tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mohammad Nour El-Din" <nour.moham...@gmail.com>
Subject Re: EJB3 Business Interface proxies -- what do you want for features?
Date Thu, 12 Apr 2007 19:25:54 GMT
Hi All...

After reading what David Blevins have sent and you great opinions, I came
out with this humble opinion. First, we have to follow the standards anyway.
Second, we will need this extra feature - providing all-in-one proxy - to
have advantage over other EJB containers. So, what we have here is a proper
solution for two issues, first how we will make the user specify that he\she
wants the all-in-one proxy instead of one-per-interface-proxy. Second, how
to avoid as much as possible the problems before they occur without user
intervention. Currently I have a simple solution which, which is making
extra validation rules while deployment and notifies the user with the
errors found depending on his\her choice regarding proxy type.

*What I've written above is what I can claim that it is a reasonable
discussion, below is some crazy ideas, so you may skip it if you want :),
but I really want to know your feedback on this :D*

1- In case we will give the user the ability to specify an all-in-one proxy,
we can provide some extra elements to openejb-jar.xml to make the user
specify the set of interfaces he\she wants to use and under which JNDI
he\she wants the proxy to be bound for example

 <ejb-deployment ejb-name="SomeBean" deployment-id="SomeID"
container-id="SomeContainer">
   <business-interfaces>
     <business-interface>Interface1<business-interface>
     <business-interface>Interface2<business-interface>
                                        .
                                        .
                                        .
     <business-interface>InterfaceN<business-interface>
   </business-interfaces>
  </ejb-deployment>

2- We can give a more experienced user a more crazy facility which is to
specify interfaces using a sort of script\condition\constraint language to
specify by example that he\she wants to include\exclude interfaces with
certain names or having methods with certain names and\or signatures like
things related to the thrown exceptions, argument lists or return types.

On 4/12/07, Dain Sundstrom <dain@iq80.com> wrote:
>
> After thinking about this a bit longer, I don't think my idea is
> possible.  The problem is the looked-up-interface can not be combined
> with the all-implemented-interfaces set due to the
> "UndeclaredThrowableException" problem.
>
> It would be nice to be able to have two simple strategies 1) all-
> implemented 2) not-implemented.  Unfortunately, the
> "IllegalArgumentException" problem doesn't let us reliably combine
> even the implemented interfaces.  For example, the following is legal
> Java code:
>
>      public interface One {
>          One run(Object o);
>      }
>
>      public interface Two {
>          Two run(Object o);
>      }
>
>      public class OneTwo implements One, Two {
>          public OneTwo run(Object o) {
>              return null;
>          }
>      }
>
> But you can't generate a java.lang.reflect.Proxy with both the One
> and Two interfaces due to the "IllegalArgumentException" problem.
>
> I'm not sure we can do anything here (without custom bytecode
> generation, yuck).
>
> -dain
>
> On Apr 12, 2007, at 9:36 AM, Dain Sundstrom wrote:
>
> > When I write a bean, I'll most likely have my bean implement all of
> > the interfaces, so I would prefer to get an all-in-one-proxy.  I
> > can see a case where I decide to add an interface after a library
> > has shipped, so I think the "doesn't have to implement rule" is a
> > good get out of jail free card :)
> >
> > So how about a compromise....
> >
> > proxy = looked-up-interface + all-implemented-interfaces
> >
> > This way if you implement your interfaces, you get the cool all-in-
> > one proxy and you still can use unimplemented interfaces.
> >
> > -dain
> >
> > On Apr 12, 2007, at 12:19 AM, David Blevins wrote:
> >
> >> The title implies a much wider subject, so feel free to pipe in
> >> with any requests that may be not be related to the bulk of this
> >> email.
> >>
> >> Anyways, there's an interesting facet to EJB 3 business
> >> interfaces, namely that you can have as many of them as you want.
> >> One that note, you can also implement your business interfaces in
> >> your bean class whereas you could not with the old-style EJB 2.1
> >> interfaces.  But as before, you do not have to implement your
> >> business interfaces in your bean class, you can simply have
> >> "matching methods" in the old ejb style.
> >>
> >> So now here comes the question on what you as a user would like to
> >> see us do (followed by the tricky part which is why we're
> >> asking).  What would you personally want, one proxy that
> >> implements all your business interfaces or one proxy per business
> >> interface?   The spec requires us to support the one-proxy-per-
> >> interface approach, but the all-interfaces-in-one-proxy approach
> >> could be supported... sort of....
> >>
> >> The trick is that if you do *not* implement your multiple business
> >> interfaces and we try to create an all-in-one proxy, you could run
> >> into a couple different issues and one of them is really really
> >> nasty.  Here they are, the first one is the worst IMHO as I just
> >> ran into it and it's no fun :)
> >>
> >>  http://cwiki.apache.org/OPENEJB/multiple-business-interface-
> >> hazzards.html
> >>
> >> The important thing to remember is that these issues could only
> >> happen if your bean does *not* implement it's business
> >> interfaces.  If it *does* implement it's business interfaces all
> >> these issues would be sorted out at compile time and you'd never
> >> run into them in the ejb container.
> >>
> >> So, ... what would you want to see us do?  Should we support both
> >> or just the spec required approach?  If we were to support it,
> >> what would you like to see us do in the event that we encounter a
> >> bean that cannot be supported via the all-in-one proxy approach --
> >> would a log message be fine or would you want to see us fail the
> >> deployment?
> >>
> >> Thoughts?
> >>
> >> -David
> >>
> >
>
>


-- 
Thanks
- Mohammad Nour

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message