|I would certainly not build a online banking system on this solution, but I |am sure this tool would reach its audience.
even integrating my previous serious breaking of ejb contract (say the finders/create) it is a point, that it would reach its audience. Again I would satisfied with the .net approach to it where the client side doesn't suffer from this artificial (compilation bound) limitation. marcf | |> -----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
