|What about client code that needs to use those interfaces? Which
For EJB client:
at deployment it is ok.
at compilation he needs the classes (aaron's point)
You still save the bean empty implementation (ejbPassivate etc), jar
generation, xml generation
For webservices client:
You save everything, generate the wsdl and uddi entry (like in axis really)
and you are done. Your webservice is backed by the simplest of all and it
is an EJB which makes it a powerful implementation.
|may be in
|the same project or required by another?
|
|Can't a developer write a HelloBean impl with a few xdoclet tags (cut and
|pasted from an example) and have a working bean?
I want to integrate these features in the standard JBoss, it needs to be
"baby food" for the guys who come.
marcf
|
|--jason
|
|
|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
