You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Blevins <da...@visi.com> on 2007/01/20 02:07:58 UTC
Conversion Tool
Keep your ejb related plan files intact or a copy of them at least.
I'm going to try and write a conversion tool that will at least
handle trivial apps. A non-trivial app would be one with CMPs. The
new mapping.xml format for cmps is the jpa mapping.xml and converting
that will be a little more work.
Nothing done yet, just announcing intentions.
-David
Re: Deployment plan docs
Posted by Hernan Cunico <hc...@gmail.com>.
Dave,
we didn't ditch those docs, they just fell behind ;-)
thanks for making the updates.
Cheers!
Hernan
David Blevins wrote:
> So a funny thing happened on the way to the theater :)
>
> On Jan 31, 2007, at 11:05 PM, David Blevins wrote:
>
>> So the 10,000 foot perspective is that we are creating a conversion
>> tool to convert the prior openejb-jar.xml into the new set of
>> descriptors (geronimo-openejb.xml, new openejb-jar.xml, jpa
>> entity-mappings.xml). It is expected that all existing plans will
>> work and no one will have to or even *should* migrate just yet.
>>
>> We are doing this for two reasons:
>>
>> 1. There is significant investment in current descriptor format.
>> These come to mind:
>> - TCK
>> - DayTrader
>> - iTests
>> - Samples
>> - All documentation to date
>> - All user-land apps to date
>
> It seems we ditched the openejb-jar.xml documentation anyway. I went
> ahead and added it into GMOxDOC20 and GMOxDOC21.
>
> I also noticed that these docs were also left:
>
> http://cwiki.apache.org/confluence/display/GMOxDOC12/geronimo-web.xml
> http://cwiki.apache.org/confluence/display/GMOxDOC12/geronimo-ra.xml
> http://cwiki.apache.org/confluence/display/GMOxDOC12/geronimo-application.xml
>
>
> We support backwards compatibility of our plans, so these docs should be
> fine for the most part.
>
> Is there some rational for not including them?
>
> -David
>
>
Deployment plan docs (was: Re: Conversion Tool and OpenEJB 3.0 integration status)
Posted by David Blevins <da...@visi.com>.
So a funny thing happened on the way to the theater :)
On Jan 31, 2007, at 11:05 PM, David Blevins wrote:
> So the 10,000 foot perspective is that we are creating a conversion
> tool to convert the prior openejb-jar.xml into the new set of
> descriptors (geronimo-openejb.xml, new openejb-jar.xml, jpa entity-
> mappings.xml). It is expected that all existing plans will work and
> no one will have to or even *should* migrate just yet.
>
> We are doing this for two reasons:
>
> 1. There is significant investment in current descriptor format.
> These come to mind:
> - TCK
> - DayTrader
> - iTests
> - Samples
> - All documentation to date
> - All user-land apps to date
It seems we ditched the openejb-jar.xml documentation anyway. I went
ahead and added it into GMOxDOC20 and GMOxDOC21.
I also noticed that these docs were also left:
http://cwiki.apache.org/confluence/display/GMOxDOC12/geronimo-web.xml
http://cwiki.apache.org/confluence/display/GMOxDOC12/geronimo-ra.xml
http://cwiki.apache.org/confluence/display/GMOxDOC12/geronimo-application.xml
We support backwards compatibility of our plans, so these docs should
be fine for the most part.
Is there some rational for not including them?
-David
Re: Conversion Tool
Posted by David Blevins <da...@visi.com>.
On Feb 16, 2007, at 2:11 PM, Christopher Blythe wrote:
> How old do you consider very old? I got this on the Geronimo 2.0-M2
> release that is out on the Geronimo website dated
> 1/30/2007.Deployed fine on M1 though...
The converter didn't make it into the M2 release. So just old enough :)
I'd give it a try on trunk and see how far you get.
-David
>
> On 2/16/07, David Blevins <da...@visi.com> wrote:
> On Feb 16, 2007, at 6:09 AM, Christopher Blythe wrote:
>
> > David/Dain...
> >
> > Did this information help narrow anything down?
>
> Actually, yes. Seems your build is very old -- we don't even have
> that error message anymore. What version are you using?
>
> -David
>
> > As an fyi, I tried to add an openejb-jar.xml file (based on the
> > file Dain provided earlier in the email chain) to the location
> > specified in the exception. Unfortunately, it resulted in the same
> > error.
> >
> > openejb-jar.xml
> > ---------------
> > https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
> > container/openejb-core/src/test/resources/convert/oej2/cmp/
> daytrader/
> > daytrader-openejb-jar.xml
> >
> > Thanks...
> >
> > Chris
> >
> > On 2/15/07, Christopher Blythe <cj...@gmail.com> wrote:
> David...
> >
> > Here is the exception I get...
> >
> > Currently a Geronimo deployment plan is required for an EJB module.
> > Please provide a plan as a deployer argument or packaged in the EJB
> > JAR at META-INF/openejb-jar.xml
> >
> > org.apache.geronimo.common.DeploymentException: Currently a
> > Geronimo deployment plan is required for an EJB module. Please
> > provide a plan as a deployer argument or packaged in the EJB JAR at
> > META-INF/openejb-jar.xml
> > at
> > org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule
> > (EjbModuleBuilder.java :166)
> > at
> > org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule
> > (EjbModuleBuilder.java:134)
> > at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$
> > $FastClassByCGLIB$$cd80af20.invoke
> > (<generated>)
> > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> > (FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> > (GBeanOperation.java:127)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> > (GBeanInstance.java:820)
> > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> > (RawInvoker.java :57)
> > at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> > (RawOperationInvoker.java:35)
> > at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> > (ProxyMethodInterceptor.java :96)
> > at org.apache.geronimo.j2ee.deployment.ModuleBuilder$
> > $EnhancerByCGLIB$$d2a1ea22.createModule
> > (<generated>)
> > at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules
> > (EARConfigBuilder.java:723)
> > at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan
> > (EARConfigBuilder.java:355)
> > at
> >
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan
> > (EARConfigBuilder.java:257)
> > at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$
> > $FastClassByCGLIB$$38e56ec6.invoke(<generated>)
> > at net.sf.cglib.reflect.FastMethod.invoke
> > ( FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> > (FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> > (GBeanOperation.java :127)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> > (GBeanInstance.java:820)
> > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> > (RawInvoker.java:57)
> > at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> > (RawOperationInvoker.java:35)
> > at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> > (ProxyMethodInterceptor.java:96)
> > at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$
> > $EnhancerByCGLIB$$9cf6437.getDeploymentPlan (<generated>)
> > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java
> > :232)
> > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java :
> 124)
> > at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$
> > $734a235d.invoke (<generated>)
> > at net.sf.cglib.reflect.FastMethod.invoke
> > (FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> > (FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> > (GBeanOperation.java:127)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> > (GBeanInstance.java :855)
> > at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> > (BasicKernel.java:239)
> > at
> >
> org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDe
> > ploy (AbstractDeployCommand.java :114)
> > at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run
> > (DistributeCommand.java:60)
> > at java.lang.Thread.run(Thread.java:595)I have placed the plan file
> > and ear that I am using at the following location...
> >
> > http://people.apache.org/~cjblythe/m2_deploy/
> >
> > Thanks...
> >
> > Chris
> >
> >
> > On 2/14/07, David Blevins < david.blevins@visi.com> wrote:
> > On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote:
> >
> > > Dain and David...
> > >
> > > Took a swag at deploying Daytrader on Geronimo 2.0-M2... During
> > > deployment, it complained about the openejb-jar.xml file missing
> > > from the EJB module. I added the one you provided earlier in this
> > > chain, but for some reason it is still complaining that the
> openejb-
> > > jar.xml file is missing from the EJB module. I think Matt is
> > > probably running into the same issue...
> > >
> > > Does the or-mapping file also need to go in the ear/jar somewhere?
> > > Should this work on M2? Is there anything else that needs to go
> > > into the jar/ear?
> > >
> > > It really seems to me like we need way too many extra xml files to
> > > deploy this thing.
> >
> > You shouldn't need any files in the ear, i.e. passing the plan as a
> > parameter on the command line should work as always.
> >
> > Post the message text and a stack trace (if there is one) and I'll
> > see if I can't find what part of the code is confused.
> >
> > -David
> >
> > >
> > > Thanks...
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > >
> > > On 2/7/07, Dain Sundstrom <da...@iq80.com> wrote:I just fix that
> > > allows nested openejb plans to work correctly. This
> > > was a big problem in the tck since all plans use the nested model.
> > >
> > > -dain
> > >
> > > On Feb 6, 2007, at 9:10 PM, Dain Sundstrom wrote:
> > >
> > > > OK, I think the conversion tool should be full working now.
> > > >
> > > > There were loads of tiny bugs causing deployments to fail
> > > > especially around cmp. I tested the converter with the OpenEJB2
> > > > itests which use almost every feature of OpenEJB2 and the
> > > > application now deploys with out error now. Of course there are
> > > > things sill unimplemented or ported to 3, so if you try to use
> > > > those features, you will get an exception at runtime.
> > > >
> > > > Let us know if you find any problems with the converter.
> > > >
> > > > -dain
> > > >
> > > > On Feb 6, 2007, at 9:57 AM, Dain Sundstrom wrote:
> > > >
> > > >> On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
> > > >>
> > > >>> Haven't been able to get a full deploy of anything (tried
> > > >>> daytrader and the v2 itests), but things are starting to look
> > > >>> good with the converter. The basic conversion is happening
> and
> > > >>> conversion of things like environment and abstract name
> queries
> > > >>> are definitely getting ported over. Still see some hiccups in
> > > >>> CMPs, but apps without CMPs may deploy just fine. Will look
> > into
> > > >>> it more when I get up.
> > > >>>
> > > >>> Dain, can you take a look at the persistence unit part of the
> > > >>> rewritten EjbModuleBuilder. Seems something in the way i've
> > > >>> reworked the code results in those not coming through so well.
> > > >>
> > > >> Looking at it now.
> > > >>
> > > >> -dain
> > > >>
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > "I say never be complete, I say stop being perfect, I say let...
> > > lets evolve, let the chips fall where they may." - Tyler Durden
> >
> >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> > lets evolve, let the chips fall where they may." - Tyler Durden
> >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> > lets evolve, let the chips fall where they may." - Tyler Durden
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
Re: Conversion Tool
Posted by Christopher Blythe <cj...@gmail.com>.
How old do you consider very old? I got this on the Geronimo 2.0-M2 release
that is out on the Geronimo website dated 1/30/2007.Deployed fine on M1
though...
On 2/16/07, David Blevins <da...@visi.com> wrote:
>
>
> On Feb 16, 2007, at 6:09 AM, Christopher Blythe wrote:
>
> > David/Dain...
> >
> > Did this information help narrow anything down?
>
> Actually, yes. Seems your build is very old -- we don't even have
> that error message anymore. What version are you using?
>
> -David
>
> > As an fyi, I tried to add an openejb-jar.xml file (based on the
> > file Dain provided earlier in the email chain) to the location
> > specified in the exception. Unfortunately, it resulted in the same
> > error.
> >
> > openejb-jar.xml
> > ---------------
> > https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
> > container/openejb-core/src/test/resources/convert/oej2/cmp/daytrader/
> > daytrader-openejb-jar.xml
> >
> > Thanks...
> >
> > Chris
> >
> > On 2/15/07, Christopher Blythe <cj...@gmail.com> wrote: David...
> >
> > Here is the exception I get...
> >
> > Currently a Geronimo deployment plan is required for an EJB module.
> > Please provide a plan as a deployer argument or packaged in the EJB
> > JAR at META-INF/openejb-jar.xml
> >
> > org.apache.geronimo.common.DeploymentException: Currently a
> > Geronimo deployment plan is required for an EJB module. Please
> > provide a plan as a deployer argument or packaged in the EJB JAR at
> > META-INF/openejb-jar.xml
> > at
> > org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule
> > (EjbModuleBuilder.java:166)
> > at
> > org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule
> > (EjbModuleBuilder.java:134)
> > at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$
> > $FastClassByCGLIB$$cd80af20.invoke
> > (<generated>)
> > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> > (FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> > (GBeanOperation.java:127)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> > (GBeanInstance.java:820)
> > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> > (RawInvoker.java:57)
> > at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> > (RawOperationInvoker.java:35)
> > at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> > (ProxyMethodInterceptor.java:96)
> > at org.apache.geronimo.j2ee.deployment.ModuleBuilder$
> > $EnhancerByCGLIB$$d2a1ea22.createModule
> > (<generated>)
> > at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules
> > (EARConfigBuilder.java:723)
> > at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan
> > (EARConfigBuilder.java:355)
> > at
> > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan
> > (EARConfigBuilder.java:257)
> > at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$
> > $FastClassByCGLIB$$38e56ec6.invoke(<generated>)
> > at net.sf.cglib.reflect.FastMethod.invoke
> > (FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> > (FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> > (GBeanOperation.java:127)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> > (GBeanInstance.java:820)
> > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> > (RawInvoker.java:57)
> > at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> > (RawOperationInvoker.java:35)
> > at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> > (ProxyMethodInterceptor.java:96)
> > at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$
> > $EnhancerByCGLIB$$9cf6437.getDeploymentPlan (<generated>)
> > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java
> > :232)
> > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
> > at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$
> > $734a235d.invoke (<generated>)
> > at net.sf.cglib.reflect.FastMethod.invoke
> > (FastMethod.java:53)
> > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> > (FastMethodInvoker.java:38)
> > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> > (GBeanOperation.java:127)
> > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> > (GBeanInstance.java:855)
> > at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> > (BasicKernel.java:239)
> > at
> > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDe
> > ploy (AbstractDeployCommand.java:114)
> > at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run
> > (DistributeCommand.java:60)
> > at java.lang.Thread.run(Thread.java:595)I have placed the plan file
> > and ear that I am using at the following location...
> >
> > http://people.apache.org/~cjblythe/m2_deploy/
> >
> > Thanks...
> >
> > Chris
> >
> >
> > On 2/14/07, David Blevins <da...@visi.com> wrote:
> > On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote:
> >
> > > Dain and David...
> > >
> > > Took a swag at deploying Daytrader on Geronimo 2.0-M2... During
> > > deployment, it complained about the openejb-jar.xml file missing
> > > from the EJB module. I added the one you provided earlier in this
> > > chain, but for some reason it is still complaining that the openejb-
> > > jar.xml file is missing from the EJB module. I think Matt is
> > > probably running into the same issue...
> > >
> > > Does the or-mapping file also need to go in the ear/jar somewhere?
> > > Should this work on M2? Is there anything else that needs to go
> > > into the jar/ear?
> > >
> > > It really seems to me like we need way too many extra xml files to
> > > deploy this thing.
> >
> > You shouldn't need any files in the ear, i.e. passing the plan as a
> > parameter on the command line should work as always.
> >
> > Post the message text and a stack trace (if there is one) and I'll
> > see if I can't find what part of the code is confused.
> >
> > -David
> >
> > >
> > > Thanks...
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > >
> > > On 2/7/07, Dain Sundstrom <da...@iq80.com> wrote:I just fix that
> > > allows nested openejb plans to work correctly. This
> > > was a big problem in the tck since all plans use the nested model.
> > >
> > > -dain
> > >
> > > On Feb 6, 2007, at 9:10 PM, Dain Sundstrom wrote:
> > >
> > > > OK, I think the conversion tool should be full working now.
> > > >
> > > > There were loads of tiny bugs causing deployments to fail
> > > > especially around cmp. I tested the converter with the OpenEJB2
> > > > itests which use almost every feature of OpenEJB2 and the
> > > > application now deploys with out error now. Of course there are
> > > > things sill unimplemented or ported to 3, so if you try to use
> > > > those features, you will get an exception at runtime.
> > > >
> > > > Let us know if you find any problems with the converter.
> > > >
> > > > -dain
> > > >
> > > > On Feb 6, 2007, at 9:57 AM, Dain Sundstrom wrote:
> > > >
> > > >> On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
> > > >>
> > > >>> Haven't been able to get a full deploy of anything (tried
> > > >>> daytrader and the v2 itests), but things are starting to look
> > > >>> good with the converter. The basic conversion is happening and
> > > >>> conversion of things like environment and abstract name queries
> > > >>> are definitely getting ported over. Still see some hiccups in
> > > >>> CMPs, but apps without CMPs may deploy just fine. Will look
> > into
> > > >>> it more when I get up.
> > > >>>
> > > >>> Dain, can you take a look at the persistence unit part of the
> > > >>> rewritten EjbModuleBuilder. Seems something in the way i've
> > > >>> reworked the code results in those not coming through so well.
> > > >>
> > > >> Looking at it now.
> > > >>
> > > >> -dain
> > > >>
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > "I say never be complete, I say stop being perfect, I say let...
> > > lets evolve, let the chips fall where they may." - Tyler Durden
> >
> >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> > lets evolve, let the chips fall where they may." - Tyler Durden
> >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> > lets evolve, let the chips fall where they may." - Tyler Durden
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: Conversion Tool
Posted by David Blevins <da...@visi.com>.
On Feb 16, 2007, at 6:09 AM, Christopher Blythe wrote:
> David/Dain...
>
> Did this information help narrow anything down?
Actually, yes. Seems your build is very old -- we don't even have
that error message anymore. What version are you using?
-David
> As an fyi, I tried to add an openejb-jar.xml file (based on the
> file Dain provided earlier in the email chain) to the location
> specified in the exception. Unfortunately, it resulted in the same
> error.
>
> openejb-jar.xml
> ---------------
> https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
> container/openejb-core/src/test/resources/convert/oej2/cmp/daytrader/
> daytrader-openejb-jar.xml
>
> Thanks...
>
> Chris
>
> On 2/15/07, Christopher Blythe <cj...@gmail.com> wrote: David...
>
> Here is the exception I get...
>
> Currently a Geronimo deployment plan is required for an EJB module.
> Please provide a plan as a deployer argument or packaged in the EJB
> JAR at META-INF/openejb-jar.xml
>
> org.apache.geronimo.common.DeploymentException: Currently a
> Geronimo deployment plan is required for an EJB module. Please
> provide a plan as a deployer argument or packaged in the EJB JAR at
> META-INF/openejb-jar.xml
> at
> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule
> (EjbModuleBuilder.java:166)
> at
> org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule
> (EjbModuleBuilder.java:134)
> at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$
> $FastClassByCGLIB$$cd80af20.invoke
> (<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:127)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:820)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> (RawInvoker.java:57)
> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:35)
> at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at org.apache.geronimo.j2ee.deployment.ModuleBuilder$
> $EnhancerByCGLIB$$d2a1ea22.createModule
> (<generated>)
> at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules
> (EARConfigBuilder.java:723)
> at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan
> (EARConfigBuilder.java:355)
> at
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan
> (EARConfigBuilder.java:257)
> at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$
> $FastClassByCGLIB$$38e56ec6.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke
> (FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:127)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:820)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
> (RawInvoker.java:57)
> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:35)
> at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$
> $EnhancerByCGLIB$$9cf6437.getDeploymentPlan (<generated>)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java
> :232)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
> at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$
> $734a235d.invoke (<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke
> (FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
> (FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:127)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:855)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke
> (BasicKernel.java:239)
> at
> org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDe
> ploy (AbstractDeployCommand.java:114)
> at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run
> (DistributeCommand.java:60)
> at java.lang.Thread.run(Thread.java:595)I have placed the plan file
> and ear that I am using at the following location...
>
> http://people.apache.org/~cjblythe/m2_deploy/
>
> Thanks...
>
> Chris
>
>
> On 2/14/07, David Blevins <da...@visi.com> wrote:
> On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote:
>
> > Dain and David...
> >
> > Took a swag at deploying Daytrader on Geronimo 2.0-M2... During
> > deployment, it complained about the openejb-jar.xml file missing
> > from the EJB module. I added the one you provided earlier in this
> > chain, but for some reason it is still complaining that the openejb-
> > jar.xml file is missing from the EJB module. I think Matt is
> > probably running into the same issue...
> >
> > Does the or-mapping file also need to go in the ear/jar somewhere?
> > Should this work on M2? Is there anything else that needs to go
> > into the jar/ear?
> >
> > It really seems to me like we need way too many extra xml files to
> > deploy this thing.
>
> You shouldn't need any files in the ear, i.e. passing the plan as a
> parameter on the command line should work as always.
>
> Post the message text and a stack trace (if there is one) and I'll
> see if I can't find what part of the code is confused.
>
> -David
>
> >
> > Thanks...
> >
> > Chris
> >
> >
> >
> >
> >
> > On 2/7/07, Dain Sundstrom <da...@iq80.com> wrote:I just fix that
> > allows nested openejb plans to work correctly. This
> > was a big problem in the tck since all plans use the nested model.
> >
> > -dain
> >
> > On Feb 6, 2007, at 9:10 PM, Dain Sundstrom wrote:
> >
> > > OK, I think the conversion tool should be full working now.
> > >
> > > There were loads of tiny bugs causing deployments to fail
> > > especially around cmp. I tested the converter with the OpenEJB2
> > > itests which use almost every feature of OpenEJB2 and the
> > > application now deploys with out error now. Of course there are
> > > things sill unimplemented or ported to 3, so if you try to use
> > > those features, you will get an exception at runtime.
> > >
> > > Let us know if you find any problems with the converter.
> > >
> > > -dain
> > >
> > > On Feb 6, 2007, at 9:57 AM, Dain Sundstrom wrote:
> > >
> > >> On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
> > >>
> > >>> Haven't been able to get a full deploy of anything (tried
> > >>> daytrader and the v2 itests), but things are starting to look
> > >>> good with the converter. The basic conversion is happening and
> > >>> conversion of things like environment and abstract name queries
> > >>> are definitely getting ported over. Still see some hiccups in
> > >>> CMPs, but apps without CMPs may deploy just fine. Will look
> into
> > >>> it more when I get up.
> > >>>
> > >>> Dain, can you take a look at the persistence unit part of the
> > >>> rewritten EjbModuleBuilder. Seems something in the way i've
> > >>> reworked the code results in those not coming through so well.
> > >>
> > >> Looking at it now.
> > >>
> > >> -dain
> > >>
> > >
> >
> >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> > lets evolve, let the chips fall where they may." - Tyler Durden
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
Re: Conversion Tool
Posted by Christopher Blythe <cj...@gmail.com>.
David/Dain...
Did this information help narrow anything down?
As an fyi, I tried to add an openejb-jar.xml file (based on the file Dain
provided earlier in the email chain) to the location specified in the
exception. Unfortunately, it resulted in the same error.
openejb-jar.xml
---------------
https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
container/openejb-core/src/test/resources/convert/oej2/cmp/daytrader/
daytrader-openejb-jar.xml
Thanks...
Chris
On 2/15/07, Christopher Blythe <cj...@gmail.com> wrote:
>
> David...
>
> Here is the exception I get...
>
> Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml
>
> org.apache.geronimo.common.DeploymentException: Currently a Geronimo deployment plan is required for an EJB module. Please provide a plan as a deployer argument or packaged in the EJB JAR at META-INF/openejb-jar.xml
>
> at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:166)
> at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:134)
> at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$$FastClassByCGLIB$$cd80af20.invoke
> (<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
> (GBeanOperation.java:127)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
> (RawOperationInvoker.java:35)
> at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$d2a1ea22.createModule
> (<generated>)
> at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:723)
> at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:355)
> at
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:257)
> at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke
> (FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:820)
> at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
> (ProxyMethodInterceptor.java:96)
> at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$9cf6437.getDeploymentPlan(<generated>)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java
> :232)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
> at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(<generated>)
> at net.sf.cglib.reflect.FastMethod.invoke
> (FastMethod.java:53)
> at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
> (GBeanInstance.java:855)
> at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
> at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:114)
>
> at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60)
> at java.lang.Thread.run(Thread.java:595)
>
> I have placed the plan file and ear that I am using at the following
> location...
>
> http://people.apache.org/~cjblythe/m2_deploy/<http://people.apache.org/%7Ecjblythe/m2_deploy/>
>
> Thanks...
>
> Chris
>
> On 2/14/07, David Blevins <da...@visi.com> wrote:
> >
> >
> > On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote:
> >
> > > Dain and David...
> > >
> > > Took a swag at deploying Daytrader on Geronimo 2.0-M2... During
> > > deployment, it complained about the openejb-jar.xml file missing
> > > from the EJB module. I added the one you provided earlier in this
> > > chain, but for some reason it is still complaining that the openejb-
> > > jar.xml file is missing from the EJB module. I think Matt is
> > > probably running into the same issue...
> > >
> > > Does the or-mapping file also need to go in the ear/jar somewhere?
> > > Should this work on M2? Is there anything else that needs to go
> > > into the jar/ear?
> > >
> > > It really seems to me like we need way too many extra xml files to
> > > deploy this thing.
> >
> > You shouldn't need any files in the ear, i.e. passing the plan as a
> > parameter on the command line should work as always.
> >
> > Post the message text and a stack trace (if there is one) and I'll
> > see if I can't find what part of the code is confused.
> >
> > -David
> >
> > >
> > > Thanks...
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > >
> > > On 2/7/07, Dain Sundstrom <da...@iq80.com> wrote:I just fix that
> > > allows nested openejb plans to work correctly. This
> > > was a big problem in the tck since all plans use the nested model.
> > >
> > > -dain
> > >
> > > On Feb 6, 2007, at 9:10 PM, Dain Sundstrom wrote:
> > >
> > > > OK, I think the conversion tool should be full working now.
> > > >
> > > > There were loads of tiny bugs causing deployments to fail
> > > > especially around cmp. I tested the converter with the OpenEJB2
> > > > itests which use almost every feature of OpenEJB2 and the
> > > > application now deploys with out error now. Of course there are
> > > > things sill unimplemented or ported to 3, so if you try to use
> > > > those features, you will get an exception at runtime.
> > > >
> > > > Let us know if you find any problems with the converter.
> > > >
> > > > -dain
> > > >
> > > > On Feb 6, 2007, at 9:57 AM, Dain Sundstrom wrote:
> > > >
> > > >> On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
> > > >>
> > > >>> Haven't been able to get a full deploy of anything (tried
> > > >>> daytrader and the v2 itests), but things are starting to look
> > > >>> good with the converter. The basic conversion is happening and
> > > >>> conversion of things like environment and abstract name queries
> > > >>> are definitely getting ported over. Still see some hiccups in
> > > >>> CMPs, but apps without CMPs may deploy just fine. Will look into
> > > >>> it more when I get up.
> > > >>>
> > > >>> Dain, can you take a look at the persistence unit part of the
> > > >>> rewritten EjbModuleBuilder. Seems something in the way i've
> > > >>> reworked the code results in those not coming through so well.
> > > >>
> > > >> Looking at it now.
> > > >>
> > > >> -dain
> > > >>
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > "I say never be complete, I say stop being perfect, I say let...
> > > lets evolve, let the chips fall where they may." - Tyler Durden
> >
> >
>
>
> --
> "I say never be complete, I say stop being perfect, I say let... lets
> evolve, let the chips fall where they may." - Tyler Durden
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: Conversion Tool
Posted by Christopher Blythe <cj...@gmail.com>.
David...
Here is the exception I get...
Currently a Geronimo deployment plan is required for an EJB module.
Please provide a plan as a deployer argument or packaged in the EJB
JAR at META-INF/openejb-jar.xml
org.apache.geronimo.common.DeploymentException: Currently a Geronimo
deployment plan is required for an EJB module. Please provide a plan
as a deployer argument or packaged in the EJB JAR at
META-INF/openejb-jar.xml
at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:166)
at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:134)
at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$$FastClassByCGLIB$$cd80af20.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$d2a1ea22.createModule(<generated>)
at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:723)
at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:355)
at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:257)
at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at org.apache.geronimo.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$9cf6437.getDeploymentPlan(<generated>)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:114)
at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60)
at java.lang.Thread.run(Thread.java:595)
I have placed the plan file and ear that I am using at the following
location...
http://people.apache.org/~cjblythe/m2_deploy/
Thanks...
Chris
On 2/14/07, David Blevins <da...@visi.com> wrote:
>
>
> On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote:
>
> > Dain and David...
> >
> > Took a swag at deploying Daytrader on Geronimo 2.0-M2... During
> > deployment, it complained about the openejb-jar.xml file missing
> > from the EJB module. I added the one you provided earlier in this
> > chain, but for some reason it is still complaining that the openejb-
> > jar.xml file is missing from the EJB module. I think Matt is
> > probably running into the same issue...
> >
> > Does the or-mapping file also need to go in the ear/jar somewhere?
> > Should this work on M2? Is there anything else that needs to go
> > into the jar/ear?
> >
> > It really seems to me like we need way too many extra xml files to
> > deploy this thing.
>
> You shouldn't need any files in the ear, i.e. passing the plan as a
> parameter on the command line should work as always.
>
> Post the message text and a stack trace (if there is one) and I'll
> see if I can't find what part of the code is confused.
>
> -David
>
> >
> > Thanks...
> >
> > Chris
> >
> >
> >
> >
> >
> > On 2/7/07, Dain Sundstrom <da...@iq80.com> wrote:I just fix that
> > allows nested openejb plans to work correctly. This
> > was a big problem in the tck since all plans use the nested model.
> >
> > -dain
> >
> > On Feb 6, 2007, at 9:10 PM, Dain Sundstrom wrote:
> >
> > > OK, I think the conversion tool should be full working now.
> > >
> > > There were loads of tiny bugs causing deployments to fail
> > > especially around cmp. I tested the converter with the OpenEJB2
> > > itests which use almost every feature of OpenEJB2 and the
> > > application now deploys with out error now. Of course there are
> > > things sill unimplemented or ported to 3, so if you try to use
> > > those features, you will get an exception at runtime.
> > >
> > > Let us know if you find any problems with the converter.
> > >
> > > -dain
> > >
> > > On Feb 6, 2007, at 9:57 AM, Dain Sundstrom wrote:
> > >
> > >> On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
> > >>
> > >>> Haven't been able to get a full deploy of anything (tried
> > >>> daytrader and the v2 itests), but things are starting to look
> > >>> good with the converter. The basic conversion is happening and
> > >>> conversion of things like environment and abstract name queries
> > >>> are definitely getting ported over. Still see some hiccups in
> > >>> CMPs, but apps without CMPs may deploy just fine. Will look into
> > >>> it more when I get up.
> > >>>
> > >>> Dain, can you take a look at the persistence unit part of the
> > >>> rewritten EjbModuleBuilder. Seems something in the way i've
> > >>> reworked the code results in those not coming through so well.
> > >>
> > >> Looking at it now.
> > >>
> > >> -dain
> > >>
> > >
> >
> >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> > lets evolve, let the chips fall where they may." - Tyler Durden
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: Conversion Tool
Posted by David Blevins <da...@visi.com>.
On Feb 14, 2007, at 1:59 PM, Christopher Blythe wrote:
> Dain and David...
>
> Took a swag at deploying Daytrader on Geronimo 2.0-M2... During
> deployment, it complained about the openejb-jar.xml file missing
> from the EJB module. I added the one you provided earlier in this
> chain, but for some reason it is still complaining that the openejb-
> jar.xml file is missing from the EJB module. I think Matt is
> probably running into the same issue...
>
> Does the or-mapping file also need to go in the ear/jar somewhere?
> Should this work on M2? Is there anything else that needs to go
> into the jar/ear?
>
> It really seems to me like we need way too many extra xml files to
> deploy this thing.
You shouldn't need any files in the ear, i.e. passing the plan as a
parameter on the command line should work as always.
Post the message text and a stack trace (if there is one) and I'll
see if I can't find what part of the code is confused.
-David
>
> Thanks...
>
> Chris
>
>
>
>
>
> On 2/7/07, Dain Sundstrom <da...@iq80.com> wrote:I just fix that
> allows nested openejb plans to work correctly. This
> was a big problem in the tck since all plans use the nested model.
>
> -dain
>
> On Feb 6, 2007, at 9:10 PM, Dain Sundstrom wrote:
>
> > OK, I think the conversion tool should be full working now.
> >
> > There were loads of tiny bugs causing deployments to fail
> > especially around cmp. I tested the converter with the OpenEJB2
> > itests which use almost every feature of OpenEJB2 and the
> > application now deploys with out error now. Of course there are
> > things sill unimplemented or ported to 3, so if you try to use
> > those features, you will get an exception at runtime.
> >
> > Let us know if you find any problems with the converter.
> >
> > -dain
> >
> > On Feb 6, 2007, at 9:57 AM, Dain Sundstrom wrote:
> >
> >> On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
> >>
> >>> Haven't been able to get a full deploy of anything (tried
> >>> daytrader and the v2 itests), but things are starting to look
> >>> good with the converter. The basic conversion is happening and
> >>> conversion of things like environment and abstract name queries
> >>> are definitely getting ported over. Still see some hiccups in
> >>> CMPs, but apps without CMPs may deploy just fine. Will look into
> >>> it more when I get up.
> >>>
> >>> Dain, can you take a look at the persistence unit part of the
> >>> rewritten EjbModuleBuilder. Seems something in the way i've
> >>> reworked the code results in those not coming through so well.
> >>
> >> Looking at it now.
> >>
> >> -dain
> >>
> >
>
>
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
Re: Conversion Tool
Posted by Christopher Blythe <cj...@gmail.com>.
Dain and David...
Took a swag at deploying Daytrader on Geronimo 2.0-M2... During deployment,
it complained about the openejb-jar.xml file missing from the EJB module. I
added the one you provided earlier in this chain, but for some reason it is
still complaining that the openejb-jar.xml file is missing from the EJB
module. I think Matt is probably running into the same issue...
Does the or-mapping file also need to go in the ear/jar somewhere? Should
this work on M2? Is there anything else that needs to go into the jar/ear?
It really seems to me like we need way too many extra xml files to deploy
this thing.
Thanks...
Chris
On 2/7/07, Dain Sundstrom <da...@iq80.com> wrote:
>
> I just fix that allows nested openejb plans to work correctly. This
> was a big problem in the tck since all plans use the nested model.
>
> -dain
>
> On Feb 6, 2007, at 9:10 PM, Dain Sundstrom wrote:
>
> > OK, I think the conversion tool should be full working now.
> >
> > There were loads of tiny bugs causing deployments to fail
> > especially around cmp. I tested the converter with the OpenEJB2
> > itests which use almost every feature of OpenEJB2 and the
> > application now deploys with out error now. Of course there are
> > things sill unimplemented or ported to 3, so if you try to use
> > those features, you will get an exception at runtime.
> >
> > Let us know if you find any problems with the converter.
> >
> > -dain
> >
> > On Feb 6, 2007, at 9:57 AM, Dain Sundstrom wrote:
> >
> >> On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
> >>
> >>> Haven't been able to get a full deploy of anything (tried
> >>> daytrader and the v2 itests), but things are starting to look
> >>> good with the converter. The basic conversion is happening and
> >>> conversion of things like environment and abstract name queries
> >>> are definitely getting ported over. Still see some hiccups in
> >>> CMPs, but apps without CMPs may deploy just fine. Will look into
> >>> it more when I get up.
> >>>
> >>> Dain, can you take a look at the persistence unit part of the
> >>> rewritten EjbModuleBuilder. Seems something in the way i've
> >>> reworked the code results in those not coming through so well.
> >>
> >> Looking at it now.
> >>
> >> -dain
> >>
> >
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: Conversion Tool
Posted by Dain Sundstrom <da...@iq80.com>.
I just fix that allows nested openejb plans to work correctly. This
was a big problem in the tck since all plans use the nested model.
-dain
On Feb 6, 2007, at 9:10 PM, Dain Sundstrom wrote:
> OK, I think the conversion tool should be full working now.
>
> There were loads of tiny bugs causing deployments to fail
> especially around cmp. I tested the converter with the OpenEJB2
> itests which use almost every feature of OpenEJB2 and the
> application now deploys with out error now. Of course there are
> things sill unimplemented or ported to 3, so if you try to use
> those features, you will get an exception at runtime.
>
> Let us know if you find any problems with the converter.
>
> -dain
>
> On Feb 6, 2007, at 9:57 AM, Dain Sundstrom wrote:
>
>> On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
>>
>>> Haven't been able to get a full deploy of anything (tried
>>> daytrader and the v2 itests), but things are starting to look
>>> good with the converter. The basic conversion is happening and
>>> conversion of things like environment and abstract name queries
>>> are definitely getting ported over. Still see some hiccups in
>>> CMPs, but apps without CMPs may deploy just fine. Will look into
>>> it more when I get up.
>>>
>>> Dain, can you take a look at the persistence unit part of the
>>> rewritten EjbModuleBuilder. Seems something in the way i've
>>> reworked the code results in those not coming through so well.
>>
>> Looking at it now.
>>
>> -dain
>>
>
Re: Conversion Tool
Posted by Dain Sundstrom <da...@iq80.com>.
OK, I think the conversion tool should be full working now.
There were loads of tiny bugs causing deployments to fail especially
around cmp. I tested the converter with the OpenEJB2 itests which
use almost every feature of OpenEJB2 and the application now deploys
with out error now. Of course there are things sill unimplemented or
ported to 3, so if you try to use those features, you will get an
exception at runtime.
Let us know if you find any problems with the converter.
-dain
On Feb 6, 2007, at 9:57 AM, Dain Sundstrom wrote:
> On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
>
>> Haven't been able to get a full deploy of anything (tried
>> daytrader and the v2 itests), but things are starting to look good
>> with the converter. The basic conversion is happening and
>> conversion of things like environment and abstract name queries
>> are definitely getting ported over. Still see some hiccups in
>> CMPs, but apps without CMPs may deploy just fine. Will look into
>> it more when I get up.
>>
>> Dain, can you take a look at the persistence unit part of the
>> rewritten EjbModuleBuilder. Seems something in the way i've
>> reworked the code results in those not coming through so well.
>
> Looking at it now.
>
> -dain
>
Re: Conversion Tool
Posted by Dain Sundstrom <da...@iq80.com>.
On Feb 6, 2007, at 6:37 AM, David Blevins wrote:
> Haven't been able to get a full deploy of anything (tried daytrader
> and the v2 itests), but things are starting to look good with the
> converter. The basic conversion is happening and conversion of
> things like environment and abstract name queries are definitely
> getting ported over. Still see some hiccups in CMPs, but apps
> without CMPs may deploy just fine. Will look into it more when I
> get up.
>
> Dain, can you take a look at the persistence unit part of the
> rewritten EjbModuleBuilder. Seems something in the way i've
> reworked the code results in those not coming through so well.
Looking at it now.
-dain
Re: Conversion Tool
Posted by David Blevins <da...@visi.com>.
Haven't been able to get a full deploy of anything (tried daytrader
and the v2 itests), but things are starting to look good with the
converter. The basic conversion is happening and conversion of
things like environment and abstract name queries are definitely
getting ported over. Still see some hiccups in CMPs, but apps
without CMPs may deploy just fine. Will look into it more when I get
up.
Dain, can you take a look at the persistence unit part of the
rewritten EjbModuleBuilder. Seems something in the way i've reworked
the code results in those not coming through so well.
-David
On Jan 31, 2007, at 11:05 PM, David Blevins wrote:
> Reposting this info with more details.
>
> So the 10,000 foot perspective is that we are creating a conversion
> tool to convert the prior openejb-jar.xml into the new set of
> descriptors (geronimo-openejb.xml, new openejb-jar.xml, jpa entity-
> mappings.xml). It is expected that all existing plans will work
> and no one will have to or even *should* migrate just yet.
>
> We are doing this for two reasons:
>
> 1. There is significant investment in current descriptor format.
> These come to mind:
> - TCK
> - DayTrader
> - iTests
> - Samples
> - All documentation to date
> - All user-land apps to date
>
> 2. The new plans will not be stable for a good long while.
> Primary reasons are:
> - Continued work in integration (security, webservices,
> corba, etc.)
> - Continued work implementing JavaEE 5
>
>
> So the big motivation for the conversion tool is that with some
> hard work from Dain and I up front (and for a while really), we can
> save a few hundred developer and user hours over the next couple
> months. We're very close to having something running and hope to
> see something basically working by the end of the week.
>
> If we're really lucky after this week we can hide all the change
> under the conversion tool and no one (but the people working on and
> maintaining the conversion tool that is) will have to feel the pain
> or frustration while things move underneath. As we enable things
> like security people won't have to update their plans, we'll just
> add more conversion logic to port that information over and put it
> into action.
>
> I can say that the spirit of the new descriptor files is to fully
> embrace the "anti-descriptor" focus of Java EE 5 and to be as small
> and contain as little requirements as possible. Hopefully when the
> day comes to move over (not soon), it will more be a matter of
> deleting than adding. There will definitely be lots of
> experimentation in that area, so we'll see.
>
> As always, thoughts and questions very welcome and encouraged.
>
> -David
>
>
> On Jan 31, 2007, at 3:13 PM, Dain Sundstrom wrote:
>
>> I just checked in the working converter for CMP beans. There is a
>> fairly extensive test suite that converts the OpenEJB2 itests,
>> daytrader and the OpenEJB2 CMR mappings tests. For example, here
>> are the mappings for daytrader
>>
>>
>> ejb-jar.xml
>> -----------
>> https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
>> container/openejb-core/src/test/resources/convert/oej2/cmp/
>> daytrader/daytrader-ejb-jar.xml
>>
>> openejb-jar.xml
>> ---------------
>> https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
>> container/openejb-core/src/test/resources/convert/oej2/cmp/
>> daytrader/daytrader-openejb-jar.xml
>>
>>
>> And the final JPA mappings
>> --------------------------
>> https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
>> container/openejb-core/src/test/resources/convert/oej2/cmp/
>> daytrader/daytrader-orm.xml
>>
>>
>>
>> I hope to have the converter fully integrated into Geronimo in by
>> the end of the week.
>>
>> -dain
>>
>> On Jan 21, 2007, at 11:01 PM, David Blevins wrote:
>>
>>> On Jan 19, 2007, at 5:07 PM, David Blevins wrote:
>>>
>>>> Keep your ejb related plan files intact or a copy of them at
>>>> least. I'm going to try and write a conversion tool that will
>>>> at least handle trivial apps. A non-trivial app would be one
>>>> with CMPs. The new mapping.xml format for cmps is the jpa
>>>> mapping.xml and converting that will be a little more work.
>>>>
>>>> Nothing done yet, just announcing intentions.
>>>
>>> Ok, have a little progress on this. So far I am able to convert:
>>>
>>> - <environment> and children
>>> - <security> and children
>>> - <gbean> and children
>>> - <message-destination> and children
>>> - <persistence-context-ref> and children
>>>
>>> To see same converted document, look here:
>>>
>>> source: http://svn.apache.org/repos/asf/incubator/openejb/trunk/
>>> openejb3/container/openejb-jee/src/test/resources/openejb-jar-2-
>>> full.xml
>>> result: http://svn.apache.org/repos/asf/incubator/openejb/trunk/
>>> openejb3/container/openejb-jee/src/test/resources/geronimo-
>>> openejb-converted.xml
>>>
>>> It was a bit of work getting JAXB2 to work with our schemas
>>> because of duplicated elements combined with the fact that we
>>> allow invalid xml (i.e. no namespace at all). So I actually had
>>> to write a invalid 2 valid xml converter before I could get
>>> started on the openejb-jar.xml to geronimo-openejb.xml converter.
>>>
>>> Things should go faster from here. Will hack more in the morning.
>>>
>>> Not sure what the effort is going to be to convert the cmp
>>> information as that is a openejb-jar.xml 2 jpa mapping.xml
>>> conversion. Hoping Dain might have some input on that.
>>>
>>>
>>> -David
>>>
>>
>
Re: Conversion Tool and OpenEJB 3.0 integration status -- please read and ask questions :)
Posted by David Blevins <da...@visi.com>.
Reposting this info with more details.
So the 10,000 foot perspective is that we are creating a conversion
tool to convert the prior openejb-jar.xml into the new set of
descriptors (geronimo-openejb.xml, new openejb-jar.xml, jpa entity-
mappings.xml). It is expected that all existing plans will work and
no one will have to or even *should* migrate just yet.
We are doing this for two reasons:
1. There is significant investment in current descriptor format.
These come to mind:
- TCK
- DayTrader
- iTests
- Samples
- All documentation to date
- All user-land apps to date
2. The new plans will not be stable for a good long while.
Primary reasons are:
- Continued work in integration (security, webservices,
corba, etc.)
- Continued work implementing JavaEE 5
So the big motivation for the conversion tool is that with some hard
work from Dain and I up front (and for a while really), we can save a
few hundred developer and user hours over the next couple months.
We're very close to having something running and hope to see
something basically working by the end of the week.
If we're really lucky after this week we can hide all the change
under the conversion tool and no one (but the people working on and
maintaining the conversion tool that is) will have to feel the pain
or frustration while things move underneath. As we enable things
like security people won't have to update their plans, we'll just add
more conversion logic to port that information over and put it into
action.
I can say that the spirit of the new descriptor files is to fully
embrace the "anti-descriptor" focus of Java EE 5 and to be as small
and contain as little requirements as possible. Hopefully when the
day comes to move over (not soon), it will more be a matter of
deleting than adding. There will definitely be lots of
experimentation in that area, so we'll see.
As always, thoughts and questions very welcome and encouraged.
-David
On Jan 31, 2007, at 3:13 PM, Dain Sundstrom wrote:
> I just checked in the working converter for CMP beans. There is a
> fairly extensive test suite that converts the OpenEJB2 itests,
> daytrader and the OpenEJB2 CMR mappings tests. For example, here
> are the mappings for daytrader
>
>
> ejb-jar.xml
> -----------
> https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
> container/openejb-core/src/test/resources/convert/oej2/cmp/
> daytrader/daytrader-ejb-jar.xml
>
> openejb-jar.xml
> ---------------
> https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
> container/openejb-core/src/test/resources/convert/oej2/cmp/
> daytrader/daytrader-openejb-jar.xml
>
>
> And the final JPA mappings
> --------------------------
> https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
> container/openejb-core/src/test/resources/convert/oej2/cmp/
> daytrader/daytrader-orm.xml
>
>
>
> I hope to have the converter fully integrated into Geronimo in by
> the end of the week.
>
> -dain
>
> On Jan 21, 2007, at 11:01 PM, David Blevins wrote:
>
>> On Jan 19, 2007, at 5:07 PM, David Blevins wrote:
>>
>>> Keep your ejb related plan files intact or a copy of them at
>>> least. I'm going to try and write a conversion tool that will at
>>> least handle trivial apps. A non-trivial app would be one with
>>> CMPs. The new mapping.xml format for cmps is the jpa mapping.xml
>>> and converting that will be a little more work.
>>>
>>> Nothing done yet, just announcing intentions.
>>
>> Ok, have a little progress on this. So far I am able to convert:
>>
>> - <environment> and children
>> - <security> and children
>> - <gbean> and children
>> - <message-destination> and children
>> - <persistence-context-ref> and children
>>
>> To see same converted document, look here:
>>
>> source: http://svn.apache.org/repos/asf/incubator/openejb/trunk/
>> openejb3/container/openejb-jee/src/test/resources/openejb-jar-2-
>> full.xml
>> result: http://svn.apache.org/repos/asf/incubator/openejb/trunk/
>> openejb3/container/openejb-jee/src/test/resources/geronimo-openejb-
>> converted.xml
>>
>> It was a bit of work getting JAXB2 to work with our schemas
>> because of duplicated elements combined with the fact that we
>> allow invalid xml (i.e. no namespace at all). So I actually had
>> to write a invalid 2 valid xml converter before I could get
>> started on the openejb-jar.xml to geronimo-openejb.xml converter.
>>
>> Things should go faster from here. Will hack more in the morning.
>>
>> Not sure what the effort is going to be to convert the cmp
>> information as that is a openejb-jar.xml 2 jpa mapping.xml
>> conversion. Hoping Dain might have some input on that.
>>
>>
>> -David
>>
>
Re: Conversion Tool
Posted by Dain Sundstrom <da...@iq80.com>.
I just checked in the working converter for CMP beans. There is a
fairly extensive test suite that converts the OpenEJB2 itests,
daytrader and the OpenEJB2 CMR mappings tests. For example, here are
the mappings for daytrader
ejb-jar.xml
-----------
https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
container/openejb-core/src/test/resources/convert/oej2/cmp/daytrader/
daytrader-ejb-jar.xml
openejb-jar.xml
---------------
https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
container/openejb-core/src/test/resources/convert/oej2/cmp/daytrader/
daytrader-openejb-jar.xml
And the final JPA mappings
--------------------------
https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
container/openejb-core/src/test/resources/convert/oej2/cmp/daytrader/
daytrader-orm.xml
I hope to have the converter fully integrated into Geronimo in by the
end of the week.
-dain
On Jan 21, 2007, at 11:01 PM, David Blevins wrote:
> On Jan 19, 2007, at 5:07 PM, David Blevins wrote:
>
>> Keep your ejb related plan files intact or a copy of them at
>> least. I'm going to try and write a conversion tool that will at
>> least handle trivial apps. A non-trivial app would be one with
>> CMPs. The new mapping.xml format for cmps is the jpa mapping.xml
>> and converting that will be a little more work.
>>
>> Nothing done yet, just announcing intentions.
>
> Ok, have a little progress on this. So far I am able to convert:
>
> - <environment> and children
> - <security> and children
> - <gbean> and children
> - <message-destination> and children
> - <persistence-context-ref> and children
>
> To see same converted document, look here:
>
> source: http://svn.apache.org/repos/asf/incubator/openejb/trunk/
> openejb3/container/openejb-jee/src/test/resources/openejb-jar-2-
> full.xml
> result: http://svn.apache.org/repos/asf/incubator/openejb/trunk/
> openejb3/container/openejb-jee/src/test/resources/geronimo-openejb-
> converted.xml
>
> It was a bit of work getting JAXB2 to work with our schemas because
> of duplicated elements combined with the fact that we allow invalid
> xml (i.e. no namespace at all). So I actually had to write a
> invalid 2 valid xml converter before I could get started on the
> openejb-jar.xml to geronimo-openejb.xml converter.
>
> Things should go faster from here. Will hack more in the morning.
>
> Not sure what the effort is going to be to convert the cmp
> information as that is a openejb-jar.xml 2 jpa mapping.xml
> conversion. Hoping Dain might have some input on that.
>
>
> -David
>
Re: Conversion Tool
Posted by David Blevins <da...@visi.com>.
On Jan 19, 2007, at 5:07 PM, David Blevins wrote:
> Keep your ejb related plan files intact or a copy of them at
> least. I'm going to try and write a conversion tool that will at
> least handle trivial apps. A non-trivial app would be one with
> CMPs. The new mapping.xml format for cmps is the jpa mapping.xml
> and converting that will be a little more work.
>
> Nothing done yet, just announcing intentions.
Ok, have a little progress on this. So far I am able to convert:
- <environment> and children
- <security> and children
- <gbean> and children
- <message-destination> and children
- <persistence-context-ref> and children
To see same converted document, look here:
source: http://svn.apache.org/repos/asf/incubator/openejb/trunk/
openejb3/container/openejb-jee/src/test/resources/openejb-jar-2-full.xml
result: http://svn.apache.org/repos/asf/incubator/openejb/trunk/
openejb3/container/openejb-jee/src/test/resources/geronimo-openejb-
converted.xml
It was a bit of work getting JAXB2 to work with our schemas because
of duplicated elements combined with the fact that we allow invalid
xml (i.e. no namespace at all). So I actually had to write a invalid
2 valid xml converter before I could get started on the openejb-
jar.xml to geronimo-openejb.xml converter.
Things should go faster from here. Will hack more in the morning.
Not sure what the effort is going to be to convert the cmp
information as that is a openejb-jar.xml 2 jpa mapping.xml
conversion. Hoping Dain might have some input on that.
-David