Re: ee apps in trunk
You can try running rm -rf var/cache in the assembly directory before starting the server. Jarek On Wed, Nov 25, 2009 at 8:20 PM, Forrest Xia wrote: > Hi Jarek, > > These WARNs just happen when starting up the server, not when building the > assembly. > > Today I will give some tries on: > 1. welcome-tomcat-server > 2. another simple sample built with car-maven-plugin > > I will post what I get. > > Thanks! > Forrest >
Re: A wierd problem when deploying applications to Geronimo on Lotus Foundation
I notice the terminal echo problem after running some geronimo shell scripts with exceptions happen. So far, I don't figure out why it happens. Will keep an eye on it later. Forrest
[jira] Created: (GERONIMO-4961) Update Spring version to 3.0.0-RC1
Update Spring version to 3.0.0-RC1 -- Key: GERONIMO-4961 URL: https://issues.apache.org/jira/browse/GERONIMO-4961 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: Plugins Affects Versions: 3.0 Reporter: Ivan Fix For: 3.0 Need to update spring components to latest 3.0.0-RC1, as the spring-web-2.5.6 does not accept ervlet spec version 3.0.0 -- 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: 884367
Geronimo Revision: 884367 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091125/build-2100.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091125/unit-test-reports for artifact: org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo.exist.com/maven2), ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo.exist.com/maven2), ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576) 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:37) at java.lang.reflect.Method.invoke(Method.java:599) 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.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo.exist.com/maven2), ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots
[jira] Closed: (GERONIMO-4678) Initial Japanese translation
[ https://issues.apache.org/jira/browse/GERONIMO-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa closed GERONIMO-4678. --- Resolution: Fixed Ivan, thanks! > Initial Japanese translation > > > Key: GERONIMO-4678 > URL: https://issues.apache.org/jira/browse/GERONIMO-4678 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Reporter: Kan Ogawa >Assignee: Kan Ogawa >Priority: Minor > Fix For: 2.2 > > Attachments: geronimo-v21_i18n-ja_G4485-G4532_v1.patch, > geronimo-v22_i18n-ja_G4474-G4484-G4517_v1.patch, > geronimo-v22_i18n-ja_G4759.patch, geronimo-v22_i18n-ja_v2.patch, > geronimo-v22_i18n-ja_v3.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: A wierd problem when deploying applications to Geronimo on Lotus Foundation
Are you writing the service script by yourself or using the Service Register script in Geronimo ? https://svn.apache.org/repos/asf/geronimo/server/branches/2.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/bin/gserviceReg.sh I never met the problem you described with the service registered by gserviceReg.sh On Thu, Nov 26, 2009 at 1:48 AM, Quintin Beukes wrote: > Regarding this same component, has anyone noticed the following problem. > > I start my Geronimo server with the following: > "$KMS_SERVER"/geronimo/bin/gsh -c "geronimo/start-server --logfile > '$KMS_SERVER/geronimo/var/log/startup.log'" & > USER=`<"$KMS_CONF/geronimo-auth-user"` > PASS=`<"$KMS_CONF/geronimo-auth-pass"` > "$KMS_SERVER"/geronimo/bin/gsh -c "geronimo/wait-for-server -u $USER -w > $PASS" > > When it finished starting a message is printed to the tune of > "Geronimo started in h:mm:ss.sss". Sometimes this works perfectly, > though on the odd occassion the messages is printed only after a new > shell prompt has been printed, and this again sometimes goes paired > with echoing being broken. So when you type, the shell receives the > input but it's not being echoed. I have to issue a "reset" command to > return back to normal. > > I have not noticed anything triggering this problem. It will happen > intermittently for no reason. And since it's always paired with the > message being printed after the prompt, I figure it's probably a race > condition? Note that the failure is paired backwards with the late > printing, though the late printing doesn't indicate the echo failure. > I do think they're related though. > > This is a good start: > quin...@quintin-laptop sbin $ sudo /opt/kms/sbin/service restart appserver > Shutting down... > Waiting for Geronimo server: localhost:1099 > Launching Geronimo Server... > Geronimo server is started > Geronimo Server started in 0:00:33.382 > quin...@quintin-laptop sbin $ > > This is a failed start (with enter pressed 3 times afterwards and then > "ls" entered + another enter): > quin...@quintin-laptop sbin $ sudo /opt/kms/sbin/service restart appserver > Shutting down... > Waiting for Geronimo server: localhost:1099 > Launching Geronimo Server... > Geronimo server is started > quin...@quintin-laptop sbin $ Geronimo Server started in 0:00:33.382 > quin...@quintin-laptop sbin $ quin...@quintin-laptop sbin $ > quin...@quintin-laptop sbin $ > 2.1.4.start-appserver 2.1.4.stop-appserver common.sh daemon init.d > install jsvc service start-appserver start-jar stop-appserver > stop-jar > quin...@quintin-laptop sbin $ > > It's not the same as above, though I do think it's caused by the same > component, as the only way shell echoing can become broken would be > the terminal not being restored/initialized properly. Anyone noticed > this problem? > > Quintin Beukes > > > > On Wed, Nov 25, 2009 at 5:13 PM, Shawn Jiang wrote: > > I'm using G2.1.4 in LF, it should be a general problems. I don't think > its > > a GShell specific problem. Instead, we met this problem with both "gsh > -c > > deploy deploy" and "deploy.sh deploy". > > > > > > On Wed, Nov 25, 2009 at 7:13 PM, chi runhua wrote: > >> > >> Thanks Shawn for the sharing. > >> > >> I'll collect this info into G doc. Could you specify the G version you > >> are using, or is it a general problem in all G servers with a GShell > >> environment? > >> > >> Jeff C > >> > >> On Wed, Nov 25, 2009 at 5:29 PM, Shawn Jiang > wrote: > >>> > >>> Lotus Foundation(LF) is a customized linux OS. We met a wierd problem > >>> when deploying applications to a running Geronimo on LF. > >>> > >>> The deploy process is not successful and never return. I remote debug > >>> to it and found that it's caused by some native code execution when > doing > >>> the JLine UnixTerminal init. Seems LF does not support some native > code > >>> used in UnixTerminal. > >>> > >>> To resolve this problem, We have to set a system property in JAVA_OPTS > >>> > >>> -Djline.terminal=jline.UnsupportedTerminal > >>> > >>> to force the JLine use UnsupportedTerminal instead of UnixTerminal. > I'm > >>> sending this mail to log it in case someone else might meet similar > problems > >>> on other platforms, > >>> > >>> -- > >>> Shawn > >> > > > > > > > > -- > > Shawn > > > -- Shawn
[jira] Commented: (GERONIMO-4678) Initial Japanese translation
[ https://issues.apache.org/jira/browse/GERONIMO-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782712#action_12782712 ] Ivan commented on GERONIMO-4678: Commit the translation patch for rev 883562, thanks ! > Initial Japanese translation > > > Key: GERONIMO-4678 > URL: https://issues.apache.org/jira/browse/GERONIMO-4678 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Reporter: Kan Ogawa >Assignee: Kan Ogawa >Priority: Minor > Fix For: 2.2 > > Attachments: geronimo-v21_i18n-ja_G4485-G4532_v1.patch, > geronimo-v22_i18n-ja_G4474-G4484-G4517_v1.patch, > geronimo-v22_i18n-ja_G4759.patch, geronimo-v22_i18n-ja_v2.patch, > geronimo-v22_i18n-ja_v3.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ee apps in trunk
Hi Jarek, These WARNs just happen when starting up the server, not when building the assembly. Today I will give some tries on: 1. welcome-tomcat-server 2. another simple sample built with car-maven-plugin I will post what I get. Thanks! Forrest
[BUILD] trunk: Failed for Revision: 884241
Geronimo Revision: 884241 built with tests included See the full build-1500.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091125/build-1500.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091125/unit-test-reports for artifact: org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots), ibiblio.org (http://repo.exist.com/maven2), ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots), ibiblio.org (http://repo.exist.com/maven2), ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576) 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: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.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots), ibiblio.org (http://repo.exist.com/maven2), ops4j.snapshots (http
[BUILD] branches/2.2: Failed for Revision: 884226
Geronimo Revision: 884226 built with tests included See the full build-1400.log file at http://people.apache.org/builds/geronimo/server/binaries/2.2/20091125/build-1400.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/2.2/20091125/unit-test-reports -- 1 required artifact is missing. for artifact: org.apache.geronimo.framework:jee-specs:car:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.geronimo.specs:geronimo-interceptor_3.0_spec:jar:1.0.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.specs -DartifactId=geronimo-interceptor_3.0_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.geronimo.specs -DartifactId=geronimo-interceptor_3.0_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.framework:jee-specs:car:2.2-SNAPSHOT 2) org.apache.geronimo.specs:geronimo-interceptor_3.0_spec:jar:1.0.1 -- 1 required artifact is missing. for artifact: org.apache.geronimo.framework:jee-specs:car:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576) 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: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.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.geronimo.specs:geronimo-interceptor_3.0_spec:jar:1.0.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.specs -DartifactId=geronimo-interceptor_3.0_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.geronimo.specs -DartifactId=geronimo-interceptor_3.0_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.framework:jee-specs:car:2.2-SNAPSHOT 2) org.apache.geronimo.specs:geronimo-interceptor_3.0_spec:jar:1.0.1 -- 1 required artifact is missing. for artifact: org.apache.geronimo.framework:jee-specs:car:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:324) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:288) at
Re: Help needed to debug a KernelDelegate call
I'm not sure what you are asking about. The mbean server is supplied by the java platform so you'll need it's source if you want to understand what is happening locally during the invoke call. I would suggest debugging in the target vm in the basic kernel to see what is happening there (including if the call gets to the remote vm). hope this relates to what you are asking about... david jencks On Nov 25, 2009, at 10:27 AM, Ashish Jain wrote: Hi, I am trying to debug one of the issue I am facing with wadi clustering. At one of the point there is a call to KernelDelegate.invokeKernel(String methodName, Object[] args, String[] types) which calls up return mbeanServer.invoke(Kernel.KERNEL, methodName, args, types). After this once the call is returned I see the operation is complete. Can someone help me to debug the code after I Step Into return mbeanServer.invoke(Kernel.KERNEL, methodName, args, types). Thanks Ashish
Help needed to debug a KernelDelegate call
Hi, I am trying to debug one of the issue I am facing with wadi clustering. At one of the point there is a call to KernelDelegate.invokeKernel(String methodName, Object[] args, String[] types) which calls up *return mbeanServer.invoke(Kernel.KERNEL, methodName, args, types)*. After this once the call is returned I see the operation is complete. Can someone help me to debug the code after I Step Into *return mbeanServer.invoke(Kernel.KERNEL, methodName, args, types). *Thanks Ashish
Re: A wierd problem when deploying applications to Geronimo on Lotus Foundation
Regarding this same component, has anyone noticed the following problem. I start my Geronimo server with the following: "$KMS_SERVER"/geronimo/bin/gsh -c "geronimo/start-server --logfile '$KMS_SERVER/geronimo/var/log/startup.log'" & USER=`<"$KMS_CONF/geronimo-auth-user"` PASS=`<"$KMS_CONF/geronimo-auth-pass"` "$KMS_SERVER"/geronimo/bin/gsh -c "geronimo/wait-for-server -u $USER -w $PASS" When it finished starting a message is printed to the tune of "Geronimo started in h:mm:ss.sss". Sometimes this works perfectly, though on the odd occassion the messages is printed only after a new shell prompt has been printed, and this again sometimes goes paired with echoing being broken. So when you type, the shell receives the input but it's not being echoed. I have to issue a "reset" command to return back to normal. I have not noticed anything triggering this problem. It will happen intermittently for no reason. And since it's always paired with the message being printed after the prompt, I figure it's probably a race condition? Note that the failure is paired backwards with the late printing, though the late printing doesn't indicate the echo failure. I do think they're related though. This is a good start: quin...@quintin-laptop sbin $ sudo /opt/kms/sbin/service restart appserver Shutting down... Waiting for Geronimo server: localhost:1099 Launching Geronimo Server... Geronimo server is started Geronimo Server started in 0:00:33.382 quin...@quintin-laptop sbin $ This is a failed start (with enter pressed 3 times afterwards and then "ls" entered + another enter): quin...@quintin-laptop sbin $ sudo /opt/kms/sbin/service restart appserver Shutting down... Waiting for Geronimo server: localhost:1099 Launching Geronimo Server... Geronimo server is started quin...@quintin-laptop sbin $ Geronimo Server started in 0:00:33.382 quin...@quintin-laptop sbin $ quin...@quintin-laptop sbin $ quin...@quintin-laptop sbin $ 2.1.4.start-appserver 2.1.4.stop-appserver common.sh daemon init.d install jsvc service start-appserver start-jar stop-appserver stop-jar quin...@quintin-laptop sbin $ It's not the same as above, though I do think it's caused by the same component, as the only way shell echoing can become broken would be the terminal not being restored/initialized properly. Anyone noticed this problem? Quintin Beukes On Wed, Nov 25, 2009 at 5:13 PM, Shawn Jiang wrote: > I'm using G2.1.4 in LF, it should be a general problems. I don't think its > a GShell specific problem. Instead, we met this problem with both "gsh -c > deploy deploy" and "deploy.sh deploy". > > > On Wed, Nov 25, 2009 at 7:13 PM, chi runhua wrote: >> >> Thanks Shawn for the sharing. >> >> I'll collect this info into G doc. Could you specify the G version you >> are using, or is it a general problem in all G servers with a GShell >> environment? >> >> Jeff C >> >> On Wed, Nov 25, 2009 at 5:29 PM, Shawn Jiang wrote: >>> >>> Lotus Foundation(LF) is a customized linux OS. We met a wierd problem >>> when deploying applications to a running Geronimo on LF. >>> >>> The deploy process is not successful and never return. I remote debug >>> to it and found that it's caused by some native code execution when doing >>> the JLine UnixTerminal init. Seems LF does not support some native code >>> used in UnixTerminal. >>> >>> To resolve this problem, We have to set a system property in JAVA_OPTS >>> >>> -Djline.terminal=jline.UnsupportedTerminal >>> >>> to force the JLine use UnsupportedTerminal instead of UnixTerminal. I'm >>> sending this mail to log it in case someone else might meet similar problems >>> on other platforms, >>> >>> -- >>> Shawn >> > > > > -- > Shawn >
Re: minimal tomcat server is assembled, but failed on starting module tomcat6
The problem was that a class in catalina bundle was using StringManager class in util bundle to load a resource that was in catalina bundle. And the utll bundle does not import the catalina packages. My solution for now is to make sure that each Tomcat bundle has its own version of StringManager and that all classes within the given bundle use the right StringManager to load the resources. That's what Tomcat seemed to be doing anyway since there is a number of StringManager copies in different packages/bundles already. Another thing I realized is that the util bundle is only really used by the catalina bundle. So we could also merge these together to make things a bit simpler. After resolving that problem locally I ran into another problem. In Geronimo we add some Geronimo specific listeners to each web app (see addInstanceListener() in GeronimoStandardContext). These classes are instantiated by Tomcat using Class.forName(String) in StandardContext.createWrapper(). So the Geronimo-specific class will be loaded using the catalina bundle classloader and things will fail. The easy fix is to add DynamicImport-Package * to catalina bundle. Or we could modify the Tomcat code to use a specific classloader when loading the listeners, etc. Thoughts or other solutions? Jarek On Fri, Nov 20, 2009 at 12:42 AM, David Jencks wrote: > I don't know how resource bundles work but I expect they have assumptions > about classloaders loading the resource files that are not valid in osgi > outside a single bundle. I'm not sure exactly what happens with osgi either > but I think that you have to use the Bundle object to load classes and > resources from other bundles, not the classloader that loads the classes in > a bundle. > > For a modular system I'd expect that the resources would need to be in the > bundle itself or else supplied through some kind of resource service. If > the resources aren't in the right bundle lets move them. > > BTW I'm starting to try to get the welcome app to deploy, I'm adding a > couple mini-assemblies to the build. I'm starting with the jetty server > if you'd like to take a look at the tomcat one that might be a standardized > testbed for this work. I've just committed the server assemblies under > plugins/welcome. > > thanks > david jencks > > On Nov 19, 2009, at 7:51 PM, Forrest Xia wrote: > >> Hi, >> >> I managed to locally make an assembly of tomcat-minimal successfully(of >> cause, disabled some modules, such as hot-deploy, remote-deploy). >> >> But when I tried to start the server, I encounter a strange problem that I >> can not figure out why. The problem is: >> >> When boot comes to plugin >> "org.apache.geronimo.configs/tomcat6/3.0-SNAPSHOT/car", an >> java.util.MissingResourceException threw out. Full stack trace is: >> >> [* ] 83% 10s Starting >> org.apache.ger...2009-11-20 11:13:40,920 ERROR [GBeanInstanceState] Error >> while starting; GBean is now in the FAILED state: >> abstractName="org.apache.geronimo.configs/tomcat6/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/3.0-SNAPSHOT/car,j2eeType=GBean,name=TomcatServer" >> org.apache.xbean.recipe.ConstructionException: Error invoking constructor: >> public org.apache.catalina.connector.Connector(java.lang.String) throws >> java.lang.Exception >> at >> org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:962) >> at >> org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276) >> at >> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) >> at >> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) >> at >> org.apache.geronimo.tomcat.model.ConnectorType.getConnector(ConnectorType.java:595) >> at >> org.apache.geronimo.tomcat.model.ServiceType.getService(ServiceType.java:278) >> at >> org.apache.geronimo.tomcat.model.ServerType.build(ServerType.java:294) >> at >> org.apache.geronimo.tomcat.TomcatServerGBean.(TomcatServerGBean.java:132) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >> at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >> at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >> at >> org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:952) >> at >> org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:276) >> at >> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:96) >> at >> org.apache.xbean.recipe.AbstractRecipe.create(AbstractRecipe.java:61) >> at >> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:917) >> at >> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) >> at
Re: ee apps in trunk
Are you getting these errors when starting up the server or when building the assembly? I sometimes see these errors too (I haven't been able to track the cause yet) in car-maven-plugin but I just recompile the plugins and things usually just work fine the second time. Jarek On Wed, Nov 25, 2009 at 10:33 AM, Forrest Xia wrote: > I double checked those bundles and they are in the assembly's repository. I > think they should be installed and activated before installing > jetty8-deployer bundle, isn't it? > > Forrest >
Re: ee apps in trunk
I double checked those bundles and they are in the assembly's repository. I think they should be installed and activated before installing jetty8-deployer bundle, isn't it? Forrest
Re: ee apps in trunk
Hi David, What I did is building a geronimo-jetty8-minimal assembly, starting it, and then installing and activating welcome-jetty car bundle on it. The build order of geronimo-jetty8-minimal assembly as follows: framework->plugins->plugingroups/web-jetty(disable some modules)->assemblies/geronimo-jetty8-minimal When first starting the assembly, jetty8-deployer bundle seems not activated correctly, and it suspends the server boot. Exceptions as below: WARN [DependencyManager] Could not install bundle for artifact: org.apache.geronimo.configs/connector-deployer-1_6//car org.osgi.framework.BundleException: Unable to cache bundle: mvn:org.apache.geronimo.configs/connector-deployer-1_6/null/car at org.apache.felix.framework.Felix.installBundle(Felix.java:2321) ... Caused by: java.lang.RuntimeException: URL [mvn:org.apache.geronimo.configs/connector-deployer-1_6/null/car] could not be resolved. WARN [DependencyManager] Could not install bundle for artifact: org.apache.geronimo.configs/jetty8//car org.osgi.framework.BundleException: Unable to cache bundle: mvn:org.apache.geronimo.configs/jetty8/null/car at org.apache.felix.framework.Felix.installBundle(Felix.java:2321) ... Caused by: java.lang.RuntimeException: URL [mvn:org.apache.geronimo.configs/jetty8/null/car] could not be resolved. WARN [DependencyManager] Could not install bundle for artifact: org.apache.geronimo.configs/j2ee-deployer//car org.osgi.framework.BundleException: Unable to cache bundle: mvn:org.apache.geronimo.configs/j2ee-deployer/null/car ... Caused by: java.lang.RuntimeException: URL [mvn:org.apache.geronimo.configs/j2ee-deployer/null/car] could not be resolved. WARN [DependencyManager] Could not install bundle for artifact: org.apache.geronimo.modules/geronimo-web-2.5-builder//jar org.osgi.framework.BundleException: Unable to cache bundle: mvn:org.apache.geronimo.modules/geronimo-web-2.5-builder/null ... Caused by: java.lang.RuntimeException: URL [mvn:org.apache.geronimo.modules/geronimo-web-2.5-builder/null] could not be resolved. Startup failed org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/jetty8-deployer/3.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:305) at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:145) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:81) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:109) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32) Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.geronimo.configs.jetty8-deployer [125]: package; (package=org.apache.geronimo.jetty8.deployment) at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) at org.apache.felix.framework.Felix.startBundle(Felix.java:1597) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:300) ... 5 more Seems we need to adjust the module dependencies of web-jetty to ensure the necessary dependent bundles installed and activate. Please share your thoughts about why it does not work if doing like that. thanks! Forrest
Re: A wierd problem when deploying applications to Geronimo on Lotus Foundation
I'm using G2.1.4 in LF, it should be a general problems. I don't think its a GShell specific problem. Instead, we met this problem with both "gsh -c deploy deploy" and "deploy.sh deploy". On Wed, Nov 25, 2009 at 7:13 PM, chi runhua wrote: > Thanks Shawn for the sharing. > > I'll collect this info into G doc. Could you specify the G version you are > using, or is it a general problem in all G servers with a GShell > environment? > > Jeff C > > > On Wed, Nov 25, 2009 at 5:29 PM, Shawn Jiang wrote: > >> Lotus Foundation(LF) is a customized linux OS. We met a wierd problem >> when deploying applications to a running Geronimo on LF. >> >> The deploy process is not successful and never return. I remote debug to >> it and found that it's caused by some native code execution when doing the >> JLine UnixTerminal init. Seems LF does not support some native code used >> in UnixTerminal. >> >> To resolve this problem, We have to set a system property in JAVA_OPTS >> >> *-Djline.terminal=jline.UnsupportedTerminal* >> >> to force the JLine use UnsupportedTerminal instead of UnixTerminal. I'm >> sending this mail to log it in case someone else might meet similar problems >> on other platforms, >> >> -- >> Shawn >> > > -- Shawn
[jira] Updated: (GERONIMO-4678) Initial Japanese translation
[ https://issues.apache.org/jira/browse/GERONIMO-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa updated GERONIMO-4678: Attachment: geronimo-v22_i18n-ja_v3.patch Attached the translation patch for rev 883582. Please commit it. > Initial Japanese translation > > > Key: GERONIMO-4678 > URL: https://issues.apache.org/jira/browse/GERONIMO-4678 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Reporter: Kan Ogawa >Assignee: Kan Ogawa >Priority: Minor > Fix For: 2.2 > > Attachments: geronimo-v21_i18n-ja_G4485-G4532_v1.patch, > geronimo-v22_i18n-ja_G4474-G4484-G4517_v1.patch, > geronimo-v22_i18n-ja_G4759.patch, geronimo-v22_i18n-ja_v2.patch, > geronimo-v22_i18n-ja_v3.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-4678) Initial Japanese translation
[ https://issues.apache.org/jira/browse/GERONIMO-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kan Ogawa reopened GERONIMO-4678: - There was two additional i18n messages in rev 883582: http://svn.apache.org/viewvc?view=revision&revision=883582 > Initial Japanese translation > > > Key: GERONIMO-4678 > URL: https://issues.apache.org/jira/browse/GERONIMO-4678 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Reporter: Kan Ogawa >Assignee: Kan Ogawa >Priority: Minor > Fix For: 2.2 > > Attachments: geronimo-v21_i18n-ja_G4485-G4532_v1.patch, > geronimo-v22_i18n-ja_G4474-G4484-G4517_v1.patch, > geronimo-v22_i18n-ja_G4759.patch, geronimo-v22_i18n-ja_v2.patch > > -- 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: 884107
Geronimo Revision: 884107 built with tests included See the full build-0900.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091125/build-0900.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091125/unit-test-reports for artifact: org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo.exist.com/maven2), ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo.exist.com/maven2), ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576) 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:37) at java.lang.reflect.Method.invoke(Method.java:599) 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.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo.exist.com/maven2), ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots
Re: [ANNOUNCE] MyFaces Core v1.2.8 Release
On Nov 24, 2009, at 10:21 PM, Ivan wrote: > How about updating myfaces version to 1.2.8 for Geronimo 2.2 ? Personally, I'd leave 2.2 as is... It's time to release 2.2. Better to avoid introducing new problems... Target the upgrade to 2.2.1. Would go ahead and upgrade to latest MyFaces in branches/2.1. --kevan
Re: A wierd problem when deploying applications to Geronimo on Lotus Foundation
Thanks Shawn for the sharing. I'll collect this info into G doc. Could you specify the G version you are using, or is it a general problem in all G servers with a GShell environment? Jeff C On Wed, Nov 25, 2009 at 5:29 PM, Shawn Jiang wrote: > Lotus Foundation(LF) is a customized linux OS. We met a wierd problem when > deploying applications to a running Geronimo on LF. > > The deploy process is not successful and never return. I remote debug to > it and found that it's caused by some native code execution when doing the > JLine UnixTerminal init. Seems LF does not support some native code used > in UnixTerminal. > > To resolve this problem, We have to set a system property in JAVA_OPTS > > *-Djline.terminal=jline.UnsupportedTerminal* > > to force the JLine use UnsupportedTerminal instead of UnixTerminal. I'm > sending this mail to log it in case someone else might meet similar problems > on other platforms, > > -- > Shawn >
Re: Strange dependency problem building jaxws
2009/11/13 Rick McGuire > David Jencks wrote: > >> >> On Nov 10, 2009, at 9:57 AM, Rick McGuire wrote: >> >> David Jencks wrote: >>> On Nov 10, 2009, at 7:59 AM, Rick McGuire wrote: There are two subprojects in the jaxws plugin that I'm having trouble > building, and I can't figure out why. The cause of the failure is a > resolution failure trying to resolve the javax.jws package, version 2.0. > These classes are contained in the geronimo-ws-metadata specs bundle, and > should be there. Running the build with the -X option does not show any > sign that this bundle is getting installed and started before the error. > I've tried adding this as dependency in every pom I could think of to > force > this to be loaded first and nothing appears to have made a difference. > That > bundle just doesn't seem to get loaded. The manifests look good in all > cases, but it just doesn't appear to load. > > I also tried specifying a version in the karaf config.properties on the > javax.jws packages, but that didn't make any difference either. There's > obviously something going wrong with how the dependencies are processed > here, but I can't seem to spot what's messing up. Everything looks like > what I'd expect to see when I use dependency:tree. > For now, I've just commented these two items out so they won't build, > but this is going to need to be solved eventually. > I suspect these classes are also in the jvm. Maybe the situation is similar to the one for javax.transaction where some classes come from the jvm and some from the spec jar? The mysterious fix for that seems to be, in etc/config.properties from framework/config/karaf-framework/src/main/resources/filtered-resources/etc/config.properties org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.transaction,javax.transaction.* >>> Ok, I've think I've tracked this problem back to its root cause and fixed > it now. I'm able to build with this fix and with the changes to the > geronimo-gbean-deployer backed off. > > The issue here was how the framework system classes were getting defined > and how the build/runtime was providing access to spec class that are JRE > resident. With my original problem, the issue was showing up with the > javax.jws packages, but this would be an issue with any of our spec jars. > Here's how some of these issues showed up: > > 1) During the build, any configuration or bundle that had a dependency on > the javax.jws classes was getting built using the geronimo-ws-metadata spec > jar. This resulted in these bundles having an import dependency against the > version 2.0 of the javax.jws packages. > > 2) When building the configuration using the car plugin, the provided > scope on the geronimo-gbean-deployer was preventing the geronimo-ws-metadata > bundle from getting installed. This caused a resolution failure because > there was no javax.jms package available with a version >= 2.0. > 3) Removing the provided scope from the geronimo-gbean-deployer allowed > the geronimo-ws-metadata bundle to be installed, but this had the side > effect of having two versions of the javax.jws packages visible in the > framework. One at the 2.0 level (the geronimo-ws-metadata one) and a second > at the 0.0.0 level (the one from the jre). In some complex environments, > this resulted in bundle constraint violations because the uses relationships > required visibility to both versions of these packages. > The solution was to explicitly specify the framework exported versions of > these packages so that they match the version level we specify in the > geronimo spec bundles. This allows bundles dependent upon specific versions > of these packages to use the framework version without requiring the > geronimo bundle to be installed and if the geronimo version does end up > getting installed, bundles will still be wired to just a single source for > these package files. > This correction needed to be made in both the car plugin and the karaf > config.properties files. > Since Geronimo 3.0 will only support JDK 1.6+, those packages like jws are provided by JRE, so do we still need to ship our own spec ? After keeping the same version number, it seems that the ones from JRE are always used. > > Rick > > > > and javax.transaction; javax.transaction.xa; partial=true; mandatory:=partial, \ >>> I did that experiment already, and that didn't work either. The root of >>> the problem appears to be the explicit request for the 2.0 version. That is >>> available in the geronimo-ws-metadata bundle, but there's no sign in any of >>> the Felix debug output to indicate that this is getting loaded. >>> I'm now stuck on a similar situation with geronimo-service-builder. I'm >>> getting a constraint loading error on geronimo-service-builder because it >>> can
A wierd problem when deploying applications to Geronimo on Lotus Foundation
Lotus Foundation(LF) is a customized linux OS. We met a wierd problem when deploying applications to a running Geronimo on LF. The deploy process is not successful and never return. I remote debug to it and found that it's caused by some native code execution when doing the JLine UnixTerminal init. Seems LF does not support some native code used in UnixTerminal. To resolve this problem, We have to set a system property in JAVA_OPTS *-Djline.terminal=jline.UnsupportedTerminal* to force the JLine use UnsupportedTerminal instead of UnixTerminal. I'm sending this mail to log it in case someone else might meet similar problems on other platforms, -- Shawn
Is there any license issue about packaging jstl with OSGI information
Hi, Just find that jstl component does not have osgi meta-info shipped, while it is not under ASL 2.0, so is there any license issue for repackaging it with felix-maven.plugin ? Thanks ! -- Ivan
