geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: osgi >> trunk
Date Tue, 20 Oct 2009 07:03:44 GMT
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 <chirunhua@gmail.com>
> 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  
> <quintin@skywalk.co.za> 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  
> <david_jencks@yahoo.com> 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 <david_jencks@yahoo.com 
> >
> >> 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
> >>>
> >>>
> >
> >
>
>


Mime
View raw message