You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Jonathan Gallimore <jg...@wav2.com> on 2007/08/14 13:28:55 UTC
Using XDoclet to generate openejb-jar.xml
Hi All,
Apologies if this has been asked before, but I was wondering whether
anyone uses XDoclet to generate their openejb-jar.xml deployment
descriptors?
Currently we're developing for JBoss 4, and are part way through getting
our app to deploy on the community edition of Websphere. The J2G
migration tool has done an excellent job of migrating our deployment
descriptors, but going forward I'd still like to add all the necessary
XML stuff for new EJBs using XDoclet rather than hand editing the
openejb-jar.xml. Having hunted around it looks like the openejb task
that comes with XDoclet is for a much older version, and only handles
session beans.
I've started work on an xdoclet plugin that generates a basic
openejb-jar.xml for me, and I was just wondering whether I had missed an
existing tool/plugin and was just duplicating work (obviously if I
haven't and this is a useful piece of work, I'd be happy to continue and
share it).
I'd appreciate any thoughts anyone has.
Regards,
Jon
Re: Using XDoclet to generate openejb-jar.xml
Posted by Bill Stoddard <bi...@wstoddard.com>.
Jason Warner wrote:
> Hi Jon,
>
> I'm glad that you found the j2g migration tool helpful. In regards to
> your question, one of the contributors are currently eyeballs deep
> working on a Administration Console Wizard for generating deployment
> plans. The current status of this work can be found in the jira
> geronimo-3254[1]. I read through it briefly but didn't see any
> explicit mention of the openejb-jar.xml. Perhaps you and Shiva could
> coordinate to incorporate your work in the Wizard?
>
> [1] http://issues.apache.org/jira/browse/GERONIMO-3254
> <http://issues.apache.org/jira/browse/GERONIMO-3254>
>
> Hopefully this is the kind of response you were looking for.
Hi Jon,
Good suggestion from Jason, however if this is not exactly what you were
looking for, open a new JIRA with your request.
Regards,
Bill
Re: Using XDoclet to generate openejb-jar.xml
Posted by Jason Warner <ja...@gmail.com>.
Hi Jon,
I'm glad that you found the j2g migration tool helpful. In regards to your
question, one of the contributors are currently eyeballs deep working on a
Administration Console Wizard for generating deployment plans. The current
status of this work can be found in the jira geronimo-3254[1]. I read
through it briefly but didn't see any explicit mention of the
openejb-jar.xml. Perhaps you and Shiva could coordinate to incorporate your
work in the Wizard?
[1] http://issues.apache.org/jira/browse/GERONIMO-3254
Hopefully this is the kind of response you were looking for.
Thanks,
Jason Warner
On 8/14/07, Jonathan Gallimore <jg...@wav2.com> wrote:
>
> Hi All,
>
> Apologies if this has been asked before, but I was wondering whether
> anyone uses XDoclet to generate their openejb-jar.xml deployment
> descriptors?
>
> Currently we're developing for JBoss 4, and are part way through getting
> our app to deploy on the community edition of Websphere. The J2G migration
> tool has done an excellent job of migrating our deployment descriptors, but
> going forward I'd still like to add all the necessary XML stuff for new EJBs
> using XDoclet rather than hand editing the openejb-jar.xml. Having hunted
> around it looks like the openejb task that comes with XDoclet is for a much
> older version, and only handles session beans.
>
> I've started work on an xdoclet plugin that generates a basic
> openejb-jar.xml for me, and I was just wondering whether I had missed an
> existing tool/plugin and was just duplicating work (obviously if I haven't
> and this is a useful piece of work, I'd be happy to continue and share it).
>
> I'd appreciate any thoughts anyone has.
>
> Regards,
>
> Jon
>
>
Re: AW: Using XDoclet to generate openejb-jar.xml
Posted by David Blevins <da...@visi.com>.
On Aug 24, 2007, at 9:34 AM, Jonathan Gallimore wrote:
> Thanks for the feedback. I'm still using EJB 2, and haven't used
> EJB 3 before. My new EJB 3 book is on its way from Amazon.
Great. I like the O'Reilly one. Though I haven't really read the
book since Richard retired for book authoring.
> It sounds like what I've done for generating a deployment
> descriptor for EJB 2 is unlikely to be useful to people using EJB
> 3, and perhaps any kind of deployment descriptor generator is
> unnecessary to those people?
Pretty much. A bit more detail below.
> I'm sure I can convince people at work that we need to move to EJB
> 3, if that's what's recommended.
The great thing about ejb3 is that for quite a lot of it it's
subtractive, so you're not really moving but re-moving. Any app
becomes an EJB 3.0 app the second you delete the namespace in the ejb-
jar.xml that declares it is 2.1 (or 2.0, etc). It will be assumed as
an EJB 3.0 app and from there you can keep deleting. The more
annotations you add, the more descriptor you can delete. It's a
pretty direct conversion for Session beans and MessageDriven Beans.
Let me give you the crib notes:
@Stateless or @Stateful on a class replaces the descriptor tags
<session>, <ejb-name>, <session-type>Stateless</session-type>, and
<session-type>Stateful</session-type>.
@RemoteHome or @LocalHome is used on a class to replace <home> or
<local-home>. We inspect the actual home or local-home interface to
determine the related <remote> or <local> interface.
@TransactionManagement on a class replaces <transaction-type>
@TransactionAttribute on a class and/or method replaces <container-
transaction>. You'll need one @TransactionAttribute for each
<container-transaction>/<method> xml element. A <method-name>*</
method-name> would turn into an @TransactionAttribute on a class,
everything else would go on methods.
@EJB used on a class replaces <ejb-ref> and <ejb-local-ref>. @EJB
used on a field or setter method (private or public) request
injection of that EJB as well. When @EJB is used on a class the
"beanInterface" attribute is required. When used on a field or
setter method, the "beanInterface" attribute defaults to the type of
the field or setter method.
@Resource used on a class replaces <env-entry>, <resource-ref>,
<resource-env-ref>. @Resource used on a field or method (private or
public) requests injection of that resource. When @Resource is used
on a class, the "type" attribute is required. When used on a field
or method, the "type" attribute defaults to the type of the field or
setter method.
There are more annotations obviously, but these are fairly simple and
get rid of a ton of xml.
> I'm still planning on doing more work the XDoclet plugin, just
> hoping for some spare time when the day job isn't getting in the
> way ;-)
If you're interested in working on a truly cool tool, help us write
the anti-XDoclet :)
http://www.nabble.com/ejb-jar.xml-to-Annotations-tool-tf4325175.html
-David
>
> Jon
>
> David Blevins wrote:
>>
>> On Aug 24, 2007, at 7:57 AM, Ueberbach, Michael wrote:
>>
>>> Hello,
>>>
>>> I followed the discussion about using XDoclet with great
>>> interest. I have been using XDoclet for the last four years to
>>> generate EJB applications and it has been very usefull all the
>>> time. But meanwhile (since EJB 3) I think the situation has
>>> changed dramatically. Most of what I have done with XDoclet
>>> (creating local or remote interfaces, utility classes, homefinder
>>> classes, value objects and so on) isn't neccessary anymore. There
>>> is also no more need for generating any large deployment descriptor!
>>> After converting my old EJB 2 projects to EJB 3 there remain only
>>> two artefacts that still have to be build: A very little
>>> persistence.xml and a deployment plan for geronimo. What is
>>> important for the last one is, that there are no cmp entries to
>>> be made inside the openejb-jar.xml because this can all be done
>>> by annotations inside the bean code. The only important entries
>>> made in the deployment plan are some dependencies to special
>>> libs. So I wonder what XDoclet really can do in this case?
>>> Probably it was the great success of XDoclet that lead to the
>>> annotation concept of EJB 3 and in consequence made XDoclet less
>>> usefull (only for this kind of code generation naturally).
>>> I'm interested to hear other opinions on this item.
>>
>> I think you captured the spirit of the new EJB 3.0 annotations
>> pretty well. In fact, internally we read in all the annotations
>> and use them to create or update your ejb-jar.xml (ala a nice jaxb
>> tree) in memory which we then use to deploy your app.
>>
>>
>> -David
>>
>>
>>>
>>>
>>> regards
>>> Michael
>>>
>>>
>>>
>>>
>>> Von: Jonathan Gallimore [mailto:jgallimore@wav2.com]
>>> Gesendet: Dienstag, 21. August 2007 15:39
>>> An: user@geronimo.apache.org
>>> Betreff: Re: Using XDoclet to generate openejb-jar.xml
>>>
>>> Hi Erik,
>>>
>>> At the moment, I'm part way through getting our applications
>>> working on Geronimo / Websphere-CE. We basically have two
>>> applications - our core application which is used for building
>>> publications, and another app that acts as a asset management
>>> system, and integrates with our core app using JMS. The first one
>>> of the two is now up and running on a Websphere-CE server, and
>>> hasn't really taken much to get it working at all.
>>>
>>> Largely all I needed the J2G tool to do was create some new
>>> deployment descriptors, which it did without any real problems. I
>>> needed to add some EJB refs to my geronimo-web.xml, and I needed
>>> to create a jms-resource-plan.xml myself. At first glance it
>>> didn't appear to generate much in the way of <message-driven>
>>> elements and I was a fair way through creating a patch to
>>> generate what I could from ejb-jar.xml and then I realised there
>>> was some code to do it from annotations in the source. By far and
>>> away the biggest problem I encountered was with how our EARs were
>>> laid out. I think JBoss is too forgiving with its classloader -
>>> we had a core.jar file inside our EJB.jar and nothing in any jar
>>> manifests that specified any kind of classpath. (I believe it was
>>> done in JBoss-IDE using this: http://docs.jboss.com/jbosside/
>>> tutorial/build/en/pdf/JBossIDE-Tutorial.pdf as a guide). I needed
>>> to do quite a bit of work to get it repackaged so that Websphere
>>> would be happy with it.
>>>
>>> I now need to do the same thing with the other app - I think this
>>> will be more involved, we've used more JBoss specific classes in
>>> places, so it'll hopefully be a good test of the J2G tool in
>>> terms of its code conversion abilities. I'll let you know how I
>>> get on.
>>>
>>> Overall I thought J2G was great (although it took ages to get it
>>> to build - it wasn't obvious that Maven was going nuts because I
>>> was using JDK1.6 - I couldn't find a binary on the web - is it
>>> worth adding a link from the cwiki pages?) The reason behind
>>> exploring the XDoclet route, is rather than 'migrating' to
>>> Geronimo, we'd like to add it to the app servers we can support.
>>> Going forward, we'd like new beans we add etc to work on both
>>> without needing to run J2G again, or editing two sets of files.
>>> But in terms of getting the apps going ont Geronimo in the first
>>> place, J2G has made the task much easier.
>>>
>>> I'd be more than happy to contribute to the J2G project if I can.
>>>
>>> Hope that's helpful.
>>>
>>> Regards
>>>
>>> Jon
>>>
>>> Erik B. Craig wrote:
>>>> Jon,
>>>>
>>>> I am one of the developers that contributed to j2g most
>>>> recently, and I am wondering if you had any specific comments on
>>>> it, or thoughts on any areas that you thought could use some
>>>> improvement? I've been hoping someone would, like yourself, use
>>>> it in a real world scenario to really give it a solid test, as
>>>> the best I've been able to do are 'mock' situations in testing.
>>>> Any input you could give would be great, especially if it would
>>>> be something you might be interested in helping out with a bit,
>>>> as well. Oh, and another quick thing, did the version you played
>>>> with incorporate eclipse ui plugins and annotations support yet,
>>>> or no?
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Erik B. Craig
>>>>
>>>> On 8/14/07, Jonathan Gallimore <jg...@wav2.com> wrote:
>>>> Hi All,
>>>>
>>>> Apologies if this has been asked before, but I was wondering
>>>> whether anyone uses XDoclet to generate their openejb-jar.xml
>>>> deployment descriptors?
>>>>
>>>> Currently we're developing for JBoss 4, and are part way through
>>>> getting our app to deploy on the community edition of Websphere.
>>>> The J2G migration tool has done an excellent job of migrating
>>>> our deployment descriptors, but going forward I'd still like to
>>>> add all the necessary XML stuff for new EJBs using XDoclet
>>>> rather than hand editing the openejb-jar.xml. Having hunted
>>>> around it looks like the openejb task that comes with XDoclet is
>>>> for a much older version, and only handles session beans.
>>>>
>>>> I've started work on an xdoclet plugin that generates a basic
>>>> openejb-jar.xml for me, and I was just wondering whether I had
>>>> missed an existing tool/plugin and was just duplicating work
>>>> (obviously if I haven't and this is a useful piece of work, I'd
>>>> be happy to continue and share it).
>>>>
>>>> I'd appreciate any thoughts anyone has.
>>>>
>>>> Regards,
>>>>
>>>> Jon
>>>>
>>>>
>>>>
>>>>
>>>> No virus found in this incoming message. Checked by AVG Free
>>>> Edition. Version: 7.5.476 / Virus Database: 269.11.19/955 -
>>>> Release Date: 15/08/2007 16:55
>>
>>
>>
>>
>>
Re: AW: Using XDoclet to generate openejb-jar.xml
Posted by Jonathan Gallimore <jg...@wav2.com>.
Thanks for the feedback. I'm still using EJB 2, and haven't used EJB 3
before. My new EJB 3 book is on its way from Amazon.
It sounds like what I've done for generating a deployment descriptor for
EJB 2 is unlikely to be useful to people using EJB 3, and perhaps any
kind of deployment descriptor generator is unnecessary to those people?
I'm sure I can convince people at work that we need to move to EJB 3, if
that's what's recommended.
I'm still planning on doing more work the XDoclet plugin, just hoping
for some spare time when the day job isn't getting in the way ;-)
Jon
David Blevins wrote:
>
> On Aug 24, 2007, at 7:57 AM, Ueberbach, Michael wrote:
>
>> Hello,
>>
>> I followed the discussion about using XDoclet with great interest. I
>> have been using XDoclet for the last four years to generate EJB
>> applications and it has been very usefull all the time. But meanwhile
>> (since EJB 3) I think the situation has changed dramatically. Most of
>> what I have done with XDoclet (creating local or remote interfaces,
>> utility classes, homefinder classes, value objects and so on) isn't
>> neccessary anymore. There is also no more need for generating any
>> large deployment descriptor!
>> After converting my old EJB 2 projects to EJB 3 there remain only two
>> artefacts that still have to be build: A very little persistence.xml
>> and a deployment plan for geronimo. What is important for the last
>> one is, that there are no cmp entries to be made inside the
>> openejb-jar.xml because this can all be done by annotations inside
>> the bean code. The only important entries made in the deployment plan
>> are some dependencies to special libs. So I wonder what XDoclet
>> really can do in this case?
>> Probably it was the great success of XDoclet that lead to the
>> annotation concept of EJB 3 and in consequence made XDoclet less
>> usefull (only for this kind of code generation naturally).
>> I'm interested to hear other opinions on this item.
>
> I think you captured the spirit of the new EJB 3.0 annotations pretty
> well. In fact, internally we read in all the annotations and use them
> to create or update your ejb-jar.xml (ala a nice jaxb tree) in memory
> which we then use to deploy your app.
>
>
> -David
>
>
>>
>>
>> regards
>> Michael
>>
>>
>>
>>
>> Von: Jonathan Gallimore [mailto:jgallimore@wav2.com]
>> Gesendet: Dienstag, 21. August 2007 15:39
>> An: user@geronimo.apache.org
>> Betreff: Re: Using XDoclet to generate openejb-jar.xml
>>
>> Hi Erik,
>>
>> At the moment, I'm part way through getting our applications working
>> on Geronimo / Websphere-CE. We basically have two applications - our
>> core application which is used for building publications, and another
>> app that acts as a asset management system, and integrates with our
>> core app using JMS. The first one of the two is now up and running on
>> a Websphere-CE server, and hasn't really taken much to get it working
>> at all.
>>
>> Largely all I needed the J2G tool to do was create some new
>> deployment descriptors, which it did without any real problems. I
>> needed to add some EJB refs to my geronimo-web.xml, and I needed to
>> create a jms-resource-plan.xml myself. At first glance it didn't
>> appear to generate much in the way of <message-driven> elements and I
>> was a fair way through creating a patch to generate what I could from
>> ejb-jar.xml and then I realised there was some code to do it from
>> annotations in the source. By far and away the biggest problem I
>> encountered was with how our EARs were laid out. I think JBoss is too
>> forgiving with its classloader - we had a core.jar file inside our
>> EJB.jar and nothing in any jar manifests that specified any kind of
>> classpath. (I believe it was done in JBoss-IDE using this:
>> http://docs.jboss.com/jbosside/tutorial/build/en/pdf/JBossIDE-Tutorial.pdf
>> as a guide). I needed to do quite a bit of work to get it repackaged
>> so that Websphere would be happy with it.
>>
>> I now need to do the same thing with the other app - I think this
>> will be more involved, we've used more JBoss specific classes in
>> places, so it'll hopefully be a good test of the J2G tool in terms of
>> its code conversion abilities. I'll let you know how I get on.
>>
>> Overall I thought J2G was great (although it took ages to get it to
>> build - it wasn't obvious that Maven was going nuts because I was
>> using JDK1.6 - I couldn't find a binary on the web - is it worth
>> adding a link from the cwiki pages?) The reason behind exploring the
>> XDoclet route, is rather than 'migrating' to Geronimo, we'd like to
>> add it to the app servers we can support. Going forward, we'd like
>> new beans we add etc to work on both without needing to run J2G
>> again, or editing two sets of files. But in terms of getting the apps
>> going ont Geronimo in the first place, J2G has made the task much
>> easier.
>>
>> I'd be more than happy to contribute to the J2G project if I can.
>>
>> Hope that's helpful.
>>
>> Regards
>>
>> Jon
>>
>> Erik B. Craig wrote:
>>> Jon,
>>>
>>> I am one of the developers that contributed to j2g most recently,
>>> and I am wondering if you had any specific comments on it, or
>>> thoughts on any areas that you thought could use some improvement?
>>> I've been hoping someone would, like yourself, use it in a real
>>> world scenario to really give it a solid test, as the best I've been
>>> able to do are 'mock' situations in testing. Any input you could
>>> give would be great, especially if it would be something you might
>>> be interested in helping out with a bit, as well. Oh, and another
>>> quick thing, did the version you played with incorporate eclipse ui
>>> plugins and annotations support yet, or no?
>>>
>>>
>>> Thanks!
>>>
>>> --
>>> Erik B. Craig
>>>
>>> On 8/14/07, Jonathan Gallimore <jg...@wav2.com> wrote:
>>> Hi All,
>>>
>>> Apologies if this has been asked before, but I was wondering whether
>>> anyone uses XDoclet to generate their openejb-jar.xml deployment
>>> descriptors?
>>>
>>> Currently we're developing for JBoss 4, and are part way through
>>> getting our app to deploy on the community edition of Websphere. The
>>> J2G migration tool has done an excellent job of migrating our
>>> deployment descriptors, but going forward I'd still like to add all
>>> the necessary XML stuff for new EJBs using XDoclet rather than hand
>>> editing the openejb-jar.xml. Having hunted around it looks like the
>>> openejb task that comes with XDoclet is for a much older version,
>>> and only handles session beans.
>>>
>>> I've started work on an xdoclet plugin that generates a basic
>>> openejb-jar.xml for me, and I was just wondering whether I had
>>> missed an existing tool/plugin and was just duplicating work
>>> (obviously if I haven't and this is a useful piece of work, I'd be
>>> happy to continue and share it).
>>>
>>> I'd appreciate any thoughts anyone has.
>>>
>>> Regards,
>>>
>>> Jon
>>>
>>>
>>>
>>>
>>> No virus found in this incoming message. Checked by AVG Free
>>> Edition. Version: 7.5.476 / Virus Database: 269.11.19/955 - Release
>>> Date: 15/08/2007 16:55
>
>
>
>
>
Re: AW: Using XDoclet to generate openejb-jar.xml
Posted by David Blevins <da...@visi.com>.
On Aug 24, 2007, at 7:57 AM, Ueberbach, Michael wrote:
> Hello,
>
> I followed the discussion about using XDoclet with great interest.
> I have been using XDoclet for the last four years to generate EJB
> applications and it has been very usefull all the time. But
> meanwhile (since EJB 3) I think the situation has changed
> dramatically. Most of what I have done with XDoclet (creating local
> or remote interfaces, utility classes, homefinder classes, value
> objects and so on) isn't neccessary anymore. There is also no more
> need for generating any large deployment descriptor!
> After converting my old EJB 2 projects to EJB 3 there remain only
> two artefacts that still have to be build: A very little
> persistence.xml and a deployment plan for geronimo. What is
> important for the last one is, that there are no cmp entries to be
> made inside the openejb-jar.xml because this can all be done by
> annotations inside the bean code. The only important entries made
> in the deployment plan are some dependencies to special libs. So I
> wonder what XDoclet really can do in this case?
> Probably it was the great success of XDoclet that lead to the
> annotation concept of EJB 3 and in consequence made XDoclet less
> usefull (only for this kind of code generation naturally).
> I'm interested to hear other opinions on this item.
I think you captured the spirit of the new EJB 3.0 annotations pretty
well. In fact, internally we read in all the annotations and use
them to create or update your ejb-jar.xml (ala a nice jaxb tree) in
memory which we then use to deploy your app.
-David
>
>
> regards
> Michael
>
>
>
>
> Von: Jonathan Gallimore [mailto:jgallimore@wav2.com]
> Gesendet: Dienstag, 21. August 2007 15:39
> An: user@geronimo.apache.org
> Betreff: Re: Using XDoclet to generate openejb-jar.xml
>
> Hi Erik,
>
> At the moment, I'm part way through getting our applications
> working on Geronimo / Websphere-CE. We basically have two
> applications - our core application which is used for building
> publications, and another app that acts as a asset management
> system, and integrates with our core app using JMS. The first one
> of the two is now up and running on a Websphere-CE server, and
> hasn't really taken much to get it working at all.
>
> Largely all I needed the J2G tool to do was create some new
> deployment descriptors, which it did without any real problems. I
> needed to add some EJB refs to my geronimo-web.xml, and I needed to
> create a jms-resource-plan.xml myself. At first glance it didn't
> appear to generate much in the way of <message-driven> elements and
> I was a fair way through creating a patch to generate what I could
> from ejb-jar.xml and then I realised there was some code to do it
> from annotations in the source. By far and away the biggest problem
> I encountered was with how our EARs were laid out. I think JBoss is
> too forgiving with its classloader - we had a core.jar file inside
> our EJB.jar and nothing in any jar manifests that specified any
> kind of classpath. (I believe it was done in JBoss-IDE using this:
> http://docs.jboss.com/jbosside/tutorial/build/en/pdf/JBossIDE-
> Tutorial.pdf as a guide). I needed to do quite a bit of work to get
> it repackaged so that Websphere would be happy with it.
>
> I now need to do the same thing with the other app - I think this
> will be more involved, we've used more JBoss specific classes in
> places, so it'll hopefully be a good test of the J2G tool in terms
> of its code conversion abilities. I'll let you know how I get on.
>
> Overall I thought J2G was great (although it took ages to get it to
> build - it wasn't obvious that Maven was going nuts because I was
> using JDK1.6 - I couldn't find a binary on the web - is it worth
> adding a link from the cwiki pages?) The reason behind exploring
> the XDoclet route, is rather than 'migrating' to Geronimo, we'd
> like to add it to the app servers we can support. Going forward,
> we'd like new beans we add etc to work on both without needing to
> run J2G again, or editing two sets of files. But in terms of
> getting the apps going ont Geronimo in the first place, J2G has
> made the task much easier.
>
> I'd be more than happy to contribute to the J2G project if I can.
>
> Hope that's helpful.
>
> Regards
>
> Jon
>
> Erik B. Craig wrote:
>> Jon,
>>
>> I am one of the developers that contributed to j2g most recently,
>> and I am wondering if you had any specific comments on it, or
>> thoughts on any areas that you thought could use some improvement?
>> I've been hoping someone would, like yourself, use it in a real
>> world scenario to really give it a solid test, as the best I've
>> been able to do are 'mock' situations in testing. Any input you
>> could give would be great, especially if it would be something you
>> might be interested in helping out with a bit, as well. Oh, and
>> another quick thing, did the version you played with incorporate
>> eclipse ui plugins and annotations support yet, or no?
>>
>>
>> Thanks!
>>
>> --
>> Erik B. Craig
>>
>> On 8/14/07, Jonathan Gallimore <jg...@wav2.com> wrote:
>> Hi All,
>>
>> Apologies if this has been asked before, but I was wondering
>> whether anyone uses XDoclet to generate their openejb-jar.xml
>> deployment descriptors?
>>
>> Currently we're developing for JBoss 4, and are part way through
>> getting our app to deploy on the community edition of Websphere.
>> The J2G migration tool has done an excellent job of migrating our
>> deployment descriptors, but going forward I'd still like to add
>> all the necessary XML stuff for new EJBs using XDoclet rather than
>> hand editing the openejb-jar.xml. Having hunted around it looks
>> like the openejb task that comes with XDoclet is for a much older
>> version, and only handles session beans.
>>
>> I've started work on an xdoclet plugin that generates a basic
>> openejb-jar.xml for me, and I was just wondering whether I had
>> missed an existing tool/plugin and was just duplicating work
>> (obviously if I haven't and this is a useful piece of work, I'd be
>> happy to continue and share it).
>>
>> I'd appreciate any thoughts anyone has.
>>
>> Regards,
>>
>> Jon
>>
>>
>>
>>
>> No virus found in this incoming message. Checked by AVG Free
>> Edition. Version: 7.5.476 / Virus Database: 269.11.19/955 -
>> Release Date: 15/08/2007 16:55
AW: Using XDoclet to generate openejb-jar.xml
Posted by "Ueberbach, Michael" <mi...@dbh.de>.
Hello,
I followed the discussion about using XDoclet with great interest. I
have been using XDoclet for the last four years to generate EJB
applications and it has been very usefull all the time. But meanwhile
(since EJB 3) I think the situation has changed dramatically. Most of
what I have done with XDoclet (creating local or remote interfaces,
utility classes, homefinder classes, value objects and so on) isn't
neccessary anymore. There is also no more need for generating any large
deployment descriptor!
After converting my old EJB 2 projects to EJB 3 there remain only two
artefacts that still have to be build: A very little persistence.xml and
a deployment plan for geronimo. What is important for the last one is,
that there are no cmp entries to be made inside the openejb-jar.xml
because this can all be done by annotations inside the bean code. The
only important entries made in the deployment plan are some dependencies
to special libs. So I wonder what XDoclet really can do in this case?
Probably it was the great success of XDoclet that lead to the annotation
concept of EJB 3 and in consequence made XDoclet less usefull (only for
this kind of code generation naturally).
I'm interested to hear other opinions on this item.
regards
Michael
________________________________
Von: Jonathan Gallimore [mailto:jgallimore@wav2.com]
Gesendet: Dienstag, 21. August 2007 15:39
An: user@geronimo.apache.org
Betreff: Re: Using XDoclet to generate openejb-jar.xml
Hi Erik,
At the moment, I'm part way through getting our applications working on
Geronimo / Websphere-CE. We basically have two applications - our core
application which is used for building publications, and another app
that acts as a asset management system, and integrates with our core app
using JMS. The first one of the two is now up and running on a
Websphere-CE server, and hasn't really taken much to get it working at
all.
Largely all I needed the J2G tool to do was create some new deployment
descriptors, which it did without any real problems. I needed to add
some EJB refs to my geronimo-web.xml, and I needed to create a
jms-resource-plan.xml myself. At first glance it didn't appear to
generate much in the way of <message-driven> elements and I was a fair
way through creating a patch to generate what I could from ejb-jar.xml
and then I realised there was some code to do it from annotations in the
source. By far and away the biggest problem I encountered was with how
our EARs were laid out. I think JBoss is too forgiving with its
classloader - we had a core.jar file inside our EJB.jar and nothing in
any jar manifests that specified any kind of classpath. (I believe it
was done in JBoss-IDE using this:
http://docs.jboss.com/jbosside/tutorial/build/en/pdf/JBossIDE-Tutorial.p
df as a guide). I needed to do quite a bit of work to get it repackaged
so that Websphere would be happy with it.
I now need to do the same thing with the other app - I think this will
be more involved, we've used more JBoss specific classes in places, so
it'll hopefully be a good test of the J2G tool in terms of its code
conversion abilities. I'll let you know how I get on.
Overall I thought J2G was great (although it took ages to get it to
build - it wasn't obvious that Maven was going nuts because I was using
JDK1.6 - I couldn't find a binary on the web - is it worth adding a link
from the cwiki pages?) The reason behind exploring the XDoclet route, is
rather than 'migrating' to Geronimo, we'd like to add it to the app
servers we can support. Going forward, we'd like new beans we add etc to
work on both without needing to run J2G again, or editing two sets of
files. But in terms of getting the apps going ont Geronimo in the first
place, J2G has made the task much easier.
I'd be more than happy to contribute to the J2G project if I can.
Hope that's helpful.
Regards
Jon
Erik B. Craig wrote:
Jon,
I am one of the developers that contributed to j2g most
recently, and I am wondering if you had any specific comments on it, or
thoughts on any areas that you thought could use some improvement? I've
been hoping someone would, like yourself, use it in a real world
scenario to really give it a solid test, as the best I've been able to
do are 'mock' situations in testing. Any input you could give would be
great, especially if it would be something you might be interested in
helping out with a bit, as well. Oh, and another quick thing, did the
version you played with incorporate eclipse ui plugins and annotations
support yet, or no?
Thanks!
--
Erik B. Craig
On 8/14/07, Jonathan Gallimore <jg...@wav2.com> wrote:
Hi All,
Apologies if this has been asked before, but I was
wondering whether anyone uses XDoclet to generate their openejb-jar.xml
deployment descriptors?
Currently we're developing for JBoss 4, and are part way
through getting our app to deploy on the community edition of Websphere.
The J2G migration tool has done an excellent job of migrating our
deployment descriptors, but going forward I'd still like to add all the
necessary XML stuff for new EJBs using XDoclet rather than hand editing
the openejb-jar.xml. Having hunted around it looks like the openejb task
that comes with XDoclet is for a much older version, and only handles
session beans.
I've started work on an xdoclet plugin that generates a
basic openejb-jar.xml for me, and I was just wondering whether I had
missed an existing tool/plugin and was just duplicating work (obviously
if I haven't and this is a useful piece of work, I'd be happy to
continue and share it).
I'd appreciate any thoughts anyone has.
Regards,
Jon
________________________________
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.11.19/955 - Release Date:
15/08/2007 16:55
Re: Using XDoclet to generate openejb-jar.xml
Posted by Jonathan Gallimore <jg...@wav2.com>.
Hi Erik,
At the moment, I'm part way through getting our applications working on
Geronimo / Websphere-CE. We basically have two applications - our core
application which is used for building publications, and another app
that acts as a asset management system, and integrates with our core app
using JMS. The first one of the two is now up and running on a
Websphere-CE server, and hasn't really taken much to get it working at all.
Largely all I needed the J2G tool to do was create some new deployment
descriptors, which it did without any real problems. I needed to add
some EJB refs to my geronimo-web.xml, and I needed to create a
jms-resource-plan.xml myself. At first glance it didn't appear to
generate much in the way of <message-driven> elements and I was a fair
way through creating a patch to generate what I could from ejb-jar.xml
and then I realised there was some code to do it from annotations in the
source. By far and away the biggest problem I encountered was with how
our EARs were laid out. I think JBoss is too forgiving with its
classloader - we had a core.jar file inside our EJB.jar and nothing in
any jar manifests that specified any kind of classpath. (I believe it
was done in JBoss-IDE using this:
http://docs.jboss.com/jbosside/tutorial/build/en/pdf/JBossIDE-Tutorial.pdf
as a guide). I needed to do quite a bit of work to get it repackaged so
that Websphere would be happy with it.
I now need to do the same thing with the other app - I think this will
be more involved, we've used more JBoss specific classes in places, so
it'll hopefully be a good test of the J2G tool in terms of its code
conversion abilities. I'll let you know how I get on.
Overall I thought J2G was great (although it took ages to get it to
build - it wasn't obvious that Maven was going nuts because I was using
JDK1.6 - I couldn't find a binary on the web - is it worth adding a link
from the cwiki pages?) The reason behind exploring the XDoclet route, is
rather than 'migrating' to Geronimo, we'd like to add it to the app
servers we can support. Going forward, we'd like new beans we add etc to
work on both without needing to run J2G again, or editing two sets of
files. But in terms of getting the apps going ont Geronimo in the first
place, J2G has made the task much easier.
I'd be more than happy to contribute to the J2G project if I can.
Hope that's helpful.
Regards
Jon
Erik B. Craig wrote:
> Jon,
>
> I am one of the developers that contributed to j2g most recently, and
> I am wondering if you had any specific comments on it, or thoughts on
> any areas that you thought could use some improvement? I've been
> hoping someone would, like yourself, use it in a real world scenario
> to really give it a solid test, as the best I've been able to do are
> 'mock' situations in testing. Any input you could give would be great,
> especially if it would be something you might be interested in helping
> out with a bit, as well. Oh, and another quick thing, did the version
> you played with incorporate eclipse ui plugins and annotations support
> yet, or no?
>
>
> Thanks!
>
> --
> Erik B. Craig
>
> On 8/14/07, *Jonathan Gallimore* <jgallimore@wav2.com
> <ma...@wav2.com>> wrote:
>
> Hi All,
>
> Apologies if this has been asked before, but I was wondering
> whether anyone uses XDoclet to generate their openejb-jar.xml
> deployment descriptors?
>
> Currently we're developing for JBoss 4, and are part way through
> getting our app to deploy on the community edition of Websphere.
> The J2G migration tool has done an excellent job of migrating our
> deployment descriptors, but going forward I'd still like to add
> all the necessary XML stuff for new EJBs using XDoclet rather than
> hand editing the openejb-jar.xml. Having hunted around it looks
> like the openejb task that comes with XDoclet is for a much older
> version, and only handles session beans.
>
> I've started work on an xdoclet plugin that generates a basic
> openejb-jar.xml for me, and I was just wondering whether I had
> missed an existing tool/plugin and was just duplicating work
> (obviously if I haven't and this is a useful piece of work, I'd be
> happy to continue and share it).
>
> I'd appreciate any thoughts anyone has.
>
> Regards,
>
> Jon
>
>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.11.19/955 - Release Date: 15/08/2007 16:55
>
Re: Using XDoclet to generate openejb-jar.xml
Posted by "Erik B. Craig" <gi...@gmail.com>.
Jon,
I am one of the developers that contributed to j2g most recently, and I am
wondering if you had any specific comments on it, or thoughts on any areas
that you thought could use some improvement? I've been hoping someone would,
like yourself, use it in a real world scenario to really give it a solid
test, as the best I've been able to do are 'mock' situations in testing. Any
input you could give would be great, especially if it would be something you
might be interested in helping out with a bit, as well. Oh, and another
quick thing, did the version you played with incorporate eclipse ui plugins
and annotations support yet, or no?
Thanks!
--
Erik B. Craig
On 8/14/07, Jonathan Gallimore <jg...@wav2.com> wrote:
>
> Hi All,
>
> Apologies if this has been asked before, but I was wondering whether
> anyone uses XDoclet to generate their openejb-jar.xml deployment
> descriptors?
>
> Currently we're developing for JBoss 4, and are part way through getting
> our app to deploy on the community edition of Websphere. The J2G migration
> tool has done an excellent job of migrating our deployment descriptors, but
> going forward I'd still like to add all the necessary XML stuff for new EJBs
> using XDoclet rather than hand editing the openejb-jar.xml. Having hunted
> around it looks like the openejb task that comes with XDoclet is for a much
> older version, and only handles session beans.
>
> I've started work on an xdoclet plugin that generates a basic
> openejb-jar.xml for me, and I was just wondering whether I had missed an
> existing tool/plugin and was just duplicating work (obviously if I haven't
> and this is a useful piece of work, I'd be happy to continue and share it).
>
> I'd appreciate any thoughts anyone has.
>
> Regards,
>
> Jon
>
>