Just an idea...
Why not providing a helper class that would build smart proxies.
The client code is implemented like if it was acting against the source
class but it would need to use the helper factory to create the bean instead
of using the new operator. The helper factory would access JNDI, get the
home, get the remote a forward the requests, masking the RemoteException.
i.e.
MyDumyClass myObj = (MyDumyClass)EasyEJBHelper.createInstance
(MyDumyClass.class);
myObj.doThis ();
myObj.doThat ();
So we would wrap the server proxy in a client proxy built by the
EasyEJBHelper. MyDumyClass is the bean implementation that is dropped in
/deploy for example.
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Aaron Mulder
> Envoye : lundi, 12 novembre 2001 18:17
> A : jBoss Developer
> Objet : Re: [JBoss-dev] [research] a home/remote generator
>
>
> How do you compile the client code if the home/remote exists only
> in the VM of the running server?
>
> Aaron
>
> On Mon, 12 Nov 2001, marc fleury wrote:
> > I know there are many tools out there that do almost what I am going to
> > describe already, it is an improvement on x-doclet.
> >
> > I am wondering if the generation step cannot be done at
> deployment time. I
> > think we have the bytecode generation tools stuff that
> generates compiled
> > bytecode at runtime. See the 1.2.2 proxy generation and the
> implementation
> > Dain has put of the 2.0 spec CMP stuff. I will call them "bytecode
> > injectors".
> >
> > I would like the developer to just provide the "implementation"
> class with
> > "HelloBean", "bean" identifying the implementation. The code would be
> >
> > public class HelloBean extends SessionBean {
> >
> > public String sayHello
> > { return "hi";}
> > }
> > }
> >
> > and that is it. We would generate the home and remote with our "code
> > injectors", if we find overridden methods (ejbActivate) then we
> would use
> > that from the class definition itself, if not we provide an empty
> > implementation. We put all the public methods in the Remote, minus the
> > create(...) and find...(...) that need manipulation in the
> home. Since we
> > control the classes definition that are loaded in our system we would be
> > able to plug this one in, the "HelloBean" implemented by us (actually it
> > could be under a different name since we are on the server
> side), and the
> > client sees the generated "Hello" (naming convention we remove
> the "bean")
> > and "HelloHome". This way the client can see the classes with
> the remote
> > loading.
> >
> > For more advanced tags like the transactional ones we should incorporate
> > some x-doclet tags in the code, but these do not result in the xml file
> > generation and the jar creation rather it all works in JBoss, i.e. the
> > metadata population is done directly from the code. In essence
> we say "fuck
> > packaging", too complex.
> >
> > The goal there is really simple, it is to have the developers write the
> > trivial HelloBean above and BE DONE WITH THE EJB "LEARNING CURVE".
> >
> > marcf
> >
> > xxxxxxxxxxxxxxxx
> > Marc Fleury
> > President
> > JBoss Group, LLC
> > xxxxxxxxxxxxxxxx
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
