Yes, but one of the important point (I think) is that *the developer is able to write the client code directly by referencing the bean code without waiting for a code generator to generate the home and remote. The developer modifies the bean? no problem, he can directly uses the new methods in its editor for the client code. The magic lies in the client proxy generated by the factory.
The developer acts like if he was calling methods on the bean class (and that is almost also what the compiler think) but at runtime, the factory get a home+remote from JNDI and wraps the EJB proxy in its own proxy. And thus calls are exectued on the EJB server (going through the interceptor chain). Thus, you keep the ability to compile code directly, as you write the bean, while keeping the execution on JBoss. Then you can use JNDI environment variable on the client JVM to tell it where to lookup the JBoss server. As for Rickard's RMI semantic concern, why not making the client proxy raise java.lang.Error in case of problem (instead of java.lang.Exception). As it seem that this has even been discussed by the RMI team HIMSELF, it should be OK ;) I would certainly not build a online banking system on this solution, but I am sure this tool would reach its audience. > -----Message d'origine----- > De : marc fleury [mailto:[EMAIL PROTECTED]] > Envoye : lundi, 12 novembre 2001 19:03 > A : Sacha Labourey; Aaron Mulder; jBoss Developer > Objet : RE: [JBoss-dev] [research] a home/remote generator > > > |Just an idea... > > Your $20 worth ... > > :) > > |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. > > Let me get this right. You want the client to operate on the > bean directly > through the methods, but still buy the indirection on the EJB transaction > and security. The JavaBeans pattern for that would be pretty > cool in fact. > The pattern is know as the access bean. You are proposing that the access > bean exposes the *BEAN* interface even though behind the covers > it is an EJB > that does the transactional/security integration + additional plugin > services (e.g. CMP) hmmmmmmmmmm > > hmmmmmm > > hmmmmm > > interesting. > > marcf > > > | > | > | > |> -----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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
