I've found these errors usually result from some bundle not loading
properly, sometimes due to split packages, sometimes due to missing
constraints. I'm not sure why some load problems cause the build to
fail right away and some create problems much later.
Is there any indication of a problem earlier in the build?
thanks
david jencks
On Oct 19, 2009, at 8:23 PM, Rex Wang wrote:
I am trying build the trunk, but got the following error when
building j2ee-security.
[ERROR] Deployment failed due to
org.apache.geronimo.gbean.InvalidConfigurationException: Could not
load class org.apache.geronimo.security.SecurityServiceImpl
org
.apache
.geronimo
.gbean
.annotation
.AnnotationGBeanInfoFactory
.getGBeanInfo(AnnotationGBeanInfoFactory.java:40)
org
.apache
.geronimo
.gbean.MultiGBeanInfoFactory.getGBeanInfo(MultiGBeanInfoFactory.java:
66)
org
.apache
.geronimo
.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:113)
org
.apache
.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:108)
org
.apache
.geronimo
.deployment
.NamespaceDrivenBuilderCollection
.build(NamespaceDrivenBuilderCollection.java:46)
org
.apache
.geronimo
.deployment
.service
.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:
250)
org
.apache
.geronimo
.deployment
.service
.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:
209)
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun
.reflect
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org
.apache
.geronimo
.gbean
.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:
34)
org
.apache
.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
org
.apache
.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:854)
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:
245)
org
.apache
.geronimo
.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:517)
org
.apache
.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:
337)
org
.apache
.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:234)
org
.apache
.maven
.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:
490)
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:
694)
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:
535)
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeTaskSegments(DefaultLifecycleExecutor.java:348)
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:
60)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun
.reflect
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:
315)
org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:
430)
org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] could not package plugin
Embedded error:
org.apache.geronimo.gbean.InvalidConfigurationException: Could not
load class org.apache.geronimo.security.SecurityServiceImpl
But, this class is in place. Did anyone meet this?
-Rex
2009/10/19 chi runhua <[email protected]>
I am also interested in questions that Quintin raised. Hope the
answer could at least give us a big picture about what OSGI+Geronimo
will be.
Jeff C
On Sun, Oct 18, 2009 at 8:10 PM, Quintin Beukes
<[email protected]> wrote:
What exactly will be the affect OSGi will have on Geronimo?
Will it simply replace the plugin architecture?
And how will it, if at all, affect gbeans?
Quintin Beukes
On Sat, Oct 17, 2009 at 7:02 PM, David Jencks
<[email protected]> wrote:
>
> On Oct 17, 2009, at 5:04 AM, Quintin Beukes wrote:
>
>> Is it tricky to build? I would like to take a look at what you guys
>> have achieved so far :>
>
> It's beyond tricky, only the framework builds so far. For that,
you need to
> build some servicemix bundles locally. I'll try to publish the
servicemix
> bundles in the next few days. There have been a few posts
recently about
> how to get the framework to build, I would consult them for
additional
> hints.
>
> I'm trying to get plugins/j2ee to build: at that point it should
be possible
> for lots of people to work more or less independently in parallel
on fixing
> the other plugins.
>
> thanks
> david jencks
>
>>
>> Quintin Beukes
>>
>>
>>
>> On Fri, Oct 16, 2009 at 10:41 PM, David Jencks <[email protected]
>
>> wrote:
>>>
>>> Thanks Donald,
>>>
>>> I opened GERONIMO-4916 to track this, removed the old framework,
and
>>> moved
>>> over the osgi framework from sandbox.
>>>
>>> Now we just have to get it all to work :-)
>>>
>>> thanks
>>> david jencks
>>>
>>> On Oct 16, 2009, at 12:30 PM, Donald Woods wrote:
>>>
>>>> Branch of current pre-OSGi trunk has been created at -
>>>> https://svn.apache.org/repos/asf/geronimo/server/branches/
3.0_old/
>>>>
>>>> Let the OSGi merge begin....
>>>>
>>>>
>>>> -Donald
>>>>
>>>>
>>>> David Jencks wrote:
>>>>>
>>>>> I have the sandbox osgi framework working enough to start the
geronimo
>>>>> plugins, so I'm planning to move this work into trunk so we
can all
>>>>> pitch in
>>>>> more easily on getting the rest of geronimo running on osgi.
>>>>> There's one legal issue to take care of first, since I copied
in some
>>>>> plexus code that is not clearly available under asl2. The
code appears
>>>>> to
>>>>> have been derived from ant, so I'm going to see if we can get
the same
>>>>> results by importing or using ant code.
>>>>> I think that Donald is planning to make a branch off of trunk
for a
>>>>> convenient place to try out jpa2 stuff at least until we have
the
>>>>> equivalent
>>>>> working under osgi.
>>>>> If you have any concerns about this please speak up!
>>>>> thanks
>>>>> david jencks
>>>
>>>
>
>
