well the point is more for webservices and the additional invokers.

Axis does this, in a clumsy way.

marcf

|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
|Mulder
|Sent: Monday, November 12, 2001 12:17 PM
|To: jBoss Developer
|Subject: 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

Reply via email to