Re: [RESULT] [VOTE] genesis 2.0 and geronimo-jaspic_1.0_spec 1.0
I don't know, But I keep seeing them in my local trunk build log as well as online trunk build log: http://people.apache.org/builds/geronimo/server/binaries/trunk/20090611/build-1500.log On Fri, Jun 12, 2009 at 11:54 AM, David Jencks wrote: > > On Jun 11, 2009, at 8:37 PM, Shawn Jiang wrote: > > Good to know, But I would like to mention that I can't access > http://geronimo.zones.apache.org:8081/nexus/content/repositories/geronimo from > China. > > > Where did that url come from? I don't think that nexus instance is running > any more. It doesn't have anything to do with this release the apache > release repo is at > > https://repository.apache.org/content/repositories/releases > > and everything gets synched to central on an at least daily basis. > > thanks > david jencks > > > I'm not sure if this repo will be the final geronimo repo. > > On Fri, Jun 12, 2009 at 9:41 AM, Kevan Miller wrote: > >> My belated +1. I reviewed source, build, and generated binaries. Then >> never got around to sending this note. >> >> --kevan >> >> >> On Jun 11, 2009, at 9:06 PM, David Jencks wrote: >> >> Vote has passed with 4 binding +1 votes from >>> djencks >>> dwoods >>> jaydm >>> rickmcguire >>> >>> and no other votes. >>> >>> I'll promote the artifacts and move the sites to their permanent >>> locations. >>> >>> many thanks >>> david jencks >>> >> > > > -- > Shawn > > > -- Shawn
Re: [RESULT] [VOTE] genesis 2.0 and geronimo-jaspic_1.0_spec 1.0
On Jun 11, 2009, at 8:37 PM, Shawn Jiang wrote: Good to know, But I would like to mention that I can't access http://geronimo.zones.apache.org:8081/nexus/content/repositories/geronimo from China. Where did that url come from? I don't think that nexus instance is running any more. It doesn't have anything to do with this release the apache release repo is at https://repository.apache.org/content/repositories/releases and everything gets synched to central on an at least daily basis. thanks david jencks I'm not sure if this repo will be the final geronimo repo. On Fri, Jun 12, 2009 at 9:41 AM, Kevan Miller wrote: My belated +1. I reviewed source, build, and generated binaries. Then never got around to sending this note. --kevan On Jun 11, 2009, at 9:06 PM, David Jencks wrote: Vote has passed with 4 binding +1 votes from djencks dwoods jaydm rickmcguire and no other votes. I'll promote the artifacts and move the sites to their permanent locations. many thanks david jencks -- Shawn
Re: [RESULT] [VOTE] genesis 2.0 and geronimo-jaspic_1.0_spec 1.0
Good to know, But I would like to mention that I can't access http://geronimo.zones.apache.org:8081/nexus/content/repositories/geronimo from China. I'm not sure if this repo will be the final geronimo repo. On Fri, Jun 12, 2009 at 9:41 AM, Kevan Miller wrote: > My belated +1. I reviewed source, build, and generated binaries. Then never > got around to sending this note. > > --kevan > > > On Jun 11, 2009, at 9:06 PM, David Jencks wrote: > > Vote has passed with 4 binding +1 votes from >> djencks >> dwoods >> jaydm >> rickmcguire >> >> and no other votes. >> >> I'll promote the artifacts and move the sites to their permanent >> locations. >> >> many thanks >> david jencks >> > -- Shawn
Re: [RESULT] [VOTE] genesis 2.0 and geronimo-jaspic_1.0_spec 1.0
My belated +1. I reviewed source, build, and generated binaries. Then never got around to sending this note. --kevan On Jun 11, 2009, at 9:06 PM, David Jencks wrote: Vote has passed with 4 binding +1 votes from djencks dwoods jaydm rickmcguire and no other votes. I'll promote the artifacts and move the sites to their permanent locations. many thanks david jencks
Re: [RESULT] [VOTE] genesis 2.0 and geronimo-jaspic_1.0_spec 1.0
Good news ! 2009/6/12 David Jencks > Vote has passed with 4 binding +1 votes from > djencks > dwoods > jaydm > rickmcguire > > and no other votes. > > I'll promote the artifacts and move the sites to their permanent locations. > > many thanks > david jencks > -- Ivan
[RESULT] [VOTE] genesis 2.0 and geronimo-jaspic_1.0_spec 1.0
Vote has passed with 4 binding +1 votes from djencks dwoods jaydm rickmcguire and no other votes. I'll promote the artifacts and move the sites to their permanent locations. many thanks david jencks
Re: [VOTE] genesis 2.0 and geronimo-jaspic_1.0_spec 1.0
+1 Jay David Jencks wrote: > This is a vote on two bits: > > genesis 2.0, a new build system foundation based on great work by Jason > Dillon and the new apache 6 pom and assembly plugin bits. > > geronimo-jaspic_1.0_spec 1.0 a new spec jar for the jsr 196 jaspic > spec. This passes the jaspic signature test and with appropriate bits > of jetty 7 passes the shared and servlet profile of the jaspic tck. > > The jar type stuff is staged at > > https://repository.apache.org/content/repositories/geronimo-staging-009/ > > In particular the source archives (which this vote is actually on) are at > > https://repository.apache.org/content/repositories/geronimo-staging-009/org/apache/geronimo/genesis/genesis/2.0/genesis-2.0-source-release.tar.gz > > https://repository.apache.org/content/repositories/geronimo-staging-009/org/apache/geronimo/genesis/genesis/2.0/genesis-2.0-source-release.zip > > > and > > https://repository.apache.org/content/repositories/geronimo-staging-009/org/apache/geronimo/specs/geronimo-jaspic_1.0_spec/1.0/geronimo-jaspic_1.0_spec-1.0-source-release.tar.gz > > https://repository.apache.org/content/repositories/geronimo-staging-009/org/apache/geronimo/specs/geronimo-jaspic_1.0_spec/1.0/geronimo-jaspic_1.0_spec-1.0-source-release.zip > > > with the signatures in the obvious place next to them. > > The sites are staged at > > http://people.apache.org/~djencks/staging-site/ > > in particular > http://people.apache.org/~djencks/staging-site/maven/genesis/2.0/ > http://people.apache.org/~djencks/staging-site/maven/specs/geronimo-jaspic_1.0_spec/1.0/ > > > the jar type stuff is using the new apache nexus instance which works > great! > > > > [ ] +1 About time, yes yes yes > [ ] 0 Apathy > [ ] -1 No thanks because > > Please vote! > > Thanks to Jason Dillon for setting up most of the new genesis 2.0 system > and to Brian Fox for getting the nexus setup working for us! > > thanks > david jencks
Re: jta spec bundle issue in felix
Btw, not sure how you deployed the tx manager (if you did so), but there is an osgi bundle that i wrote to do that: http://svn.apache.org/repos/asf/felix/trunk/transaction/ On Thu, Jun 11, 2009 at 17:03, Guillaume Nodet wrote: > FWIW, Karaf solved the problem was explicitely removing the > javax.transaction package exported by the system bundle and deploying > the geronimo jta jar. > > On Wed, Jun 10, 2009 at 19:58, Jarek Gawor wrote: >> Hey all, >> >> I'm experimenting with JPA (OpenJPA specifically) in osgi environment >> and I ran into an interesting issue with the transaction API. The root >> of the problem is that the JDK provides a *subset* of the >> javax.transaction classes that the JTA specification defines. And that >> creates problems (i.e. java.lang.NoClassDefFoundError) at runtime >> depending on which bundle is used to wire in the transaction packages. >> >> The JVM transaction packages are exported via the system bundle (just >> like any other JVM package). On Felix, the JVM packages are exported >> with the version of the JVM you are running on (e.g. if you are >> running Java 5, the version attribute is set to 1.5.0). Our JTA spec >> bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API >> with version 1.1.0. >> >> Now, openjpa has the following javax.transaction imports: >> javax.transaction;version="1.1", javax.transaction.xa;version="1.1". >> On Felix, the container wires these imports using the system bundle >> since the system bundle exports these packages with higher version >> then the JTA bundle and that creates the NoClassDefFoundError >> problems. So, one would think that updating the version in our JTA >> spec bundle to something higher then 1.5 or 1.6 should work. And I >> think that should work but it doesn't seem to be working right on >> Felix. I don't know if this is a bug or if I'm just missing something >> or doing things wrong. When I install the openjpa bundle for the first >> time, its transaction imports get wired to our JTA bundle. But once I >> restart Felix, the openjpa transaction imports are wired to the system >> bundle maybe somebody knows what's going on here? >> >> Interestingly enough, Equinox exposes the JVM packages with version >> 0.0.0 and so I don't run into these NoClassDefFoundError errors there. >> >> One thing that worked for me reliably is when I updated the JTA spec >> bundle to be a fragment bundle (attaching itself to the system >> bundle). That way, the missing transaction classes can be loaded >> through the system bundle classloader. So, I'm wondering if we should >> turn the JTA spec bundle into a fragment bundle (just manifest >> updates) to deal with this problem? >> >> Jarek >> > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Resolved: (GERONIMO-4638) ForwardData held by GenericForwardServlet will be invalid after the target application is restarted
[ https://issues.apache.org/jira/browse/GERONIMO-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4638. --- Resolution: Fixed Fix Version/s: 2.2 2.1.5 Committed fixes to trunk (revision 783898) and branches/2.1 (revision 783899). > ForwardData held by GenericForwardServlet will be invalid after the target > application is restarted > --- > > Key: GERONIMO-4638 > URL: https://issues.apache.org/jira/browse/GERONIMO-4638 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.5, 2.2 > Environment: JDK 1.5.0 > Windows XP Pro >Reporter: Ivan >Assignee: Jarek Gawor >Priority: Minor > Fix For: 2.1.5, 2.2 > > > 2009-05-20 17:57:53,062 ERROR [[context-forward]] Servlet.service() for > servlet context-forward threw exception > java.lang.NullPointerException > at > org.apache.geronimo.console.servlet.GenericForwardServlet.doPost(GenericForwardServlet.java:147) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:125) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) > at java.lang.Thread.run(Thread.java:810) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4638) ForwardData held by GenericForwardServlet will be invalid after the target application is restarted
[ https://issues.apache.org/jira/browse/GERONIMO-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-4638: - Assignee: Jarek Gawor > ForwardData held by GenericForwardServlet will be invalid after the target > application is restarted > --- > > Key: GERONIMO-4638 > URL: https://issues.apache.org/jira/browse/GERONIMO-4638 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.5, 2.2 > Environment: JDK 1.5.0 > Windows XP Pro >Reporter: Ivan >Assignee: Jarek Gawor >Priority: Minor > > 2009-05-20 17:57:53,062 ERROR [[context-forward]] Servlet.service() for > servlet context-forward threw exception > java.lang.NullPointerException > at > org.apache.geronimo.console.servlet.GenericForwardServlet.doPost(GenericForwardServlet.java:147) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.geronimo.console.filter.XSSXSRFFilter.doFilter(XSSXSRFFilter.java:125) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) > at java.lang.Thread.run(Thread.java:810) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 783086
Geronimo Revision: 783086 built with tests included See the full build-1500.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090611/build-1500.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090611/unit-test-reports from the specified remote repositories: central (http://repo1.maven.org/maven2), geronimo (http://geronimo.zones.apache.org:8081/nexus/content/repositories/geronimo), codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Path to dependency: 1) org.apache.geronimo.modules:geronimo-activemq:jar:2.2-SNAPSHOT at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) 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:287) 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:585) 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.artifact.resolver.ArtifactResolutionException: Unable to get dependency information: Unable to read the metadata file for artifact 'org.apache.activemq:activemq-core:jar': Cannot find parent: org.apache.activemq:activemq-parent for project: null:activemq-core:bundle:null for project null:activemq-core:bundle:null org.apache.activemq:activemq-core:jar:5.3-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), geronimo (http://geronimo.zones.apache.org:8081/nexus/content/repositories/geronimo), codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Path to dependency: 1) org.apache.geronimo.modules:geronimo-activemq:jar:2.2-SNAPSHOT at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:403) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:76) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:300) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:288) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1415) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:405) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) ... 16 more Caused by: org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable to read the metadata file for artifact 'org.apache.activemq:activemq-core:jar': Cannot find parent: org.apache.activemq:activemq-parent for project: null:activemq-core:bundle:null for project null:activemq-core:bundle:null at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:135) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:380) ... 22 more Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.activemq:activemq-parent for project: null:activemq-core:bundle:null for project null:activemq-core:bundle:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenPro
[jira] Resolved: (GERONIMO-4661) Meaningless message displays while Geronimo ear plan contains modules that aren't in the ear
[ https://issues.apache.org/jira/browse/GERONIMO-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4661. --- Resolution: Fixed Fix Version/s: 2.2 2.1.5 Assignee: Jarek Gawor Committed slightly simplified fix to trunk (revision 783821) and branches/2.1 (revision 783823). Thanks! > Meaningless message displays while Geronimo ear plan contains modules that > aren't in the ear > > > Key: GERONIMO-4661 > URL: https://issues.apache.org/jira/browse/GERONIMO-4661 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.2 > Environment: Windows XP > JDK 1.5 >Reporter: Ivan >Assignee: Jarek Gawor >Priority: Minor > Fix For: 2.1.5, 2.2 > > Attachments: GERONIMO-4661.patch > > > While the ear plan contains modules which are not in the ear, the console > will show > Geronimo ear plan contains modules that aren't in the ear : false. It is not > friendly for user to correct the plan, > Please check the > \geronimo\plugins\j2ee\geronimo-j2ee-builder\src\main\java\org\apache\geronimo\j2ee\deployment\EARConfigBuilder.java > line 904 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4673) Geronimo cannot be run as a Windows service by configuring Java Service Wrapper
[ https://issues.apache.org/jira/browse/GERONIMO-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718522#action_12718522 ] Jarek Gawor commented on GERONIMO-4673: --- >From what directory did you execute the g_service.bat command? Looking at the >batch files, they assume they are executed from within the \bin >directory. If you execute it from any other directory outside of that, things >will fail finding the configuration file. My guess that's what is happening >here. If so, we probably just need to update the documentation since in 2.2 we >have a better way (non JSW based) of running Geronimo as a Windows service. > Geronimo cannot be run as a Windows service by configuring Java Service > Wrapper > --- > > Key: GERONIMO-4673 > URL: https://issues.apache.org/jira/browse/GERONIMO-4673 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: usability >Affects Versions: 2.2 > Environment: Sun JDK 1.6.0_17 + Windows XP + Geronimo 2.2-snapshot >Reporter: Ying Tang >Priority: Minor > Fix For: 2.2 > > > Geronimo 2.2 cannot be run as a Windows service with the help of Java Service > Wrapper 3.2.3. > Steps: > 1. Copy wrapper.exe, g_service.bat, Install_Geronimo.bat and > Uninstall_Geronimo.bat to /bin. > 2. Copy wrapper.jar and wrapper.dll to /lib. > 3. Copy wrapper.conf to /var/config. The wrapper.conf file has > been modified based on > http://www.nabble.com/Intalio-and-Geronimo-1.1-as-a-Windows-Service-tp23778055s134p23827726.html > 4. Wrapper log reports fatal error: > FATAL | wrapper | Unable to open configuration file. > D:\geronimo-tomcat6-javaee5-2.2-SNAPSHOT\bin\- > And > 1. Install Geronimo as a Windows service by running Install_Geronimo.bat, > after getting the configuration files and batch files prepared. > 2. Launch the service in Windows service tool. > 3. Error occurs: The computer cannot start the service. > Error code 1067:The process has been terminated unexpectly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-578) Integrate server adapter 1.1 in GEP 2.2
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718520#action_12718520 ] Kevan Miller commented on GERONIMODEVTOOLS-578: --- IIRC, we didn't support 1.1 servers, because we didn't have any motivation to do the work. And older GEP server adapters could support 1.1 servers. However, if older GEP server adapters won't work on recent versions of Eclipse, then there may have been a gap in our reasoning... If Delos or Tim want to add this support (and test it), I don't see why that would be a problem. Unless you feel that it is detrimental to the functionality of GEP or is unsupportable, then I don't see why this would be an issue. > Integrate server adapter 1.1 in GEP 2.2 > --- > > Key: GERONIMODEVTOOLS-578 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-578 > Project: Geronimo-Devtools > Issue Type: New Feature > Components: eclipse-plugin >Affects Versions: 2.2.0 >Reporter: Delos Dai >Assignee: Tim McConnell > Fix For: 2.2.0 > > > Need to integrate server adapter 1.1 in new GEP release to support Eclipse > 3.4 & 3.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4676) Incorrect USAGE_MSG of cxf-tools script
[
https://issues.apache.org/jira/browse/GERONIMO-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor resolved GERONIMO-4676.
---
Resolution: Fixed
Fix Version/s: 2.2
Assignee: Jarek Gawor
Committed the patch to trunk (revision 783814). Thanks for the patch!
> Incorrect USAGE_MSG of cxf-tools script
> ---
>
> Key: GERONIMO-4676
> URL: https://issues.apache.org/jira/browse/GERONIMO-4676
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: commands
>Affects Versions: 2.2
> Environment: Ubuntu 8.0.4+JDK 1.6.0
>Reporter: Chi Runhua
>Assignee: Jarek Gawor
>Priority: Minor
> Fix For: 2.2
>
> Attachments: GERONIMO-4676.patch
>
>
> 1. run ./cxf-tools.sh in terminal;
> 2. Usage of cxf-tools shows up as followed:
> {color:white}
> {noformat:borderStyle=solid|bgColor=#00}
> Usage: jaxws-tools
> where is:
> java2ws - generate portable artifacts from class
> wsdl2java - generate portable artifacts from WSDL
> {noformat}
> {color}
> Expected result: the message should be
> Usage: {color:red}cxf-tools{color}
> I'm providing a patch for this issue. please help to commit if it's correct.
> Jeff C
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: jta spec bundle issue in felix
FWIW, Karaf solved the problem was explicitely removing the javax.transaction package exported by the system bundle and deploying the geronimo jta jar. On Wed, Jun 10, 2009 at 19:58, Jarek Gawor wrote: > Hey all, > > I'm experimenting with JPA (OpenJPA specifically) in osgi environment > and I ran into an interesting issue with the transaction API. The root > of the problem is that the JDK provides a *subset* of the > javax.transaction classes that the JTA specification defines. And that > creates problems (i.e. java.lang.NoClassDefFoundError) at runtime > depending on which bundle is used to wire in the transaction packages. > > The JVM transaction packages are exported via the system bundle (just > like any other JVM package). On Felix, the JVM packages are exported > with the version of the JVM you are running on (e.g. if you are > running Java 5, the version attribute is set to 1.5.0). Our JTA spec > bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API > with version 1.1.0. > > Now, openjpa has the following javax.transaction imports: > javax.transaction;version="1.1", javax.transaction.xa;version="1.1". > On Felix, the container wires these imports using the system bundle > since the system bundle exports these packages with higher version > then the JTA bundle and that creates the NoClassDefFoundError > problems. So, one would think that updating the version in our JTA > spec bundle to something higher then 1.5 or 1.6 should work. And I > think that should work but it doesn't seem to be working right on > Felix. I don't know if this is a bug or if I'm just missing something > or doing things wrong. When I install the openjpa bundle for the first > time, its transaction imports get wired to our JTA bundle. But once I > restart Felix, the openjpa transaction imports are wired to the system > bundle maybe somebody knows what's going on here? > > Interestingly enough, Equinox exposes the JVM packages with version > 0.0.0 and so I don't run into these NoClassDefFoundError errors there. > > One thing that worked for me reliably is when I updated the JTA spec > bundle to be a fragment bundle (attaching itself to the system > bundle). That way, the missing transaction classes can be loaded > through the system bundle classloader. So, I'm wondering if we should > turn the JTA spec bundle into a fragment bundle (just manifest > updates) to deal with this problem? > > Jarek > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: jta spec bundle issue in felix
Also, would it be possible to get it working by specify a version range, like: Import-Package:javax.transaction;version=”[1.1,1.2)” Lin On Wed, Jun 10, 2009 at 4:06 PM, Lin Sun wrote: > Interesting prob... I wonder if you add the split-package (see > http://www.aqute.biz/Code/Bnd) when you export the jta packages would > solve the prob for you. This is what I have been using but I only > tried Equinox so far. > > Export-Package = \ > javax.transaction;version=1.1;-split-package:=first, \ > javax.transaction.xa;version=1.1;-split-package:=first > > Lin > > On Wed, Jun 10, 2009 at 1:58 PM, Jarek Gawor wrote: >> Hey all, >> >> I'm experimenting with JPA (OpenJPA specifically) in osgi environment >> and I ran into an interesting issue with the transaction API. The root >> of the problem is that the JDK provides a *subset* of the >> javax.transaction classes that the JTA specification defines. And that >> creates problems (i.e. java.lang.NoClassDefFoundError) at runtime >> depending on which bundle is used to wire in the transaction packages. >> >> The JVM transaction packages are exported via the system bundle (just >> like any other JVM package). On Felix, the JVM packages are exported >> with the version of the JVM you are running on (e.g. if you are >> running Java 5, the version attribute is set to 1.5.0). Our JTA spec >> bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API >> with version 1.1.0. >> >> Now, openjpa has the following javax.transaction imports: >> javax.transaction;version="1.1", javax.transaction.xa;version="1.1". >> On Felix, the container wires these imports using the system bundle >> since the system bundle exports these packages with higher version >> then the JTA bundle and that creates the NoClassDefFoundError >> problems. So, one would think that updating the version in our JTA >> spec bundle to something higher then 1.5 or 1.6 should work. And I >> think that should work but it doesn't seem to be working right on >> Felix. I don't know if this is a bug or if I'm just missing something >> or doing things wrong. When I install the openjpa bundle for the first >> time, its transaction imports get wired to our JTA bundle. But once I >> restart Felix, the openjpa transaction imports are wired to the system >> bundle maybe somebody knows what's going on here? >> >> Interestingly enough, Equinox exposes the JVM packages with version >> 0.0.0 and so I don't run into these NoClassDefFoundError errors there. >> >> One thing that worked for me reliably is when I updated the JTA spec >> bundle to be a fragment bundle (attaching itself to the system >> bundle). That way, the missing transaction classes can be loaded >> through the system bundle classloader. So, I'm wondering if we should >> turn the JTA spec bundle into a fragment bundle (just manifest >> updates) to deal with this problem? >> >> Jarek >> >
[jira] Commented: (GERONIMODEVTOOLS-492) GEP v2.1.1 installation error in eclipse Ganymede JEE package
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718426#action_12718426 ] Ted Kirby commented on GERONIMODEVTOOLS-492: Thanks for the workaround, Carlos. This problem should have been fixed in GEP 2.1.2. Did you try the original scenario with GEP 2.1.4 and it failed? If that is the case, we should either re-open this JIRA, or open an new one. What version of eclipse did you use, and what were the error messages you got? Thanks. > GEP v2.1.1 installation error in eclipse Ganymede JEE package > - > > Key: GERONIMODEVTOOLS-492 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-492 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.1 > Environment: OS: Windows XP SP2 and Ubuntu 8.04 > Eclipse: Eclipse Ganymede JEE package, based on Version: 3.4.0 Build id: > I20080617-2000 > JDK: IBM SDK 5 sr6b >Reporter: Forrest Xia >Assignee: Ted Kirby > Fix For: 2.1.2 > > > Steps: > 1. Download and lauch eclipse ganymede > 2. click "Software Updates..."->"Available Software" to add a site point to > http://www.apache.org/dist/geronimo/eclipse/updates > 3. Choose "Geronimo v2.1 Server Adapter" to install > Symptom: > An install error shows up as follows: > Cannot complete the request. See the details. > Unsatisfied dependency: [org.apache.geronimo.v21.feature.feature.group 2.1.1] > requiredCapability: > org.eclipse.equinox.p2.iu/org.eclipse.jst.feature.group/[2.0.0,3.0.0) > Unsatisfied dependency: [org.apache.geronimo.feature.feature.group 2.1.1] > requiredCapability: > org.eclipse.equinox.p2.iu/org.eclipse.jst.feature.group/[2.0.0,3.0.0) > Unsatisfied dependency: [org.apache.geronimo.feature.feature.group 2.1.1] > requiredCapability: > org.eclipse.equinox.p2.iu/org.eclipse.jst.feature.group/[2.0.0,3.0.0) > Unsatisfied dependency: [org.apache.geronimo.v21.feature.feature.group 2.1.1] > requiredCapability: > org.eclipse.equinox.p2.iu/org.eclipse.jst.feature.group/[2.0.0,3.0.0) > Unsatisfied dependency: [org.apache.geronimo.v21.feature.feature.group 2.1.1] > requiredCapability: > org.eclipse.equinox.p2.iu/org.apache.geronimo.feature.feature.group/[2.1.1,2.1.1] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4679) many [ERROR] "The protocol for the JAR file's URL is not supported" in the build log when building geronimo on windows
[
https://issues.apache.org/jira/browse/GERONIMO-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718422#action_12718422
]
Donald Woods commented on GERONIMO-4679:
Changing it to DEBUG seems fine to me.
> many [ERROR] "The protocol for the JAR file's URL is not supported" in the
> build log when building geronimo on windows
> ---
>
> Key: GERONIMO-4679
> URL: https://issues.apache.org/jira/browse/GERONIMO-4679
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: kernel
>Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.1.4
> Environment: windows + trunk
>Reporter: Shawn Jiang
>Assignee: Shawn Jiang
>Priority: Minor
> Fix For: 2.1.5, 2.2
>
> Attachments: G4679.patch
>
>
> When building the Geronimo from source code on windows. There are
> many [ERROR] "The protocol for the JAR file's URL is not supported" in
> the build log like following.
> -
> [ERROR] The protocol for the JAR file's URL is not supported
> java.lang.UnsupportedOperationException: Only local file jars are
> supported jar:file:/D:/ws/gtrunck/
> server_repo/org/apache/geronimo/configs/system-database/2.2-SNAPSHOT/
> system-database-2.2-SNAPSHOT.ca
> r!/rar/tranql-connector-1.4.jar
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.cacheUrl(UrlResourceFinder.java:231)
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.rebuildClassPath(UrlResourceFinder.java
> :188)
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.addUrls(UrlResourceFinder.java:142)
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.addUrls(UrlResourceFinder.java:127)
>
> org.apache.geronimo.kernel.classloader.JarFileClassLoader$2.run(JarFileClassLoader.java:153)
>
> This message was thrown in UrlResourceFinder.cacheUrl() and logged as
> ERROR in UrlResourceFinder.rebuildClassPath().
> --
> } catch (UnsupportedOperationException ex) {
>// the protocol for the JAR file's URL is not
> supported. This can occur when
>// the jar file is embedded in an EAR or CAR
> file. Proceed but log the message.
>log.error("The protocol for the JAR file's URL
> is not supported", ex);
>continue;
>}
> -
> We'd better to log this as INFO or DEBUG instead of an ERROR so that the user
> will not be mislead by a lot of ERRORs in the build log.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-492) GEP v2.1.1 installation error in eclipse Ganymede JEE package
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718390#action_12718390 ] Carlos Ortega commented on GERONIMODEVTOOLS-492: Possible manual workaround (For Windows XP): == 1) Download latest version of GEP deployable.zip : ( I downloaded V2.1.4: geronimo-eclipse-plugin-2.1.4-deployable.zip from: http://archive.eu.apache.org/dist/geronimo/eclipse/2.1.4/ ) 2) Unzip to any directory you want: ( I used D:\Temp as my Download and Unzip directory, so after I unzipped the .zip file I got: D:\Temp\eclipse #directory features #subdirectory plugin #subdirectory LICENCE.txt # text file NOTICE.txt # text file PLUGIN_RELEASE-NOTES-2.1.4.txt #text file 3) Copy the contents of the recently created "features" subdirectory to the Eclipse installation "features" subdirectory. (I used C:\Program Files\eclipse as my eclipse installation directory, so I just copy the content: org.apache.geronimo.v21.feature_2.1.4 #subdirectory to: C:\Program Files\eclipse\features 4) Copy the contents of the recently created "plugins" subdirectory to the Eclipse installation "plugins" subdirectory. (I used C:\Program Files\eclipse as my eclipse installation directory, so I just copy the content: org.apache.geronimo.jee.v21.jaxbmodel_2.1.4.jar #jar file org.apache.geronimo.runtime.common_2.1.4.jar #jar file org.apache.geronimo.runtime.v20_2.1.4.jar #jar file org.apache.geronimo.runtime.v21_2.1.4.jar #jar file org.apache.geronimo.st.core_2.1.4.jar #jar file org.apache.geronimo.st.schemas_2.1.4.jar #jar file org.apache.geronimo.st.ui_2.1.4.jar #jar file org.apache.geronimo.st.v20.core_2.1.4.jar #jar file org.apache.geronimo.st.v20.ui_2.1.4.jar #jar file org.apache.geronimo.st.v21.core_2.1.4.jar #jar file org.apache.geronimo.st.v21.ui_2.1.4.jar #jar file to: C:\Program Files\eclipse\plugins 5) Edit the eclipse.ini file and change the parameters to increase the default setting for maximum PermGen size for your Eclipse installation (especially if you have installed Sun's JDK 1.5.0_x in Windows Platform) to prevent "java.lang.OutOfMemoryError: PermGen" errors: (In my case I edited the C:\Program Files\eclipse\eclipse.ini file, previously, the content was: -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256M -framework plugins\org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar -vmargs -Dosgi.requiredJavaVersion=1.5 -Xms40m -Xmx512m After edition, the final content was: -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256M -framework plugins\org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar -Dosgi.requiredJavaVersion=1.5 -Xms128m -Xmx512m -XX:MaxPermSize=128m 6 - Save the eclipse.ini file and restart eclipse with -clean option to clean any cache data used by the OSGi framework and eclipse runtime. (In my case, I typed: "C:\Program Files\eclipse\eclipse.exe" -clean In the Start/Run option within Windows. 7 - Verify the installation. There are 2 options: a) Verify the recently installed plugins from within "servers" view inside Eclipse: -Window / Show View / Servers -Right Click on Servers view / New / Server -Within the Apache folder there should be the "Apache Geronimo v 2.0 Server" and "Apache Geronimo v 2.1 Server" server types. b) Verify the "About Eclipse Platform" dialog. -Help / About Eclipse Platform -There should appear the "G" eronimo Logo. And if you click it, then there should appear the "About Eclipse Platform Features" dialog showing the Apache Geronimo v2.1 Server Adapter features. Hope this help. Regards > GEP v2.1.1 installation error in eclipse Ganymede JEE package > - > > Key: GERONIMODEVTOOLS-492 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-492 >
[jira] Commented: (GERONIMO-4679) many [ERROR] "The protocol for the JAR file's URL is not supported" in the build log when building geronimo on windows
[
https://issues.apache.org/jira/browse/GERONIMO-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718338#action_12718338
]
Shawn Jiang commented on GERONIMO-4679:
---
The url format itself is correct for both windows and non-windows. The reason
why we only see this error on windows is that geronimo uses JarFileClassLoader
for windows, MultiParentClassLoader for non-windows.
JarFileClassLoader is used to keep a copy of classpathes so that it can close
all the jar file handlers on windows. When it cache the file url, It will use
UrlResourceFinder. which will ignore non file: protocol urls and throw the
UnsupportedOperationException.
protected File cacheUrl(URL url) throws IOException {
if (!"file".equals(url.getProtocol())) {
// download the jar
throw new UnsupportedOperationException("Only local file jars are
supported " + url);
}
I think it's safe to turn the stack trace to warn/debug from error. Because
it's working as design.
> many [ERROR] "The protocol for the JAR file's URL is not supported" in the
> build log when building geronimo on windows
> ---
>
> Key: GERONIMO-4679
> URL: https://issues.apache.org/jira/browse/GERONIMO-4679
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: kernel
>Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.1.4
> Environment: windows + trunk
>Reporter: Shawn Jiang
>Assignee: Shawn Jiang
>Priority: Minor
> Fix For: 2.1.5, 2.2
>
> Attachments: G4679.patch
>
>
> When building the Geronimo from source code on windows. There are
> many [ERROR] "The protocol for the JAR file's URL is not supported" in
> the build log like following.
> -
> [ERROR] The protocol for the JAR file's URL is not supported
> java.lang.UnsupportedOperationException: Only local file jars are
> supported jar:file:/D:/ws/gtrunck/
> server_repo/org/apache/geronimo/configs/system-database/2.2-SNAPSHOT/
> system-database-2.2-SNAPSHOT.ca
> r!/rar/tranql-connector-1.4.jar
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.cacheUrl(UrlResourceFinder.java:231)
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.rebuildClassPath(UrlResourceFinder.java
> :188)
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.addUrls(UrlResourceFinder.java:142)
>
> org.apache.geronimo.kernel.classloader.UrlResourceFinder.addUrls(UrlResourceFinder.java:127)
>
> org.apache.geronimo.kernel.classloader.JarFileClassLoader$2.run(JarFileClassLoader.java:153)
>
> This message was thrown in UrlResourceFinder.cacheUrl() and logged as
> ERROR in UrlResourceFinder.rebuildClassPath().
> --
> } catch (UnsupportedOperationException ex) {
>// the protocol for the JAR file's URL is not
> supported. This can occur when
>// the jar file is embedded in an EAR or CAR
> file. Proceed but log the message.
>log.error("The protocol for the JAR file's URL
> is not supported", ex);
>continue;
>}
> -
> We'd better to log this as INFO or DEBUG instead of an ERROR so that the user
> will not be mislead by a lot of ERRORs in the build log.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4682) Unique snapshots does not work
[ https://issues.apache.org/jira/browse/GERONIMO-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718330#action_12718330 ] Trygve Hardersen commented on GERONIMO-4682: FYI the Nexus repository, and least the 1.3.4 Open Source version without any specific settings for this, will accept non-unique snapshots. It seems to me like the various Apache projects use both unique and non-unique snapshots: https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/activemq-core/5.3-SNAPSHOT/ https://repository.apache.org/content/repositories/snapshots/org/apache/camel/camel-core/2.0-SNAPSHOT/ My apologies for the strange characters in my previous post; I don't know the ASF JIRA syntax. > Unique snapshots does not work > -- > > Key: GERONIMO-4682 > URL: https://issues.apache.org/jira/browse/GERONIMO-4682 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.2 > Environment: OS X 10.5.7, Java 6, Maven 2.1.0 or 2.0.9 >Reporter: Trygve Hardersen >Priority: Minor > > When we deploy Geronimo to our local Maven repository using unique snapshots > we're unable to build our server later. The car-maven-plugin fails with > errors like this: > Cound not find parent configuration: > org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car > When Geronimo is deployed using non-unique snapshots, or when we build our > server on a box that also has Geronimo built on it locally, the error does > not occur. Here's the full trace of the error: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] could not package plugin > Embedded error: Unable to create configuration for deployment > Cound not find parent configuration: > org.apache.geronimo.configs/openejb-deployer/2.2-20090609.071606-2/car > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: could not package > plugin > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > 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:597) > 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:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 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.(DeploymentContext.java:131) > at > org.apache.geronimo.deployment.DeploymentContext.(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.Deploy
