You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Quintin Beukes <qu...@last.za.net> on 2009/10/22 22:27:49 UTC
Singletons in Geronimo
Hey,
I got Singletons working in Geronimo. I've uploaded patches a few
times, but this is the first one where I feel farely stable. I've
tested it remotely (same machine, network and now over the internet).
I've uploaded @Startup singletons with dependency heirachies, misc
injections and so on. The modifications to OpenEJB also continue
working without Geronimo (tested in embedded mode).
Unfortunately the only way I could see how to get the @Startup working
was to modify OpenEJB to create a property which gives the
responsibility over to Geronimo, and there the only way was to create
a new GBean which has it's lifecycle doStart() called after all EJBs
are in the RUNNING state.
I couldn't find a better way.
Not sure if you guys will use this, though I uploaded it anyway. We
needed it urgently so I took it upon myself to get it running.
The 2 tickets are:
- https://issues.apache.org/jira/browse/OPENEJB-1092
- https://issues.apache.org/jira/browse/GERONIMO-4918
The Geronimo modification depends on the OpenEJB modification (for the
startup responsibility).
Are singletons planned for Geronimo 2.2? It might pose a problem,
because unless another method is found where OpenEJB doesn't need to
be modified, 3.1.2 would have to be revoted and rereleased.
Quintin Beukes
Re: Singletons in Geronimo
Posted by Quintin Beukes <qu...@skywalk.co.za>.
Hey,
Thanks for the analysis. Would be great to not have to rerelease
OpenEJB. I will have a look at doing anything needed to get it running
with the new modifications.
Finally, there is something else in the patches (other than the first
deadlock). When you invoke on a Singleton, itcauses the ReadWriteLock
to fail with a NullPointerException. It's related to the AccessTimeout
option for the SingletonContainer. If it doesn't specify a unit, then
the Duration object parses a null "unit". This causes the Unit object
in SingletonContainer to be set to null. I included in the patch a
check for null, which then causes a default of TimeUnit.SECONDS to be
used.
I think it's a good idea to modify OpenEJB for this in any case.
Unless you guys want a unit specified as a requirement? This might be
a bit counter intuitive, as one is used to simply specifying a number
for a timeout. And as I understand the source code for
Duration.parse(), the unit was made to be optional. So if this was the
intention, such a modification would be needed somewhere in OpenEJB.
OR in the GBean a unit could be "injected" into the timeout value. In
such a case problems could still occur when these values are
configured in a pure OpenEJB environment.
Though to avoid another release at this point, I'll simply add a unit
in Geronimo's config.xml.
So I'll make 2 patch sets. One for Geronimo at the point. And another
for OpenEJB's trunk. Let me know what you guys choose to do regarding
this unit.
Quintin Beukes
On Sat, Oct 24, 2009 at 3:29 AM, David Jencks <da...@yahoo.com> wrote:
> I attached a patch to GERONIMO-4918 that mostly reverses the dependencies
> between EjbModuleImpl and EjbDeployment so the deployments will start first.
> I think this is the main bit needed for David's idea on how to fix this
> without the wait() code in the geronimo wiring. There are some other
> changes needed before this will work such as removing the lifecycle methods
> from EjbDeployment. It also annotates EjbModuleImpl and adds wildcard
> support to collection valued references, I may well commit this last bit
> separately.
> thanks
> david jencks
> On Oct 23, 2009, at 5:33 PM, David Blevins wrote:
>
> On Oct 22, 2009, at 1:27 PM, Quintin Beukes wrote:
>
> Unfortunately the only way I could see how to get the @Startup working
>
> was to modify OpenEJB to create a property which gives the
>
> responsibility over to Geronimo, and there the only way was to create
>
> a new GBean which has it's lifecycle doStart() called after all EJBs
>
> are in the RUNNING state.
>
> I couldn't find a better way.
>
> Very impressive that you could find the problem at all as well as a workable
> fix. That code makes my brain hurt nearly every time I look at it.
>
> I checked in the more generic Singleton code. Left out the alternate
> startup code -- though it was actually pretty clever.
>
> This chunk of code in GeronimoThreadContextListener was not there when we
> wrote the initial integration, so I went digging around as to why it was
> added (there shouldn't be any locking code in the integration at all, much
> less wait/notify):
>
> At the 10,000 foot view, this chunk of code in GeronimoThreadContextListener
> must die:
>
> synchronized (deploymentInfo) {
> if (deploymentInfo.get(EjbDeployment.class) == null) {
> if (!deploymentInfo.isDestroyed()) {
> try {
> deploymentInfo.wait();
> } catch (InterruptedException e) {
> log.warn("Wait on deploymentInfo interrupted
> unexpectedly");
> }
> }
> }
> }
>
> Seems that code was added for GERONIMO-3780 which is essentially the same as
> the Singleton injection/lookup issue. Both issues boil down to the fact
> that lookups may happen inside the EjbModuleImpl.start() method where ejbs
> are created by OpenEJB. The wait/notify block works for MDBs as all their
> lookups will happen in other threads and not inside the startup thread.
> With Singletons this is not the case, so the startup thread ends up waiting
> on its own thread and a deadlock occurs.
>
> Ultimately, this is flawed and the data that is required in
> GeronimoThreadContextListener needs to be made available in some way before
> we call EjbModuleImpl.start(). I talked it over with David Jencks and the
> EjbDeployment objects are available when the EjbModuleImpl gbean is start.
> Then we should be able to hand them directly to the
> GeronimoThreadContextLister *before* asking OpenEJB to create the EJBs (and
> subsequently do lookups). When the contextEntered method is called we can
> complete any initialization as at that point we will have the
> CoreDeploymentInfo object and can hook it up with the EjbDeployment object.
>
> So we should be able to get a solution in there that removes all locking
> code, works for singletons and mdbs, and doesn't require a new OpenEJB
> release. Finger's crossed anyway :)
>
> Thanks for all the work bringing it this far. Really you did all the hard
> work. Very *very* appreciated.
>
> -David
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [1] http://issues.apache.org/jira/browse/GERONIMO-3780
>
>
Re: Singletons in Geronimo
Posted by David Blevins <da...@visi.com>.
On Oct 28, 2009, at 10:12 AM, Quintin Beukes wrote:
> Hey,
>
> Busy compiling. WIll let you know how the new changes work.
>
> So, what's the basic idea behind these changes? I had a quick look at
> the patches. Though I don't know enough about Geronimo and would need
> to carefully step through the code to understand the change.
About the simplest way I can think to describe it is that the startup
process was like this:
1. start EjbModuleGBean -- OpenEJB creates CoreDeploymentInfo objects
and deploys them into the containers.
2. start EjbDeploymentGBean -- Grabs the CoreDeploymentInfo, finishes
JNDI setup, installs itself into the CoreDeploymentInfo.
The problem is that "deploys them into containers" can involve JNDI
lookups and those require step 2 to have completed. Previously the
only beans that could actually get the chance to do a lookup on
"container.deploy()" was MDBs and that was bascially because the
MdbContainer would hook the bean up to the JMS Resource Adapter and
messages could start flowing in immediately -- even before we reached
step 2. So the workaround that was added (not by me) was to put that
synchronized block in so that lookups would wait till step 2
completed. That works fine for MDBs as they all get processed in
other threads so those "incoming message" threads would just hold for
a moment while we continued to start the app. With Singletons you get
a deadlock for very obvious reasons; a lookup in step 1 will cause the
startup thread to wait for itself to complete step 2. Obviously that
will never happen.
So I basically reworked the code so that 2 happens before 1 and
removed that synchronized block. I more or less worked around the
fact that EjbDeploymentGBean needs a reference to the not yet created
CoreDeploymentInfo object by using a java.util.concurrent.Future
object and some smarter code in the GeronimoThreadContextListener. So
the initialization we were doing in step 2 now happens on the fly the
first time the bean is invoked, whenever that is.
Hope that makes any kind of sense :)
-David
>
> Quintin Beukes
>
>
>
> On Wed, Oct 28, 2009 at 3:17 PM, David Blevins
> <da...@visi.com> wrote:
>>
>> On Oct 28, 2009, at 12:02 AM, David Jencks wrote:
>>
>>> Did you build all of geronimo? I wonder if this is caused by
>>> something
>>> like trying to run a plugin packaged under java6 on java5, which
>>> doesn't
>>> always work.
>>
>> Right, built from the root with an 'rm -r
>> ~/.m2/repository/org/apache/geronimo' for good measure.
>>
>>> will try a build here overnight...
>>
>> Great. Nice to have a second pair of eyes.
>>
>> -David
>>
>>
>>> On Oct 27, 2009, at 10:06 PM, David Blevins wrote:
>>>
>>>> The changes look good, though I seem to be running into an issue
>>>> creating
>>>> the car for the wadi stuff. Not sure what might be happening and
>>>> looking
>>>> for ideas.
>>>>
>>>> Here's the -e output:
>>>>
>>>> [INFO] [car:package]
>>>> [INFO] Packaging module configuration:
>>>> /Users/dblevins/work/geronimo-22-branch/plugins/openejb/openejb-
>>>> clustering-wadi/target/work/plan.xml
>>>> [INFO] GBean references are not using proxies
>>>> [INFO] ClassLoading behaviour has changed. The Original
>>>> Classloading
>>>> mode is in effect. If you are experiencing a problem
>>>> you can change the behaviour by specifying
>>>> -DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property.
>>>> Specify
>>>> ="safe" to revert to the original behaviour. This is a temporary
>>>> change
>>>> until we decide whether or not to make it
>>>> permanent for the 2.0 release
>>>> [INFO] Started deployer:
>>>> org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-
>>>> SNAPSHOT/car
>>>> [INFO] The Strict Manifest Classpath processing mode is in effect.
>>>> This option can be altered by specifying
>>>> -DXorg.apache.geronimo.deployment.LenientMFCP=true|false
>>>> Specify ="true" for more lenient processing such as ignoring
>>>> missing jars
>>>> and references that are not spec compliant.
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [ERROR] BUILD ERROR
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] could not package plugin
>>>>
>>>> Embedded error: Unable to create configuration for deployment
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] Trace
>>>> org.apache.maven.lifecycle.LifecycleExecutionException: could not
>>>> package
>>>> plugin
>>>> at
>>>> org
>>>> .apache
>>>> .maven
>>>> .lifecycle
>>>> .DefaultLifecycleExecutor
>>>> .executeGoals(DefaultLifecycleExecutor.java:584)
>>>> at
>>>> org
>>>> .apache
>>>> .maven
>>>> .lifecycle
>>>> .DefaultLifecycleExecutor
>>>> .executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
>>>> at
>>>> org
>>>> .apache
>>>> .maven
>>>> .lifecycle
>>>> .DefaultLifecycleExecutor
>>>> .executeGoal(DefaultLifecycleExecutor.java:479)
>>>> at
>>>> org
>>>> .apache
>>>> .maven
>>>> .lifecycle
>>>> .DefaultLifecycleExecutor
>>>> .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
>>>> at
>>>> org
>>>> .apache
>>>> .maven
>>>> .lifecycle
>>>> .DefaultLifecycleExecutor
>>>> .executeTaskSegments(DefaultLifecycleExecutor.java:292)
>>>> at
>>>> org
>>>> .apache
>>>> .maven
>>>> .lifecycle
>>>> .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:
>>>> 142)
>>>> at
>>>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
>>>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:
>>>> 129)
>>>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>> Method)
>>>> at
>>>> sun
>>>> .reflect
>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>> at
>>>> sun
>>>> .reflect
>>>> .DelegatingMethodAccessorImpl
>>>> .invoke(DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:592)
>>>> at
>>>> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>>>> at org.codehaus.classworlds.Launcher.launch(Launcher.java:
>>>> 255)
>>>> at
>>>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:
>>>> 430)
>>>> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>>>> Caused by: org.apache.maven.plugin.MojoExecutionException: could
>>>> not
>>>> package plugin
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:
>>>> 212)
>>>> at
>>>> org
>>>> .apache
>>>> .maven
>>>> .plugin
>>>> .DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
>>>> at
>>>> org
>>>> .apache
>>>> .maven
>>>> .lifecycle
>>>> .DefaultLifecycleExecutor
>>>> .executeGoals(DefaultLifecycleExecutor.java:559)
>>>> ... 16 more
>>>> Caused by: org.apache.geronimo.common.DeploymentException: Unable
>>>> to
>>>> create configuration for deployment
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .deployment
>>>> .DeploymentContext.createTempConfiguration(DeploymentContext.java:
>>>> 151)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .deployment.DeploymentContext.<init>(DeploymentContext.java:131)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .deployment.DeploymentContext.<init>(DeploymentContext.java:111)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .deployment
>>>> .service
>>>> .ServiceConfigBuilder
>>>> .buildConfiguration(ServiceConfigBuilder.java:227)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .deployment
>>>> .service
>>>> .ServiceConfigBuilder
>>>> .buildConfiguration(ServiceConfigBuilder.java:199)
>>>> at
>>>> org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>> Method)
>>>> at
>>>> sun
>>>> .reflect
>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>> at
>>>> sun
>>>> .reflect
>>>> .DelegatingMethodAccessorImpl
>>>> .invoke(DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:592)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .gbean
>>>> .runtime
>>>> .ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:
>>>> 130)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:
>>>> 850)
>>>> at
>>>> org
>>>> .apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
>>>> 237)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:483)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:309)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:
>>>> 209)
>>>> ... 18 more
>>>> Caused by: org.apache.geronimo.kernel.config.LifecycleException:
>>>> load of
>>>> org.apache.geronimo.configs/openejb-clustering-wadi/2.2-SNAPSHOT/
>>>> car failed
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .kernel
>>>> .config
>>>> .SimpleConfigurationManager
>>>> .loadConfiguration(SimpleConfigurationManager.java:316)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .deployment
>>>> .DeploymentConfigurationManager
>>>> .loadConfiguration(DeploymentConfigurationManager.java:115)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .kernel
>>>> .config
>>>> .SimpleConfigurationManager
>>>> .loadConfiguration(SimpleConfigurationManager.java:277)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .deployment
>>>> .DeploymentConfigurationManager
>>>> .loadConfiguration(DeploymentConfigurationManager.java:111)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .deployment
>>>> .DeploymentContext.createTempConfiguration(DeploymentContext.java:
>>>> 148)
>>>> ... 34 more
>>>> Caused by:
>>>> org.apache.geronimo.kernel.config.InvalidConfigException:
>>>> Error starting configuration gbean
>>>> org.apache.geronimo.configs/clustering/2.2-SNAPSHOT/car
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .kernel
>>>> .config
>>>> .SimpleConfigurationManager.load(SimpleConfigurationManager.java:
>>>> 341)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .deployment
>>>> .DeploymentConfigurationManager
>>>> .load(DeploymentConfigurationManager.java:119)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .kernel
>>>> .config
>>>> .SimpleConfigurationManager
>>>> .loadConfiguration(SimpleConfigurationManager.java:302)
>>>> ... 38 more
>>>> Caused by:
>>>> org.apache.geronimo.kernel.config.InvalidConfigException:
>>>> Unable to deserialize GBeanState in classloader:
>>>> [org.apache.geronimo.kernel.config.MultiParentClassLoader
>>>> id=org.apache.geronimo.configs/clustering/2.2-SNAPSHOT/car]
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .kernel
>>>> .config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:
>>>> 137)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .kernel
>>>> .config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:
>>>> 64)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:
>>>> 177)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo.kernel.config.Configuration.<init>(Configuration.java:
>>>> 295)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .kernel
>>>> .config
>>>> .SimpleConfigurationManager.load(SimpleConfigurationManager.java:
>>>> 337)
>>>> ... 40 more
>>>> Caused by: java.lang.NullPointerException
>>>> at
>>>> org.apache.geronimo.gbean.GBeanData.setAttribute(GBeanData.java:
>>>> 148)
>>>> at
>>>> org.apache.geronimo.gbean.GBeanData
>>>> $V0Externalizable.readExternal(GBeanData.java:336)
>>>> at
>>>> org.apache.geronimo.gbean.GBeanData.readExternal(GBeanData.java:
>>>> 282)
>>>> at
>>>> org
>>>> .apache
>>>> .geronimo
>>>> .kernel
>>>> .config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:
>>>> 124)
>>>> ... 44 more
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] Total time: 1 minute 14 seconds
>>>> [INFO] Finished at: Tue Oct 27 22:02:24 PDT 2009
>>>> [INFO] Final Memory: 58M/104M
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>>
>>>
>>>
>>
>>
>
Re: Singletons in Geronimo
Posted by Quintin Beukes <qu...@skywalk.co.za>.
Hey,
Busy compiling. WIll let you know how the new changes work.
So, what's the basic idea behind these changes? I had a quick look at
the patches. Though I don't know enough about Geronimo and would need
to carefully step through the code to understand the change.
Quintin Beukes
On Wed, Oct 28, 2009 at 3:17 PM, David Blevins <da...@visi.com> wrote:
>
> On Oct 28, 2009, at 12:02 AM, David Jencks wrote:
>
>> Did you build all of geronimo? I wonder if this is caused by something
>> like trying to run a plugin packaged under java6 on java5, which doesn't
>> always work.
>
> Right, built from the root with an 'rm -r
> ~/.m2/repository/org/apache/geronimo' for good measure.
>
>> will try a build here overnight...
>
> Great. Nice to have a second pair of eyes.
>
> -David
>
>
>> On Oct 27, 2009, at 10:06 PM, David Blevins wrote:
>>
>>> The changes look good, though I seem to be running into an issue creating
>>> the car for the wadi stuff. Not sure what might be happening and looking
>>> for ideas.
>>>
>>> Here's the -e output:
>>>
>>> [INFO] [car:package]
>>> [INFO] Packaging module configuration:
>>> /Users/dblevins/work/geronimo-22-branch/plugins/openejb/openejb-clustering-wadi/target/work/plan.xml
>>> [INFO] GBean references are not using proxies
>>> [INFO] ClassLoading behaviour has changed. The Original Classloading
>>> mode is in effect. If you are experiencing a problem
>>> you can change the behaviour by specifying
>>> -DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property. Specify
>>> ="safe" to revert to the original behaviour. This is a temporary change
>>> until we decide whether or not to make it
>>> permanent for the 2.0 release
>>> [INFO] Started deployer:
>>> org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car
>>> [INFO] The Strict Manifest Classpath processing mode is in effect.
>>> This option can be altered by specifying
>>> -DXorg.apache.geronimo.deployment.LenientMFCP=true|false
>>> Specify ="true" for more lenient processing such as ignoring missing jars
>>> and references that are not spec compliant.
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [ERROR] BUILD ERROR
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] could not package plugin
>>>
>>> Embedded error: Unable to create configuration for deployment
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Trace
>>> org.apache.maven.lifecycle.LifecycleExecutionException: could not package
>>> plugin
>>> at
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584)
>>> at
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
>>> at
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
>>> at
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
>>> at
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
>>> at
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
>>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
>>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
>>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:592)
>>> at
>>> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>>> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>>> at
>>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>>> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>>> Caused by: org.apache.maven.plugin.MojoExecutionException: could not
>>> package plugin
>>> at
>>> org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212)
>>> at
>>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
>>> at
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
>>> ... 16 more
>>> Caused by: org.apache.geronimo.common.DeploymentException: Unable to
>>> create configuration for deployment
>>> at
>>> org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:151)
>>> at
>>> org.apache.geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:131)
>>> at
>>> org.apache.geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:111)
>>> at
>>> org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:227)
>>> at
>>> org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199)
>>> at
>>> org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:592)
>>> at
>>> org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
>>> at
>>> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
>>> at
>>> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850)
>>> at
>>> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
>>> at
>>> org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:483)
>>> at
>>> org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:309)
>>> at
>>> org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:209)
>>> ... 18 more
>>> Caused by: org.apache.geronimo.kernel.config.LifecycleException: load of
>>> org.apache.geronimo.configs/openejb-clustering-wadi/2.2-SNAPSHOT/car failed
>>> at
>>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:316)
>>> at
>>> org.apache.geronimo.deployment.DeploymentConfigurationManager.loadConfiguration(DeploymentConfigurationManager.java:115)
>>> at
>>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:277)
>>> at
>>> org.apache.geronimo.deployment.DeploymentConfigurationManager.loadConfiguration(DeploymentConfigurationManager.java:111)
>>> at
>>> org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:148)
>>> ... 34 more
>>> Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
>>> Error starting configuration gbean
>>> org.apache.geronimo.configs/clustering/2.2-SNAPSHOT/car
>>> at
>>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.load(SimpleConfigurationManager.java:341)
>>> at
>>> org.apache.geronimo.deployment.DeploymentConfigurationManager.load(DeploymentConfigurationManager.java:119)
>>> at
>>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:302)
>>> ... 38 more
>>> Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
>>> Unable to deserialize GBeanState in classloader:
>>> [org.apache.geronimo.kernel.config.MultiParentClassLoader
>>> id=org.apache.geronimo.configs/clustering/2.2-SNAPSHOT/car]
>>> at
>>> org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:137)
>>> at
>>> org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:64)
>>> at
>>> org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:177)
>>> at
>>> org.apache.geronimo.kernel.config.Configuration.<init>(Configuration.java:295)
>>> at
>>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.load(SimpleConfigurationManager.java:337)
>>> ... 40 more
>>> Caused by: java.lang.NullPointerException
>>> at
>>> org.apache.geronimo.gbean.GBeanData.setAttribute(GBeanData.java:148)
>>> at
>>> org.apache.geronimo.gbean.GBeanData$V0Externalizable.readExternal(GBeanData.java:336)
>>> at
>>> org.apache.geronimo.gbean.GBeanData.readExternal(GBeanData.java:282)
>>> at
>>> org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:124)
>>> ... 44 more
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Total time: 1 minute 14 seconds
>>> [INFO] Finished at: Tue Oct 27 22:02:24 PDT 2009
>>> [INFO] Final Memory: 58M/104M
>>> [INFO]
>>> ------------------------------------------------------------------------
>>>
>>
>>
>
>
Re: Singletons in Geronimo
Posted by David Blevins <da...@visi.com>.
On Oct 28, 2009, at 12:02 AM, David Jencks wrote:
> Did you build all of geronimo? I wonder if this is caused by
> something like trying to run a plugin packaged under java6 on java5,
> which doesn't always work.
Right, built from the root with an 'rm -r ~/.m2/repository/org/apache/
geronimo' for good measure.
> will try a build here overnight...
Great. Nice to have a second pair of eyes.
-David
> On Oct 27, 2009, at 10:06 PM, David Blevins wrote:
>
>> The changes look good, though I seem to be running into an issue
>> creating the car for the wadi stuff. Not sure what might be
>> happening and looking for ideas.
>>
>> Here's the -e output:
>>
>> [INFO] [car:package]
>> [INFO] Packaging module configuration: /Users/dblevins/work/
>> geronimo-22-branch/plugins/openejb/openejb-clustering-wadi/target/
>> work/plan.xml
>> [INFO] GBean references are not using proxies
>> [INFO] ClassLoading behaviour has changed. The Original
>> Classloading mode is in effect. If you are experiencing a problem
>> you can change the behaviour by specifying -
>> DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property.
>> Specify
>> ="safe" to revert to the original behaviour. This is a temporary
>> change until we decide whether or not to make it
>> permanent for the 2.0 release
>> [INFO] Started deployer: org.apache.geronimo.framework/geronimo-
>> gbean-deployer/2.2-SNAPSHOT/car
>> [INFO] The Strict Manifest Classpath processing mode is in effect.
>> This option can be altered by specifying -
>> DXorg.apache.geronimo.deployment.LenientMFCP=true|false
>> Specify ="true" for more lenient processing such as ignoring
>> missing jars and references that are not spec compliant.
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] could not package plugin
>>
>> Embedded error: Unable to create configuration for deployment
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Trace
>> org.apache.maven.lifecycle.LifecycleExecutionException: could not
>> package plugin
>> at
>> org
>> .apache
>> .maven
>> .lifecycle
>> .DefaultLifecycleExecutor
>> .executeGoals(DefaultLifecycleExecutor.java:584)
>> at
>> org
>> .apache
>> .maven
>> .lifecycle
>> .DefaultLifecycleExecutor
>> .executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
>> at
>> org
>> .apache
>> .maven
>> .lifecycle
>> .DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:
>> 479)
>> at
>> org
>> .apache
>> .maven
>> .lifecycle
>> .DefaultLifecycleExecutor
>> .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
>> at
>> org
>> .apache
>> .maven
>> .lifecycle
>> .DefaultLifecycleExecutor
>> .executeTaskSegments(DefaultLifecycleExecutor.java:292)
>> at
>> org
>> .apache
>> .maven
>> .lifecycle
>> .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun
>> .reflect
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl
>> .invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:592)
>> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:
>> 315)
>> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>> at
>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>> Caused by: org.apache.maven.plugin.MojoExecutionException: could
>> not package plugin
>> at
>> org
>> .apache
>> .geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212)
>> at
>> org
>> .apache
>> .maven
>> .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:
>> 453)
>> at
>> org
>> .apache
>> .maven
>> .lifecycle
>> .DefaultLifecycleExecutor
>> .executeGoals(DefaultLifecycleExecutor.java:559)
>> ... 16 more
>> Caused by: org.apache.geronimo.common.DeploymentException: Unable
>> to create configuration for deployment
>> at
>> org
>> .apache
>> .geronimo
>> .deployment
>> .DeploymentContext.createTempConfiguration(DeploymentContext.java:
>> 151)
>> at
>> org
>> .apache
>> .geronimo
>> .deployment.DeploymentContext.<init>(DeploymentContext.java:131)
>> at
>> org
>> .apache
>> .geronimo
>> .deployment.DeploymentContext.<init>(DeploymentContext.java:111)
>> at
>> org
>> .apache
>> .geronimo
>> .deployment
>> .service
>> .ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:
>> 227)
>> at
>> org
>> .apache
>> .geronimo
>> .deployment
>> .service
>> .ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:
>> 199)
>> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun
>> .reflect
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl
>> .invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:592)
>> at
>> org
>> .apache
>> .geronimo
>> .gbean
>> .runtime
>> .ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
>> at
>> org
>> .apache
>> .geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:
>> 130)
>> at
>> org
>> .apache
>> .geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850)
>> at
>> org
>> .apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
>> 237)
>> at
>> org
>> .apache
>> .geronimo
>> .mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:483)
>> at
>> org
>> .apache
>> .geronimo
>> .mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:309)
>> at
>> org
>> .apache
>> .geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:209)
>> ... 18 more
>> Caused by: org.apache.geronimo.kernel.config.LifecycleException:
>> load of org.apache.geronimo.configs/openejb-clustering-wadi/2.2-
>> SNAPSHOT/car failed
>> at
>> org
>> .apache
>> .geronimo
>> .kernel
>> .config
>> .SimpleConfigurationManager
>> .loadConfiguration(SimpleConfigurationManager.java:316)
>> at
>> org
>> .apache
>> .geronimo
>> .deployment
>> .DeploymentConfigurationManager
>> .loadConfiguration(DeploymentConfigurationManager.java:115)
>> at
>> org
>> .apache
>> .geronimo
>> .kernel
>> .config
>> .SimpleConfigurationManager
>> .loadConfiguration(SimpleConfigurationManager.java:277)
>> at
>> org
>> .apache
>> .geronimo
>> .deployment
>> .DeploymentConfigurationManager
>> .loadConfiguration(DeploymentConfigurationManager.java:111)
>> at
>> org
>> .apache
>> .geronimo
>> .deployment
>> .DeploymentContext.createTempConfiguration(DeploymentContext.java:
>> 148)
>> ... 34 more
>> Caused by:
>> org.apache.geronimo.kernel.config.InvalidConfigException: Error
>> starting configuration gbean org.apache.geronimo.configs/clustering/
>> 2.2-SNAPSHOT/car
>> at
>> org
>> .apache
>> .geronimo
>> .kernel
>> .config
>> .SimpleConfigurationManager.load(SimpleConfigurationManager.java:341)
>> at
>> org
>> .apache
>> .geronimo
>> .deployment
>> .DeploymentConfigurationManager
>> .load(DeploymentConfigurationManager.java:119)
>> at
>> org
>> .apache
>> .geronimo
>> .kernel
>> .config
>> .SimpleConfigurationManager
>> .loadConfiguration(SimpleConfigurationManager.java:302)
>> ... 38 more
>> Caused by:
>> org.apache.geronimo.kernel.config.InvalidConfigException: Unable to
>> deserialize GBeanState in classloader:
>> [org.apache.geronimo.kernel.config.MultiParentClassLoader
>> id=org.apache.geronimo.configs/clustering/2.2-SNAPSHOT/car]
>> at
>> org
>> .apache
>> .geronimo
>> .kernel
>> .config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:
>> 137)
>> at
>> org
>> .apache
>> .geronimo
>> .kernel
>> .config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:64)
>> at
>> org
>> .apache
>> .geronimo
>> .kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:
>> 177)
>> at
>> org
>> .apache
>> .geronimo.kernel.config.Configuration.<init>(Configuration.java:295)
>> at
>> org
>> .apache
>> .geronimo
>> .kernel
>> .config
>> .SimpleConfigurationManager.load(SimpleConfigurationManager.java:337)
>> ... 40 more
>> Caused by: java.lang.NullPointerException
>> at org.apache.geronimo.gbean.GBeanData.setAttribute(GBeanData.java:
>> 148)
>> at org.apache.geronimo.gbean.GBeanData
>> $V0Externalizable.readExternal(GBeanData.java:336)
>> at org.apache.geronimo.gbean.GBeanData.readExternal(GBeanData.java:
>> 282)
>> at
>> org
>> .apache
>> .geronimo
>> .kernel
>> .config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:
>> 124)
>> ... 44 more
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 1 minute 14 seconds
>> [INFO] Finished at: Tue Oct 27 22:02:24 PDT 2009
>> [INFO] Final Memory: 58M/104M
>> [INFO]
>> ------------------------------------------------------------------------
>>
>
>
Re: Singletons in Geronimo
Posted by David Jencks <da...@yahoo.com>.
Did you build all of geronimo? I wonder if this is caused by
something like trying to run a plugin packaged under java6 on java5,
which doesn't always work.
will try a build here overnight...
thanks
david jencks
On Oct 27, 2009, at 10:06 PM, David Blevins wrote:
> The changes look good, though I seem to be running into an issue
> creating the car for the wadi stuff. Not sure what might be
> happening and looking for ideas.
>
> Here's the -e output:
>
> [INFO] [car:package]
> [INFO] Packaging module configuration: /Users/dblevins/work/
> geronimo-22-branch/plugins/openejb/openejb-clustering-wadi/target/
> work/plan.xml
> [INFO] GBean references are not using proxies
> [INFO] ClassLoading behaviour has changed. The Original
> Classloading mode is in effect. If you are experiencing a problem
> you can change the behaviour by specifying -
> DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property.
> Specify
> ="safe" to revert to the original behaviour. This is a temporary
> change until we decide whether or not to make it
> permanent for the 2.0 release
> [INFO] Started deployer: org.apache.geronimo.framework/geronimo-
> gbean-deployer/2.2-SNAPSHOT/car
> [INFO] The Strict Manifest Classpath processing mode is in effect.
> This option can be altered by specifying -
> DXorg.apache.geronimo.deployment.LenientMFCP=true|false
> Specify ="true" for more lenient processing such as ignoring missing
> jars and references that are not spec compliant.
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] could not package plugin
>
> Embedded error: Unable to create configuration for deployment
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: could not
> package plugin
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:
> 584)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:
> 479)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor
> .executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:592)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:
> 315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:
> 430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: could not
> package plugin
> at
> org
> .apache
> .geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:212)
> at
> org
> .apache
> .maven
> .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:
> 453)
> at
> org
> .apache
> .maven
> .lifecycle
> .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:
> 559)
> ... 16 more
> Caused by: org.apache.geronimo.common.DeploymentException: Unable to
> create configuration for deployment
> at
> org
> .apache
> .geronimo
> .deployment
> .DeploymentContext.createTempConfiguration(DeploymentContext.java:151)
> at
> org
> .apache
> .geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:
> 131)
> at
> org
> .apache
> .geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:
> 111)
> at
> org
> .apache
> .geronimo
> .deployment
> .service
> .ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:
> 227)
> at
> org
> .apache
> .geronimo
> .deployment
> .service
> .ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:
> 199)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:592)
> at
> org
> .apache
> .geronimo
> .gbean
> .runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:
> 34)
> at
> org
> .apache
> .geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
> at
> org
> .apache
> .geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
> 237)
> at
> org
> .apache
> .geronimo
> .mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:483)
> at
> org
> .apache
> .geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:
> 309)
> at
> org
> .apache
> .geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:209)
> ... 18 more
> Caused by: org.apache.geronimo.kernel.config.LifecycleException:
> load of org.apache.geronimo.configs/openejb-clustering-wadi/2.2-
> SNAPSHOT/car failed
> at
> org
> .apache
> .geronimo
> .kernel
> .config
> .SimpleConfigurationManager
> .loadConfiguration(SimpleConfigurationManager.java:316)
> at
> org
> .apache
> .geronimo
> .deployment
> .DeploymentConfigurationManager
> .loadConfiguration(DeploymentConfigurationManager.java:115)
> at
> org
> .apache
> .geronimo
> .kernel
> .config
> .SimpleConfigurationManager
> .loadConfiguration(SimpleConfigurationManager.java:277)
> at
> org
> .apache
> .geronimo
> .deployment
> .DeploymentConfigurationManager
> .loadConfiguration(DeploymentConfigurationManager.java:111)
> at
> org
> .apache
> .geronimo
> .deployment
> .DeploymentContext.createTempConfiguration(DeploymentContext.java:148)
> ... 34 more
> Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
> Error starting configuration gbean org.apache.geronimo.configs/
> clustering/2.2-SNAPSHOT/car
> at
> org
> .apache
> .geronimo
> .kernel
> .config
> .SimpleConfigurationManager.load(SimpleConfigurationManager.java:341)
> at
> org
> .apache
> .geronimo
> .deployment
> .DeploymentConfigurationManager
> .load(DeploymentConfigurationManager.java:119)
> at
> org
> .apache
> .geronimo
> .kernel
> .config
> .SimpleConfigurationManager
> .loadConfiguration(SimpleConfigurationManager.java:302)
> ... 38 more
> Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
> Unable to deserialize GBeanState in classloader:
> [org.apache.geronimo.kernel.config.MultiParentClassLoader
> id=org.apache.geronimo.configs/clustering/2.2-SNAPSHOT/car]
> at
> org
> .apache
> .geronimo
> .kernel
> .config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:137)
> at
> org
> .apache
> .geronimo
> .kernel
> .config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:64)
> at
> org
> .apache
> .geronimo
> .kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:177)
> at
> org
> .apache
> .geronimo.kernel.config.Configuration.<init>(Configuration.java:295)
> at
> org
> .apache
> .geronimo
> .kernel
> .config
> .SimpleConfigurationManager.load(SimpleConfigurationManager.java:337)
> ... 40 more
> Caused by: java.lang.NullPointerException
> at org.apache.geronimo.gbean.GBeanData.setAttribute(GBeanData.java:
> 148)
> at org.apache.geronimo.gbean.GBeanData
> $V0Externalizable.readExternal(GBeanData.java:336)
> at org.apache.geronimo.gbean.GBeanData.readExternal(GBeanData.java:
> 282)
> at
> org
> .apache
> .geronimo
> .kernel
> .config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:124)
> ... 44 more
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1 minute 14 seconds
> [INFO] Finished at: Tue Oct 27 22:02:24 PDT 2009
> [INFO] Final Memory: 58M/104M
> [INFO]
> ------------------------------------------------------------------------
>
Re: Singletons in Geronimo
Posted by David Blevins <da...@visi.com>.
The changes look good, though I seem to be running into an issue
creating the car for the wadi stuff. Not sure what might be happening
and looking for ideas.
Here's the -e output:
[INFO] [car:package]
[INFO] Packaging module configuration: /Users/dblevins/work/
geronimo-22-branch/plugins/openejb/openejb-clustering-wadi/target/work/
plan.xml
[INFO] GBean references are not using proxies
[INFO] ClassLoading behaviour has changed. The Original Classloading
mode is in effect. If you are experiencing a problem
you can change the behaviour by specifying -
DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property. Specify
="safe" to revert to the original behaviour. This is a temporary
change until we decide whether or not to make it
permanent for the 2.0 release
[INFO] Started deployer: org.apache.geronimo.framework/geronimo-gbean-
deployer/2.2-SNAPSHOT/car
[INFO] The Strict Manifest Classpath processing mode is in effect.
This option can be altered by specifying -
DXorg.apache.geronimo.deployment.LenientMFCP=true|false
Specify ="true" for more lenient processing such as ignoring missing
jars and references that are not spec compliant.
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] could not package plugin
Embedded error: Unable to create configuration for deployment
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: could not
package plugin
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:
584)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:
430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: could not
package plugin
at
org
.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:
212)
at
org
.apache
.maven
.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:
559)
... 16 more
Caused by: org.apache.geronimo.common.DeploymentException: Unable to
create configuration for deployment
at
org
.apache
.geronimo
.deployment
.DeploymentContext.createTempConfiguration(DeploymentContext.java:151)
at
org
.apache
.geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:
131)
at
org
.apache
.geronimo.deployment.DeploymentContext.<init>(DeploymentContext.java:
111)
at
org
.apache
.geronimo
.deployment
.service
.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:227)
at
org
.apache
.geronimo
.deployment
.service
.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:199)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
org
.apache
.geronimo
.gbean
.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org
.apache
.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at
org
.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:
850)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
237)
at
org
.apache
.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:
483)
at
org
.apache
.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:
309)
at
org
.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:
209)
... 18 more
Caused by: org.apache.geronimo.kernel.config.LifecycleException: load
of org.apache.geronimo.configs/openejb-clustering-wadi/2.2-SNAPSHOT/
car failed
at
org
.apache
.geronimo
.kernel
.config
.SimpleConfigurationManager
.loadConfiguration(SimpleConfigurationManager.java:316)
at
org
.apache
.geronimo
.deployment
.DeploymentConfigurationManager
.loadConfiguration(DeploymentConfigurationManager.java:115)
at
org
.apache
.geronimo
.kernel
.config
.SimpleConfigurationManager
.loadConfiguration(SimpleConfigurationManager.java:277)
at
org
.apache
.geronimo
.deployment
.DeploymentConfigurationManager
.loadConfiguration(DeploymentConfigurationManager.java:111)
at
org
.apache
.geronimo
.deployment
.DeploymentContext.createTempConfiguration(DeploymentContext.java:148)
... 34 more
Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
Error starting configuration gbean org.apache.geronimo.configs/
clustering/2.2-SNAPSHOT/car
at
org
.apache
.geronimo
.kernel
.config
.SimpleConfigurationManager.load(SimpleConfigurationManager.java:341)
at
org
.apache
.geronimo
.deployment
.DeploymentConfigurationManager
.load(DeploymentConfigurationManager.java:119)
at
org
.apache
.geronimo
.kernel
.config
.SimpleConfigurationManager
.loadConfiguration(SimpleConfigurationManager.java:302)
... 38 more
Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
Unable to deserialize GBeanState in classloader:
[org.apache.geronimo.kernel.config.MultiParentClassLoader
id=org.apache.geronimo.configs/clustering/2.2-SNAPSHOT/car]
at
org
.apache
.geronimo
.kernel
.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:137)
at
org
.apache
.geronimo
.kernel
.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:64)
at
org
.apache
.geronimo
.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:177)
at
org
.apache.geronimo.kernel.config.Configuration.<init>(Configuration.java:
295)
at
org
.apache
.geronimo
.kernel
.config
.SimpleConfigurationManager.load(SimpleConfigurationManager.java:337)
... 40 more
Caused by: java.lang.NullPointerException
at org.apache.geronimo.gbean.GBeanData.setAttribute(GBeanData.java:148)
at org.apache.geronimo.gbean.GBeanData
$V0Externalizable.readExternal(GBeanData.java:336)
at org.apache.geronimo.gbean.GBeanData.readExternal(GBeanData.java:282)
at
org
.apache
.geronimo
.kernel
.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:124)
... 44 more
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1 minute 14 seconds
[INFO] Finished at: Tue Oct 27 22:02:24 PDT 2009
[INFO] Final Memory: 58M/104M
[INFO]
------------------------------------------------------------------------
Re: Singletons in Geronimo
Posted by David Jencks <da...@yahoo.com>.
I attached a patch to GERONIMO-4918 that mostly reverses the
dependencies between EjbModuleImpl and EjbDeployment so the
deployments will start first. I think this is the main bit needed for
David's idea on how to fix this without the wait() code in the
geronimo wiring. There are some other changes needed before this will
work such as removing the lifecycle methods from EjbDeployment. It
also annotates EjbModuleImpl and adds wildcard support to collection
valued references, I may well commit this last bit separately.
thanks
david jencks
On Oct 23, 2009, at 5:33 PM, David Blevins wrote:
>
> On Oct 22, 2009, at 1:27 PM, Quintin Beukes wrote:
>
>> Unfortunately the only way I could see how to get the @Startup
>> working
>> was to modify OpenEJB to create a property which gives the
>> responsibility over to Geronimo, and there the only way was to create
>> a new GBean which has it's lifecycle doStart() called after all EJBs
>> are in the RUNNING state.
>>
>> I couldn't find a better way.
>
> Very impressive that you could find the problem at all as well as a
> workable fix. That code makes my brain hurt nearly every time I
> look at it.
>
> I checked in the more generic Singleton code. Left out the
> alternate startup code -- though it was actually pretty clever.
>
> This chunk of code in GeronimoThreadContextListener was not there
> when we wrote the initial integration, so I went digging around as
> to why it was added (there shouldn't be any locking code in the
> integration at all, much less wait/notify):
>
> At the 10,000 foot view, this chunk of code in
> GeronimoThreadContextListener must die:
>
> synchronized (deploymentInfo) {
> if (deploymentInfo.get(EjbDeployment.class) == null) {
> if (!deploymentInfo.isDestroyed()) {
> try {
> deploymentInfo.wait();
> } catch (InterruptedException e) {
> log.warn("Wait on deploymentInfo interrupted
> unexpectedly");
> }
> }
> }
> }
>
> Seems that code was added for GERONIMO-3780 which is essentially the
> same as the Singleton injection/lookup issue. Both issues boil down
> to the fact that lookups may happen inside the EjbModuleImpl.start()
> method where ejbs are created by OpenEJB. The wait/notify block
> works for MDBs as all their lookups will happen in other threads and
> not inside the startup thread. With Singletons this is not the
> case, so the startup thread ends up waiting on its own thread and a
> deadlock occurs.
>
> Ultimately, this is flawed and the data that is required in
> GeronimoThreadContextListener needs to be made available in some way
> before we call EjbModuleImpl.start(). I talked it over with David
> Jencks and the EjbDeployment objects are available when the
> EjbModuleImpl gbean is start. Then we should be able to hand them
> directly to the GeronimoThreadContextLister *before* asking OpenEJB
> to create the EJBs (and subsequently do lookups). When the
> contextEntered method is called we can complete any initialization
> as at that point we will have the CoreDeploymentInfo object and can
> hook it up with the EjbDeployment object.
>
> So we should be able to get a solution in there that removes all
> locking code, works for singletons and mdbs, and doesn't require a
> new OpenEJB release. Finger's crossed anyway :)
>
> Thanks for all the work bringing it this far. Really you did all
> the hard work. Very *very* appreciated.
>
> -David
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [1] http://issues.apache.org/jira/browse/GERONIMO-3780
Re: Singletons in Geronimo
Posted by David Blevins <da...@visi.com>.
On Oct 22, 2009, at 1:27 PM, Quintin Beukes wrote:
> Unfortunately the only way I could see how to get the @Startup working
> was to modify OpenEJB to create a property which gives the
> responsibility over to Geronimo, and there the only way was to create
> a new GBean which has it's lifecycle doStart() called after all EJBs
> are in the RUNNING state.
>
> I couldn't find a better way.
Very impressive that you could find the problem at all as well as a
workable fix. That code makes my brain hurt nearly every time I look
at it.
I checked in the more generic Singleton code. Left out the alternate
startup code -- though it was actually pretty clever.
This chunk of code in GeronimoThreadContextListener was not there when
we wrote the initial integration, so I went digging around as to why
it was added (there shouldn't be any locking code in the integration
at all, much less wait/notify):
At the 10,000 foot view, this chunk of code in
GeronimoThreadContextListener must die:
synchronized (deploymentInfo) {
if (deploymentInfo.get(EjbDeployment.class) == null) {
if (!deploymentInfo.isDestroyed()) {
try {
deploymentInfo.wait();
} catch (InterruptedException e) {
log.warn("Wait on deploymentInfo interrupted
unexpectedly");
}
}
}
}
Seems that code was added for GERONIMO-3780 which is essentially the
same as the Singleton injection/lookup issue. Both issues boil down
to the fact that lookups may happen inside the EjbModuleImpl.start()
method where ejbs are created by OpenEJB. The wait/notify block works
for MDBs as all their lookups will happen in other threads and not
inside the startup thread. With Singletons this is not the case, so
the startup thread ends up waiting on its own thread and a deadlock
occurs.
Ultimately, this is flawed and the data that is required in
GeronimoThreadContextListener needs to be made available in some way
before we call EjbModuleImpl.start(). I talked it over with David
Jencks and the EjbDeployment objects are available when the
EjbModuleImpl gbean is start. Then we should be able to hand them
directly to the GeronimoThreadContextLister *before* asking OpenEJB to
create the EJBs (and subsequently do lookups). When the
contextEntered method is called we can complete any initialization as
at that point we will have the CoreDeploymentInfo object and can hook
it up with the EjbDeployment object.
So we should be able to get a solution in there that removes all
locking code, works for singletons and mdbs, and doesn't require a new
OpenEJB release. Finger's crossed anyway :)
Thanks for all the work bringing it this far. Really you did all the
hard work. Very *very* appreciated.
-David
[1] http://issues.apache.org/jira/browse/GERONIMO-3780