[jira] [Commented] (GERONIMO-6451) API jar for JSR 338 - JPA 2.1
[ https://issues.apache.org/jira/browse/GERONIMO-6451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659652#comment-13659652 ] Kevan Miller commented on GERONIMO-6451: Hi Pinaki, I assume that you've created the source in geronimo-jpa_2.1_spec-1.0-src.jar? Is there a reason why this source is not built from our 2.0 source (i.e. https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jpa_2.0_spec). BTW, we'd be happy to svn copy geronimo-jpa_2.0_spec to geronimo-jpa_2.1_spec... > API jar for JSR 338 - JPA 2.1 > - > > Key: GERONIMO-6451 > URL: https://issues.apache.org/jira/browse/GERONIMO-6451 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Kevin Sutter > Attachments: geronimo-jpa_2.1_spec-1.0.jar, > geronimo-jpa_2.1_spec-1.0.jar, geronimo-jpa_2.1_spec-1.0-src.jar > > > Updated JPA 2.1 jar for Java EE 7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6449) Java EE 7 API jar files
[ https://issues.apache.org/jira/browse/GERONIMO-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635187#comment-13635187 ] Kevan Miller commented on GERONIMO-6449: Great. Thanks KevIn. I've created a Java EE 7 component and assigned it to this Jira (but not the sub-tasks). We have typically tracked Geronimo server version numbers in Jira (and not spec version numbers -- there's too many of them. and many slightly different). > Java EE 7 API jar files > --- > > Key: GERONIMO-6449 > URL: https://issues.apache.org/jira/browse/GERONIMO-6449 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Java EE 7 >Reporter: Kevin Sutter > Labels: javaee > > Based on the discussion on the dev mailing list, creating a set of JIRAs > seems to be the best way to get the ball rolling on developing the set of API > jars for Java EE 7. I'll create this parent JIRA along with the individual > sub-tasks for each of the major Java EE 7 technologies. There have also been > several maintenance releases of other JSRs related to Java EE 7. I didn't > automatically create sub-tasks for each of these since I'm not positive API > updates were required for each of them. We can create those as sub-tasks as > needed. > I'm not familiar with the Geronimo version strategy, so I'll let someone else > fill those fields in. Also, there doesn't seem to be a javaee7 component > identified yet for Geronimo, if somebody can create one of those and assign > it to this JIRA. > This will be a group effort. Whatever group needs a particular spec API jar > file will probably be the first one to sign up to do the work. But, even > with that, there will probably be multiple people or teams verifying or > contributing to the end result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6449) Java EE 7 API jar files
[ https://issues.apache.org/jira/browse/GERONIMO-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-6449: --- Component/s: Java EE 7 > Java EE 7 API jar files > --- > > Key: GERONIMO-6449 > URL: https://issues.apache.org/jira/browse/GERONIMO-6449 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Java EE 7 >Reporter: Kevin Sutter > Labels: javaee > > Based on the discussion on the dev mailing list, creating a set of JIRAs > seems to be the best way to get the ball rolling on developing the set of API > jars for Java EE 7. I'll create this parent JIRA along with the individual > sub-tasks for each of the major Java EE 7 technologies. There have also been > several maintenance releases of other JSRs related to Java EE 7. I didn't > automatically create sub-tasks for each of these since I'm not positive API > updates were required for each of them. We can create those as sub-tasks as > needed. > I'm not familiar with the Geronimo version strategy, so I'll let someone else > fill those fields in. Also, there doesn't seem to be a javaee7 component > identified yet for Geronimo, if somebody can create one of those and assign > it to this JIRA. > This will be a group effort. Whatever group needs a particular spec API jar > file will probably be the first one to sign up to do the work. But, even > with that, there will probably be multiple people or teams verifying or > contributing to the end result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6446) Build with Java 7
[ https://issues.apache.org/jira/browse/GERONIMO-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635129#comment-13635129 ] Kevan Miller commented on GERONIMO-6446: One note -- flipping the logic around (checking for Mac OS & Java 6) may make things easier when Java 8 shows up. We have no guarantees, though... > Build with Java 7 > - > > Key: GERONIMO-6446 > URL: https://issues.apache.org/jira/browse/GERONIMO-6446 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 3.0.0 >Reporter: Jarek Gawor >Assignee: Jarek Gawor > > Ensure that 3.0 branch builds with Java 7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6446) Build with Java 7
[ https://issues.apache.org/jira/browse/GERONIMO-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633993#comment-13633993 ] Kevan Miller commented on GERONIMO-6446: Working for me > Build with Java 7 > - > > Key: GERONIMO-6446 > URL: https://issues.apache.org/jira/browse/GERONIMO-6446 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 3.0.0 >Reporter: Jarek Gawor >Assignee: Jarek Gawor > > Ensure that 3.0 branch builds with Java 7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6446) Build with Java 7
[
https://issues.apache.org/jira/browse/GERONIMO-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631894#comment-13631894
]
Kevan Miller commented on GERONIMO-6446:
I now get the following error:
{code}
[ERROR] Failed to execute goal
org.apache.geronimo.buildsupport:car-maven-plugin:3.0.1-SNAPSHOT:package
(default-package) on project uddi-tomcat: could not package plugin: Unable to
generate the wsdl file using wsgen. InvocationTargetException:
com/sun/mirror/apt/AnnotationProcessorFactory:
com.sun.mirror.apt.AnnotationProcessorFactory in classloader null -> [Help 1]
{code}
> Build with Java 7
> -
>
> Key: GERONIMO-6446
> URL: https://issues.apache.org/jira/browse/GERONIMO-6446
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: buildsystem
>Affects Versions: 3.0.0
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
>
> Ensure that 3.0 branch builds with Java 7.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6446) Build with Java 7
[
https://issues.apache.org/jira/browse/GERONIMO-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631889#comment-13631889
]
Kevan Miller commented on GERONIMO-6446:
This is a slightly more general was of accomplishing that work-around:
{code}
$ sudo mkdir `/usr/libexec/java_home`/Classes
$ sudo ln -s `/usr/libexec/java_home`/lib/tools.jar
`/usr/libexec/java_home`/Classes/classes.jar
{code}
> Build with Java 7
> -
>
> Key: GERONIMO-6446
> URL: https://issues.apache.org/jira/browse/GERONIMO-6446
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: buildsystem
>Affects Versions: 3.0.0
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
>
> Ensure that 3.0 branch builds with Java 7.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6446) Build with Java 7
[
https://issues.apache.org/jira/browse/GERONIMO-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630284#comment-13630284
]
Kevan Miller commented on GERONIMO-6446:
FYI, I'm seeing the following:
{code}
Exception in thread "main" java.lang.AssertionError: Missing tools.jar at:
/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home/Classes/classes.jar.
Expression: file.exists()
at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:395)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:683)
at
org.codehaus.mojo.jspc.CompilationMojoSupport.findToolsJar(CompilationMojoSupport.groovy:371)
at
org.codehaus.mojo.jspc.CompilationMojoSupport.this$4$findToolsJar(CompilationMojoSupport.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:230)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:912)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:78)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrent0(ScriptBytecodeAdapter.java:112)
at
org.codehaus.mojo.jspc.CompilationMojoSupport.execute(CompilationMojoSupport.groovy:318)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
{code}
in
{code}
[INFO]
[INFO] Building Geronimo Plugins, System Database :: Portlets 3.0.1-SNAPSHOT
[INFO]
{code}
This must be a known/resolved problem... My first google search didn't turn up
anything...
> Build with Java 7
> -
>
> Key: GERONIMO-6446
> URL: https://issues.apache.org/jira/browse/GERONIMO-6446
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: buildsystem
>Affects Versions: 3.0.0
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
>
> Ensure that 3.0 branch builds with Java 7.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6138) JDBC 4 API is not supported
[ https://issues.apache.org/jira/browse/GERONIMO-6138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592285#comment-13592285 ] Kevan Miller commented on GERONIMO-6138: For WAS CE support, you'll want to check with IBM. However, this problem has been around for a while in Geronimo. We really should get this fixed. Any volunteers? > JDBC 4 API is not supported > > > Key: GERONIMO-6138 > URL: https://issues.apache.org/jira/browse/GERONIMO-6138 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 3.0-M1, 3.0.0 >Reporter: Arnaud MERGEY > Fix For: 3.0.1 > > > I try to deploy an application that uses some JDBC 4 API like > java.sql.ResultSet.isClosed() > This calls fails with following error > java.lang.AbstractMethodError: > org.tranql.connector.jdbc.ResultSetHandle.isClosed()Z > According to JEE 6 specifications, JDBC 4 API should be supported in Geronimo > 3, and it seems not. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6429) CLONE - Problem with attribute manager
[
https://issues.apache.org/jira/browse/GERONIMO-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556341#comment-13556341
]
Kevan Miller commented on GERONIMO-6429:
The change that John mentions was in both our Geronimo 1.1 and 1.1.1 releases:
{code}
svn praise
https://svn.apache.org/repos/asf/geronimo/server/tags/1.1.0/modules/system/src/java/org/apache/geronimo/system/configuration/LocalAttributeManager.java
{code}
{code}
svn diff
https://svn.apache.org/repos/asf/geronimo/server/tags/1.1.0/modules/system/src/java/org/apache/geronimo/system/configuration/LocalAttributeManager.java
https://svn.apache.org/repos/asf/geronimo/server/tags/1.1.1/modules/system/src/java/org/apache/geronimo/system/configuration/LocalAttributeManager.java
{code}
Your build timestamp is much later than our 1.1 and 1.1.0 releases... And the
line number from the exception text in your original comment does not exactly
line up with the above source. So, I'm not sure what level of code you are
running (and thus I'm not certain whether or not your build contains John's
fix).
> CLONE - Problem with attribute manager
> --
>
> Key: GERONIMO-6429
> URL: https://issues.apache.org/jira/browse/GERONIMO-6429
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: core
> Environment:
> http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
> Windows XP, cygwin
> Command line: java -jar bin/server.jar
> Free disk space: 3 Gb
>Reporter: Amit S
>Assignee: John Sisson
>Priority: Critical
>
> gnodet@guillaumes /cygdrive/c/tmp/geronimo-1.1-20060607
> $ java -jar bin/server.jar
> Booting Geronimo Kernel (in Java 1.5.0_06)...
> Starting Geronimo Application Server v1.1-20060607
> [**> ] 30% 21s Starting
> geronimo/system-database...20:32:49,484 ERROR [LocalAttributeManager] Error
> saving attributes
> java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable
> attributes working file to proper file name! Configuration will revert to
> defaults unless t
> his is manually corrected! (could not rename
> C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to
> C:\tmp\geronimo-1.1-20060607\var\config\config.xml)
> at
> org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449)
> at
> org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618)
> at java.util.TimerThread.mainLoop(Unknown Source)
> at java.util.TimerThread.run(Unknown Source)
> [**> ] 84% 39s Starting
> geronimo/webconsole-jett...20:33:07,890 ERROR [LocalAttributeManager] Error
> saving attributes
> java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable
> attributes working file to proper file name! Configuration will revert to
> defaults unless t
> his is manually corrected! (could not rename
> C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to
> C:\tmp\geronimo-1.1-20060607\var\config\config.xml)
> at
> org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449)
> at
> org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618)
> at java.util.TimerThread.mainLoop(Unknown Source)
> at java.util.TimerThread.run(Unknown Source)
> [**] 100% 45s Startup complete
> Listening on Ports:
> 1099 0.0.0.0 RMI Naming
> 1527 0.0.0.0 Derby Connector
> 4201 0.0.0.0 ActiveIO Connector EJB
> 4242 0.0.0.0 Remote Login Listener
> 8009 0.0.0.0 Jetty Connector AJP13
> 8080 0.0.0.0 Jetty Connector HTTP
> 8443 0.0.0.0 Jetty Connector HTTPS
> 0.0.0.0 JMX Remoting Connector
>61616 0.0.0.0 ActiveMQ Message Broker Connector
> Started Application Modules:
> EAR: geronimo/webconsole-jetty/1.1-20060607/car
> RAR: geronimo/activemq/1.1-20060607/car
> RAR: geronimo/system-database/1.1-20060607/car
> WAR: geronimo/remote-deploy-jetty/1.1-20060607/car
> WAR: geronimo/welcome-jetty/1.1-20060607/car
> Web Applications:
> http://guillaumes:8080/
> http://guillaumes:8080/console
> http://guillaumes:8080/console-standard
> http://guillaumes:8080/remote-deploy
> Geronimo Application Server started
> 20:33:18,718 ERROR [LocalAttributeManager] Error saving attributes
> java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable
> attributes working file to proper file name! Configuration will revert to
> defaults unless t
> his is manually corrected! (could not rename
> C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to
> C:\tmp\geronimo-1.1-20060607\va
[jira] [Closed] (GERONIMO-6380) geronimo fails to start when launched using 'jpda run'
[
https://issues.apache.org/jira/browse/GERONIMO-6380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller closed GERONIMO-6380.
--
Resolution: Invalid
> geronimo fails to start when launched using 'jpda run'
> --
>
> Key: GERONIMO-6380
> URL: https://issues.apache.org/jira/browse/GERONIMO-6380
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Kevan Miller
>Priority: Minor
>
> Starting geronimo with the jpda command is causing startup problems for me...
> {code}
> $ ./geronimo jpda run
> Using GERONIMO_HOME: /Users/kevan/servers/geronimo-tomcat7-javaee6-3.0.0
> Using GERONIMO_SERVER: /Users/kevan/servers/geronimo-tomcat7-javaee6-3.0.0
> Using GERONIMO_TMPDIR:
> /Users/kevan/servers/geronimo-tomcat7-javaee6-3.0.0/var/temp
> Using JRE_HOME:
> /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
> Using JPDA_OPTS: -Xdebug
> -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
> Listening for transport dt_socket at address: 8000
> Error launching framework:
> org.eclipse.osgi.framework.internal.core.Framework$DuplicateBundleException:
> Bundle "org.apache.aries.proxy" version "0.3.0" has already been installed
> from:
> reference:file:/Users/kevan/Servers/geronimo-tomcat7-javaee6-3.0.0/repository/org/apache/aries/proxy/org.apache.aries.proxy/0.3/org.apache.aries.proxy-0.3.jar
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6380) geronimo fails to start when launched using 'jpda run'
Kevan Miller created GERONIMO-6380:
--
Summary: geronimo fails to start when launched using 'jpda run'
Key: GERONIMO-6380
URL: https://issues.apache.org/jira/browse/GERONIMO-6380
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Kevan Miller
Priority: Minor
Starting geronimo with the jpda command is causing startup problems for me...
{code}
$ ./geronimo jpda run
Using GERONIMO_HOME: /Users/kevan/servers/geronimo-tomcat7-javaee6-3.0.0
Using GERONIMO_SERVER: /Users/kevan/servers/geronimo-tomcat7-javaee6-3.0.0
Using GERONIMO_TMPDIR:
/Users/kevan/servers/geronimo-tomcat7-javaee6-3.0.0/var/temp
Using JRE_HOME:
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
Using JPDA_OPTS: -Xdebug
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
Listening for transport dt_socket at address: 8000
Error launching framework:
org.eclipse.osgi.framework.internal.core.Framework$DuplicateBundleException:
Bundle "org.apache.aries.proxy" version "0.3.0" has already been installed
from:
reference:file:/Users/kevan/Servers/geronimo-tomcat7-javaee6-3.0.0/repository/org/apache/aries/proxy/org.apache.aries.proxy/0.3/org.apache.aries.proxy-0.3.jar
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6376) Investigate why console servlets are eagerly started
[ https://issues.apache.org/jira/browse/GERONIMO-6376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424032#comment-13424032 ] Kevan Miller commented on GERONIMO-6376: Sounds like a great idea to me. Is there a reason why this is a TCK Jira? ;-) > Investigate why console servlets are eagerly started > > > Key: GERONIMO-6376 > URL: https://issues.apache.org/jira/browse/GERONIMO-6376 > Project: Geronimo > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Jarek Gawor > > Most of the console servlets are eagerly started. That is, they are > configured with 1 parameter. We need to > investigate if that's required for anything or not. Otherwise, maybe we can > let the servlets to be loaded on demand when accessed. That should speed up > server start up a bit and reduce memory used at server start up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6351) messages displayed during minimal server startup
[
https://issues.apache.org/jira/browse/GERONIMO-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277056#comment-13277056
]
Kevan Miller commented on GERONIMO-6351:
There's also the following during jetty startup:
{noformat}
2012-05-16 15:35:02,035 WARN [JexlEngine]
org.apache.geronimo.system.configuration.condition.JexlExpressionParser.createExpression@97![0,16]:
'HTTPSPortPrimary + PortOffset;' undefined variable HTTPSPortPrimary
2012-05-16 15:35:02,036 WARN [JexlEngine]
org.apache.geronimo.system.configuration.condition.JexlExpressionParser.createExpression@97![0,16]:
'HTTPSPortPrimary + PortOffset;' undefined variable HTTPSPortPrimary
{noformat}
> messages displayed during minimal server startup
>
>
> Key: GERONIMO-6351
> URL: https://issues.apache.org/jira/browse/GERONIMO-6351
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 3.0
>Reporter: Kevan Miller
>Priority: Minor
>
> I see the following messages when starting a minimal server:
> {noformat}
> Artifact
> org/apache/geronimo/specs/geronimo-jms_1.1_spec/1.1.1/geronimo-jms_1.1_spec-1.1.1.jar
> not found
> Artifact org/apache/xbean/xbean-asm-shaded/3.11/xbean-asm-shaded-3.11.jar not
> found
> Artifact
> org/apache/servicemix/bundles/org.apache.servicemix.bundles.dom4j/1.6.1_2/org.apache.servicemix.bundles.dom4j-1.6.1_2.jar
> not found
> {noformat}
> And also:
> {noformat}
> 2012-05-16 15:20:21,197 WARN [JexlEngine]
> org.apache.geronimo.system.configuration.condition.JexlExpressionParser.createExpression@97![0,11]:
> 'ClusterName;' undefined variable ClusterName
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6351) messages displayed during minimal server startup
Kevan Miller created GERONIMO-6351:
--
Summary: messages displayed during minimal server startup
Key: GERONIMO-6351
URL: https://issues.apache.org/jira/browse/GERONIMO-6351
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 3.0
Reporter: Kevan Miller
Priority: Minor
I see the following messages when starting a minimal server:
{noformat}
Artifact
org/apache/geronimo/specs/geronimo-jms_1.1_spec/1.1.1/geronimo-jms_1.1_spec-1.1.1.jar
not found
Artifact org/apache/xbean/xbean-asm-shaded/3.11/xbean-asm-shaded-3.11.jar not
found
Artifact
org/apache/servicemix/bundles/org.apache.servicemix.bundles.dom4j/1.6.1_2/org.apache.servicemix.bundles.dom4j-1.6.1_2.jar
not found
{noformat}
And also:
{noformat}
2012-05-16 15:20:21,197 WARN [JexlEngine]
org.apache.geronimo.system.configuration.condition.JexlExpressionParser.createExpression@97![0,11]:
'ClusterName;' undefined variable ClusterName
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6344) UriBuilder (in jaxrs) is badly implemented
[ https://issues.apache.org/jira/browse/GERONIMO-6344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270872#comment-13270872 ] Kevan Miller commented on GERONIMO-6344: Thanks for the patch Romain. I've committed to trunk. We should run this through TCK with Wink > UriBuilder (in jaxrs) is badly implemented > -- > > Key: GERONIMO-6344 > URL: https://issues.apache.org/jira/browse/GERONIMO-6344 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Reporter: Romain Manni-Bucau >Assignee: Kevan Miller > > please see CXF-4281 > URIBuilder.fromPath() shouldn't call replacePath > (https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxrs_1.1_spec/src/main/java/javax/ws/rs/core/UriBuilder.java) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6344) UriBuilder (in jaxrs) is badly implemented
[ https://issues.apache.org/jira/browse/GERONIMO-6344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-6344: -- Assignee: Kevan Miller > UriBuilder (in jaxrs) is badly implemented > -- > > Key: GERONIMO-6344 > URL: https://issues.apache.org/jira/browse/GERONIMO-6344 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Reporter: Romain Manni-Bucau >Assignee: Kevan Miller > > please see CXF-4281 > URIBuilder.fromPath() shouldn't call replacePath > (https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxrs_1.1_spec/src/main/java/javax/ws/rs/core/UriBuilder.java) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6085) stop setting java.ext.dirs in geronimo scripts
[ https://issues.apache.org/jira/browse/GERONIMO-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263630#comment-13263630 ] Kevan Miller commented on GERONIMO-6085: There are a number of methods for stripping the CR/LF. However, that's not the reason for my comment... Please remember to click the "Grant License to the ASF" for your contribution. Licensing your contribution under the Apache License is implied, but the radio button makes that explicit. Thanks! > stop setting java.ext.dirs in geronimo scripts > -- > > Key: GERONIMO-6085 > URL: https://issues.apache.org/jira/browse/GERONIMO-6085 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: commands >Reporter: Kevan Miller >Assignee: Saphen Qiu > Fix For: 3.0-beta-1 > > Attachments: Remove_java.ext.dirs.patch > > > We should stop setting the java.ext.dirs property. We don't include lib/ext > any longer. So, there's no reason to be configuring it differently from the > default value the JRE/JDK will generate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6335) incomplete NLS versions of dijit criple console
[ https://issues.apache.org/jira/browse/GERONIMO-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260705#comment-13260705 ] Kevan Miller commented on GERONIMO-6335: NL == Netherlands and the language would be Dutch. > incomplete NLS versions of dijit criple console > --- > > Key: GERONIMO-6335 > URL: https://issues.apache.org/jira/browse/GERONIMO-6335 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 3.0-beta-1 > Environment: Ubuntu Linux + Firefox 11 >Reporter: Bart van Leeuwen > > My Accept-Language header is set to nl,en_us,en this causes the console > JNDI-Viewer to not display anything. > in the Javascript console you can see: > Could not load 'dijit.nls.dijit_nl'; last tried '../dijit/nls/dijit_nl.js' > the dijit_nl.js is missing from the distributrion. > Either implement a english failover, since the rest of the console is > english, or supply all the NLS versions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6334) Generate Tomcat 7.0.27 bundles with patches
[ https://issues.apache.org/jira/browse/GERONIMO-6334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259160#comment-13259160 ] Kevan Miller commented on GERONIMO-6334: Do we have documentation on how to create? > Generate Tomcat 7.0.27 bundles with patches > --- > > Key: GERONIMO-6334 > URL: https://issues.apache.org/jira/browse/GERONIMO-6334 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Kevan Miller > Fix For: 3.0 > > > There's a new Tomcat 7.0.27 release with fixes and new WebSockets support. We > should generate a corresponding externals branch for use within Geronimo... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6334) Generate Tomcat 7.0.27 bundles with patches
Kevan Miller created GERONIMO-6334: -- Summary: Generate Tomcat 7.0.27 bundles with patches Key: GERONIMO-6334 URL: https://issues.apache.org/jira/browse/GERONIMO-6334 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Reporter: Kevan Miller Fix For: 3.0 There's a new Tomcat 7.0.27 release with fixes and new WebSockets support. We should generate a corresponding externals branch for use within Geronimo... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6333) Unable to create JMS broker from admin console
[ https://issues.apache.org/jira/browse/GERONIMO-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259091#comment-13259091 ] Kevan Miller commented on GERONIMO-6333: ActiveMQ config is updated in 3.0. Don't think we have the same level of admin console support as we had in earlier releases. To do this right now, you could edit repository/org/apache/geronimo/configs/activemq-broker-blueprint/3.0-beta-1/activemq-broker-blueprint-3.0-beta-1.car And update the to look something like: After updating, you'll need to clear var/cache and start/restart the server. E.g. './geronimo run --clean' > Unable to create JMS broker from admin console > -- > > Key: GERONIMO-6333 > URL: https://issues.apache.org/jira/browse/GERONIMO-6333 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 3.0-beta-1 > Environment: Linux (Debian testing, x64), IBM J9 1.6, Geronimo > 3.0-beta-1 >Reporter: Moritz Hoffmann > > The documentation says that an ActiveMQ JMS broker can be created from the > console. See > https://cwiki.apache.org/GMOxDOC30/configuring-the-jms-server.html > When I run Geronimo, I do not see the "Add JMS Broker" link that is shown in > the documentation, thus I cannot create a new broker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6142) add backup/restore capability to Derby portlet
[ https://issues.apache.org/jira/browse/GERONIMO-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096892#comment-13096892 ] Kevan Miller commented on GERONIMO-6142: That's a nice idea. Thanks for the suggestion! Any interest in submitting a patch for this? > add backup/restore capability to Derby portlet > -- > > Key: GERONIMO-6142 > URL: https://issues.apache.org/jira/browse/GERONIMO-6142 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.7 >Reporter: Radim Kolar > > Included Derby can be used for user applications. This is good thing because > you do not need to install and maintain external database for not much loaded > applications. But there is major problem with that use scenario. You can do > database backups only when you shutdown application server. > Because Derby database can do online backups, please modify Derby portlet to > allow administrator to do online backups (and restores) to/from specified > directory. It would be best if it can be done via Geronimo shell too and then > used in backup scripts. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (GERONIMO-4222) Database pool unusable after database unavailable for awhile
[ https://issues.apache.org/jira/browse/GERONIMO-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-4222. -- Resolution: Fixed Fix Version/s: (was: Wish List) There have been multiple fixes to our connector implementation. As noted by David and Radim, we appear to have gotten things right... > Database pool unusable after database unavailable for awhile > > > Key: GERONIMO-4222 > URL: https://issues.apache.org/jira/browse/GERONIMO-4222 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.2, 2.1.3, 2.1.4 > Environment: Red Hat Enterprise Linux Server v5.2 > WAS-CE v2.0.0.1, based on Geronimo v2.0.2 >Reporter: David Frahm >Assignee: Jack Cai > Attachments: PGtrial.patch, before and after wasce restart.txt, > connector.patch, stacktrace.txt, > tranql-connector-derby-embed-local-1.5-SNAPSHOT.rar, > tranql-connector-derby-embed-xa-1.5-SNAPSHOT.rar, > tranql-connector-mysql-local-1.3-SNAPSHOT.rar, > tranql-connector-mysql-xa-1.3-SNAPSHOT.rar, > tranql-connector-postgresql-common-1.1.jar, > tranql-connector-postgresql-local-1.2-SNAPSHOT.rar, > tranql-connector-postgresql-xa-1.2-SNAPSHOT.rar, vendors.patch > > > I have frequent trouble with my database pool to an AS/400. The database is > taken down every night for backup, and at least once a week the connection > pool is unusable after the database comes back up. Restarting the connection > pool makes everything work again. > We are new to Geronimo/WAS-CE -- just this one app on one server -- so I > don't have anything to compare to. However, we have had this same issue with > a couple 1.x/1.1.x versions before we upgraded to v2. Also, there are > several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble. > Configuration Info > Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver) > Pool Min Size: 0 > Pool Max Size: 100 > Blocking Timeout: 5000 > Idle Timeout: 15 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6140) Fix testsuite errors in Geronimo trunk
Fix testsuite errors in Geronimo trunk
--
Key: GERONIMO-6140
URL: https://issues.apache.org/jira/browse/GERONIMO-6140
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Kevan Miller
There are a few testsuite problems in the current trunk
1) CI testsuite builds are always failing because of port conflicts
2) testsuite failures aren't being reflected in the testsuite summary (or
testsuite failures aren't stopping the test)
3) geronimo/server/trunk/testsuite/web-testsuite/test-tomcat/ and
geronimo/server/trunk/testsuite/aries-testsuite/require-bundle-test/RequireBundle-eba
appear to have the same basic problem:
{code}
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.354 sec <<<
FAILURE!
testTomcatHost(org.apache.geronimo.testsuite.tomcat.TestTomcat) Time elapsed:
0 sec <<< FAILURE!
junit.framework.AssertionFailedError: responseCode expected:<200> but was:<404>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at
org.apache.geronimo.testsuite.tomcat.TestTomcat.testTomcatHost(TestTomcat.java:42)
{code}
4)
/Users/kevan/geronimo/server/trunk/testsuite/javaee6-testsuite/commonannotation1.1-test/
{code}
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.455 sec <<<
FAILURE!
testDataSourceDefinition(org.apache.geronimo.sample.dataSourceDefinition.test.DataSourceDefinitionTest)
Time elapsed: 0.348 sec <<< FAILURE!
java.io.IOException: Apache Tomcat/7.0.19.2 - Error
report
HTTP Status 500 - type<\
/b> Exception reportmessage description
The server encountered an internal error () that prevented it from
fulfilling\
this request.exception javax.servlet.ServletException:
Error instantiating servlet class org.apache.geronimo.sample.servlet.DataSou\
rceDefinitionServlet
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:818)
org.apache.geron\
imo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48)
org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(Protec\
tedTargetValve.java:53)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
org.apache.catalina.valves.AccessLogValve.invo\
ke(AccessLogValve.java:851)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
org.apache.coyote.http11.Http11Processor.\
process(Http11Processor.java:278)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
org.apache.tomcat.ut\
il.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:243)
org.apache.geronimo.poo\
l.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:373)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
ja\
va.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:680)root cause java\
.lang.InstantiationException: Some objects to be injected were not found in
jndi: [javax.naming.NameNotFoundException: osgi:service/mydatasource] org.apac\
he.geronimo.j2ee.annotation.Holder.newInstance(Holder.java:174)
org.apache.geronimo.tomcat.TomcatInstanceManager.newInstance(TomcatInstanceManager.java:74)\
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:818)
org.apache.geronimo.tomcat.valve.Geron\
imoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48)
org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53\
)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java\
:851)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
org.apache.coyote.http11.Http11Processor.process(Http11Processo\
r.java:278)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
org.apache.to
[jira] [Closed] (GERONIMO-6138) JDBC 4 API is not supported
[ https://issues.apache.org/jira/browse/GERONIMO-6138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-6138. -- Resolution: Duplicate Fix Version/s: 3.0 Thanks! If I recall correctly, 3.0-M1 did not support JDBC4. But current trunk and upcoming beta do/will. > JDBC 4 API is not supported > > > Key: GERONIMO-6138 > URL: https://issues.apache.org/jira/browse/GERONIMO-6138 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 3.0-M1 >Reporter: Arnaud MERGEY > Fix For: 3.0 > > > I try to deploy an application that uses some JDBC 4 API like > java.sql.ResultSet.isClosed() > This calls fails with following error > java.lang.AbstractMethodError: > org.tranql.connector.jdbc.ResultSetHandle.isClosed()Z > According to JEE 6 specifications, JDBC 4 API should be supported in Geronimo > 3, and it seems not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (GERONIMO-5751) LinkageError running CDI TCK
[ https://issues.apache.org/jira/browse/GERONIMO-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-5751. -- > LinkageError running CDI TCK > > > Key: GERONIMO-5751 > URL: https://issues.apache.org/jira/browse/GERONIMO-5751 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 3.0 >Reporter: Kevan Miller >Assignee: Kevan Miller > Fix For: 3.0 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6126) deploy of the Spring petclinic.war sample app fails
deploy of the Spring petclinic.war sample app fails
---
Key: GERONIMO-6126
URL: https://issues.apache.org/jira/browse/GERONIMO-6126
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 3.0
Reporter: Kevan Miller
Fix For: 3.0
Deploying the petclinic.war app on Geroimo 3.0 fails as follows:
{code}
$ ./deploy deploy ~/spring/spring-samples/petclinic/trunk/target/petclinic.war
Using GERONIMO_HOME:
/Users/kevan/geronimo/server/trunk/assemblies/geronimo-tomcat7-javaee6/target/geronimo-tomcat7-javaee6-3.0-SNAPSHOT
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
2011-08-25 11:37:05,880 ERROR [DeployTool] Error:
org.apache.geronimo.common.DeploymentException: Unable to deploy petclinic.war:
Problems encountered parsing web.xml: [
No servlet matching servlet mappings for default]
at
org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDeploy.java:43)
at
org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:148)
at
org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:124)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:171)
at
org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:32)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6124) spring sample "task-basic" can't be deployed successfully because no deployer is able to handle it
[ https://issues.apache.org/jira/browse/GERONIMO-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091027#comment-13091027 ] Kevan Miller commented on GERONIMO-6124: task-basic is a Java SE jar. It's meant to be run as a main() method (e.g. java -cp target/org.springframework.samples.task.basic-1.0.0-SNAPSHOT.jar org.springframework.samples.task.basic.annotation.AnnotationDemo). So, there's nothing that an app server is going to do with the jar... That error message could be updated a bit to possibly make things clearer... In this case, there is no "J2EE descriptor". Should change that to Java EE and message should take OSGi into account, also. > spring sample "task-basic" can't be deployed successfully because no deployer > is able to handle it > -- > > Key: GERONIMO-6124 > URL: https://issues.apache.org/jira/browse/GERONIMO-6124 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 3.0 > Environment: JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 > jvmwi3260sr9-20110203_74623 (JIT enabled, AOT enabled) >Reporter: Tina Li >Priority: Minor > > 1.Use Aug 23 build of Geronimo server,start the server if it's not started > 2.Download spring sample from svn: > https://src.springframework.org/svn/spring-samples > 3.According to sample named "task-basic", modify the pom.xml file which under > trunk folder: Change the element of spring vesion from > 3.0.0.RELEASE to > 3.0.6.RELEASE > 4.Build this sample successfully using cmd : mvn clean package, then can find > the application: org.springframework.samples.task.basic-1.0.0-SNAPSHOT.jar > under \task-basic\trunk\target folder > 5.Deploy this application via admin console, but find this application can'be > deployed and the error message displayed: > The application was not deployed. > Cannot deploy the requested application module because no deployer is able to > handle it. This can happen if you have omitted the J2EE deployment > descriptor, disabled a deployer module, or if, for example, you are trying to > deploy an EJB module on a minimal Geronimo server that does not have EJB > support installed. > (moduleFile=D:\testServer\0823\geronimo-tomcat7-javaee6-3.0-SNAPSHOT-bin\geronimo-tomcat7-javaee6-3.0-SNAPSHOT\var\temp\geronimo-deployer7355734105222365838.tmpdir\org.springframework.samples.task.basic-1.0.0-SNAPSHOT.jar) > org.apache.geronimo.common.DeploymentException: Cannot deploy the requested > application module because no deployer is able to handle it. This can happen > if you have omitted the J2EE deployment descriptor, disabled a deployer > module, or if, for example, you are trying to deploy an EJB module on a > minimal Geronimo server that does not have EJB support installed. > (moduleFile=D:\testServer\0823\geronimo-tomcat7-javaee6-3.0-SNAPSHOT-bin\geronimo-tomcat7-javaee6-3.0-SNAPSHOT\var\temp\geronimo-deployer7355734105222365838.tmpdir\org.springframework.samples.task.basic-1.0.0-SNAPSHOT.jar) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:243) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:140) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) > at java.lang.reflect.Method.invoke(Method.java:611) > at > org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:883) > at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) > at java.lang.Thread.run(Thread.java:736) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6114) Avoid ServiceLoader lookup during OpenWebBeansInitializer
[ https://issues.apache.org/jira/browse/GERONIMO-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-6114: --- Attachment: getWiredBundle.png This shows the callstack that I captured using YourKit. > Avoid ServiceLoader lookup during OpenWebBeansInitializer > - > > Key: GERONIMO-6114 > URL: https://issues.apache.org/jira/browse/GERONIMO-6114 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Affects Versions: 3.0 >Reporter: Kevan Miller > Fix For: 3.0 > > Attachments: getWiredBundle.png > > > OpenWebBeans initialization can represent a major portion of a Geronimo > server's startup time. I've seen it take nearly 1/4 of a server's startup > time. Nearly all of this time is caused because OpenWebBeans is using > ServiceLoader.load(). > A search of wired bundles shouldn't be necessary (and we should avoid, if > possible). We should be able to replace OpenWebBeans > DefaultImplementationLoaderService with our own LoaderService implementation. > This LoaderService implementation could in turn avoid the use of XBean's > BundleClassLoader (BundleClassLoader.getResource() is what drives the > getWiredBundle() processing). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6114) Avoid ServiceLoader lookup during OpenWebBeansInitializer
Avoid ServiceLoader lookup during OpenWebBeansInitializer - Key: GERONIMO-6114 URL: https://issues.apache.org/jira/browse/GERONIMO-6114 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 OpenWebBeans initialization can represent a major portion of a Geronimo server's startup time. I've seen it take nearly 1/4 of a server's startup time. Nearly all of this time is caused because OpenWebBeans is using ServiceLoader.load(). A search of wired bundles shouldn't be necessary (and we should avoid, if possible). We should be able to replace OpenWebBeans DefaultImplementationLoaderService with our own LoaderService implementation. This LoaderService implementation could in turn avoid the use of XBean's BundleClassLoader (BundleClassLoader.getResource() is what drives the getWiredBundle() processing). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6113) [ServiceLoader] Unable to find service with class name : [org.apache.webbeans.spi.FailOverService]
[ https://issues.apache.org/jira/browse/GERONIMO-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086790#comment-13086790 ] Kevan Miller commented on GERONIMO-6113: As of this change in OpenWebBeans, this message is no longer generated: http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/config/WebBeansContext.java?view=diff&r1=1081596&r2=1081597&pathrev=1081597 > [ServiceLoader] Unable to find service with class name : > [org.apache.webbeans.spi.FailOverService] > --- > > Key: GERONIMO-6113 > URL: https://issues.apache.org/jira/browse/GERONIMO-6113 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 3.0 >Reporter: Jarek Gawor > > During startup a few of the following warning messages are displayed: > WARN [ServiceLoader] Unable to find service with class name : > [org.apache.webbeans.spi.FailOverService] > I don't know if that indicates some kind of an error or is harmless. If it is > harmless perhaps we can suppress the warning? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6111) geronimo-tomcat6-javaee5-2.1.7 does not start in 64 bit Platform when using JAVA 7
[ https://issues.apache.org/jira/browse/GERONIMO-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085649#comment-13085649 ] Kevan Miller commented on GERONIMO-6111: Thanks Kavithia. This is almost certainly a JAXB bug. http://www.java.net/node/661561 provides a bit more information. I didn't find a concrete bug report for the issue, but there is probably one, somewhere... IIUC, CollisionCheckStack is using System.identifyHashCode() and %'ing (remainder operator) by the array size. Since identityHashCode() can be negative, bad things can happen (like ArrayIndexOutOfBoundsException). Hopefully, there's an updated version of JAXB. Anybody willing to investigate? > geronimo-tomcat6-javaee5-2.1.7 does not start in 64 bit Platform when using > JAVA 7 > --- > > Key: GERONIMO-6111 > URL: https://issues.apache.org/jira/browse/GERONIMO-6111 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: geronimo-maven-plugin >Affects Versions: 2.1.7 > Environment: Windows AMD64 >Reporter: Kavitha Varadarajan > > Problem recreation Steps: > 1) Download Geronimo version geronimo-tomcat6-javaee5-2.1.7 from > http://geronimo.apache.org/ > 2) set JAVA_HOME to the jvm you want to test > 3) run gsh geronimo/start-server > this results in ArrayOutofBounds Exception..Here is the call Stack > java.lang.ArrayIndexOutOfBoundsException: Array index out of range: -2 >at > com.sun.xml.bind.v2.util.CollisionCheckStack.findDuplicate(CollisionCheckStack.java:112) >at > com.sun.xml.bind.v2.util.CollisionCheckStack.push(CollisionCheckStack.java:53) >at > com.sun.xml.bind.v2.runtime.XMLSerializer.pushObject(XMLSerializer.java:471) >at > com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:574) >at > com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:113) >at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:98) >at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) >at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) >at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) >at > com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) >at > com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) >at > com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) >at > com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:221) >at > javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:96) >at > org.apache.geronimo.system.configuration.AttributesXmlUtil.writeAttribute(AttributesXmlUtil.java:71) >at > org.apache.geronimo.system.configuration.AttributesXmlUtil.extractAttributeValue(AttributesXmlUtil.java:75) >at > org.apache.geronimo.system.configuration.GBeanOverride.(GBeanOverride.java:197) >at > org.apache.geronimo.system.configuration.ConfigurationOverride.(ConfigurationOverride.java:79) >at > org.apache.geronimo.system.configuration.ServerOverride.(ServerOverride.java:42) >at > org.apache.geronimo.system.configuration.LocalAttributeManager.read(LocalAttributeManager.java:354) >at > org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:334) >at > org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:527) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:998) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) >at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) >at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555) >at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) >at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) >at >
[jira] [Commented] (GERONIMO-5743) ServletContext.getRealPath() returns null
[ https://issues.apache.org/jira/browse/GERONIMO-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085387#comment-13085387 ] Kevan Miller commented on GERONIMO-5743: In my opinion, we need to treat this as a high priority. Many apps assume that getRealPath() will provide a meaningful result (non-null and usable). We're going to need to resolve this issue... > ServletContext.getRealPath() returns null > - > > Key: GERONIMO-5743 > URL: https://issues.apache.org/jira/browse/GERONIMO-5743 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: web >Affects Versions: 3.0-M2 >Reporter: Jarek Gawor > > In 3.0 M1 and trunk, ServletContext.getRealPath() returns null. In previous > versions of Geronimo a real path was returned. Returning null is ok from > specification point of view but it breaks compatibility for applications. It > also looks like there are a number of web applications that rely on the > getRealPath() to return a non-null value. One such application is Nexus web > app. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5987) The ActiveMQ working directory and port are not referenced correctly - multiple instances not possible
[
https://issues.apache.org/jira/browse/GERONIMO-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084094#comment-13084094
]
Kevan Miller commented on GERONIMO-5987:
Rex, since this may be related -- two things about ActiveMQ that I noticed,
yesterday. If you don't feel these are related enough, let's get a separate
Jira to track these.
# we're not currently displaying the ActiveMQ listening port during server
startup.
# the server socket is listening on 127.0.0.1, not 0.0.0.0
Here's output for a 2.1.x server start:
{code}
Listening on Ports:
1050 0.0.0.0 CORBA Naming Service
1099 0.0.0.0 RMI Naming
1527 0.0.0.0 Derby Connector
2001 0.0.0.0 OpenEJB ORB Adapter
4201 0.0.0.0 OpenEJB Daemon
6882 0.0.0.0 OpenEJB ORB Adapter
8009 0.0.0.0 Tomcat Connector AJP AJP
8080 0.0.0.0 Tomcat Connector HTTP BIO HTTP
8443 0.0.0.0 Tomcat Connector HTTPS BIO HTTPS
9998 0.0.0.0 JMX Secure Remoting Connector
0.0.0.0 JMX Remoting Connector
61613 0.0.0.0 ActiveMQ Transport Connector
61616 0.0.0.0 ActiveMQ Transport Connector
{code}
We no longer start the Stomp connector (61613) by default. Which is good I
think. However, on 3.0 we don't register the 61616 port and the IP address for
the server socket is not correct.
> The ActiveMQ working directory and port are not referenced correctly -
> multiple instances not possible
> --
>
> Key: GERONIMO-5987
> URL: https://issues.apache.org/jira/browse/GERONIMO-5987
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: ActiveMQ
>Affects Versions: 3.0-M1, 3.0-M2, 3.0
> Environment: Linux x86, Red Hat Enterprise Linux Server release 5.4
> (Tikanga)
>Reporter: Russell E Glaue
>Assignee: Rex Wang
> Labels: geronimo
>
> I am testing with geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT,
> geronimo-tomcat7-javaee6-web-3.0-20110523.171218-97
> ActiveMQ is configured to run as "org.apache.geronimo.home.dir/var/activemq"
> and port 61616, and does not cooperate with multi-server configurations, nor
> does it use the PortOffset. This is the use of the
> "org.apache.geronimo.server.name" option and PortOffset in
> "var/config/config-substitutions.properties". (see:
> https://cwiki.apache.org/GMOxDOC30/running-multiple-geronimo-instances.html)
> First, Problem with working directory
> When wanting to run more than a single server instance, the ActiveMQ startup
> will block waiting for the lock file "$GERONIMO_HOME/var/activemq/lock" to
> become available.
> Obviously this causes any server instance started after the first server
> instance is started to block during startup while waiting for the lock file
> to become available.
> Second, Problem with PortOffset
> When configuring the PortOffset in
> "var/config/config-substitutions.properties", all Geroniomo components expect
> and attempt to connect to ActiveMQ at the port {ActiveMQ + PortOffset}.
> However, regardless of what you set the PortOffset to be, the ActiveMQ
> service only ever binds to port 61616, the default configured port (or
> whatever you have the port set as for this service).
> Steps to repeat working directory problem:
> 1. Download and unpack G3.0 SNAPSHOT (3.0-20110523 tested)
> 2. Create the server instances:
> -- 2A. cd ${GERONIMO_HOME}
> -- 2B-1. mkdir gserver1
> -- 2B-2. cp -rp var gserver1/
> -- 2B-3. cp -rp etc gserver1/
> -- 2B-4. cp -rp repository gserver1/
> 3. update the "PortOffset" parameter in
> gserver1/var/config/config-substitutions.properties for the gserver1 instance.
> 4. Start the default instance and gserver1 instance:
> -- bin/startup
> -- env GERONIMO_OPTS=-Dorg.apache.geronimo.server.name=gserver1 bin/startup
> 5. `tail -f gserver1/var/logs/geronimo.log` and you will see this as the last
> line that outputs:
> "2011-05-31 16:26:39,609 WARN [AMQPersistenceAdapter] Waiting to Lock the
> Store var/activemq"
> The server waits here indefinitely.
> 6. Shutdown the default instance and you will see the "gserver1" instance
> continue on in the startup procedures. (of course you will see errors due to
> the PortOffset problem)
> * If I first start the "gserver1" instance by itself (before starting the
> default instance), the directory "org.apache.geronimo.home.dir/var/activemq"
> is created and populated. Instead it should be
> "org.apache.geronimo.home.dir/org.apache.geronimo.server.name/var/activemq"
> that is created and populated.
> * Probably the patch should be to reference the ActiveMQ working directory as
> "org.apache.geronimo.server.dir/var/activemq"
> Steps to repeat PortOffset problem:
> 1. Download and unpack G3.0 SNAPSHOT (3.0-20110523 tested)
> 2. Create the server
[jira] [Commented] (GERONIMO-6086) geronimo commands to not configure the java.io.tmp directory properly
[ https://issues.apache.org/jira/browse/GERONIMO-6086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068321#comment-13068321 ] Kevan Miller commented on GERONIMO-6086: I was thinking that particular problem would be fixed under GERONIMO-6087, but that's fine. I'll open a new Jira for the issue I was seeing... > geronimo commands to not configure the java.io.tmp directory properly > - > > Key: GERONIMO-6086 > URL: https://issues.apache.org/jira/browse/GERONIMO-6086 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 3.0 >Reporter: Kevan Miller >Assignee: Jarek Gawor > Fix For: 3.0 > > > The geronimo commands are currently configuring GERONIMO_TMPDIR=var/temp. > Since the current directory is the bin directory, that means our temp files > end up in $GERONIMO_HOME/bin/tmp -- which is certainly not where they are > intended to be... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6087) See if we can improve "Main not found" errors (and other startup issues)
See if we can improve "Main not found" errors (and other startup issues)
Key: GERONIMO-6087
URL: https://issues.apache.org/jira/browse/GERONIMO-6087
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Kevan Miller
Fix For: 3.0
In some cases a startup error will prevent the server from starting. Yet the
only message the user sees is "Main not found" (or no message at all).
I've seen this happen when trying to profile the server using YourKit. You must
add com.yourkit to org.osgi.framework.bootdelegation in etc/config.properties
in order for the server to start. If you don't the only error you see is "Main
not found"
Someone also reported that a non-writable java.io.tmpdir directory can lead to
a "Main not found" error. For me, on Mac OS, looks like my server startup spins
in a hot loop:
{quote}
"main" prio=5 tid=102801800 nid=0x100501000 runnable [1004ff000]
java.lang.Thread.State: RUNNABLE
at java.io.UnixFileSystem.canonicalize0(Native Method)
at java.io.UnixFileSystem.canonicalize(UnixFileSystem.java:157)
at java.io.File.getCanonicalPath(File.java:559)
at java.io.File.getCanonicalFile(File.java:583)
at java.io.File.mkdirs(File.java:1189)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.prepareTempDir(DirectoryWatcher.java:548)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.(DirectoryWatcher.java:137)
at
org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:222)
at
org.apache.felix.fileinstall.internal.FileInstall.start(FileInstall.java:124)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1130)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
- locked <7ea24ea68> (a java.lang.Object)
at
org.eclipse.osgi.framework.internal.core.EquinoxLauncher.internalStart(EquinoxLauncher.java:271)
at
org.eclipse.osgi.framework.internal.core.EquinoxLauncher.start(EquinoxLauncher.java:241)
at org.eclipse.osgi.launch.Equinox.start(Equinox.java:258)
at
org.apache.geronimo.main.FrameworkLauncher.launch(FrameworkLauncher.java:179)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:47)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32)
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6086) geronimo commands to not configure the java.io.tmp directory properly
[ https://issues.apache.org/jira/browse/GERONIMO-6086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068092#comment-13068092 ] Kevan Miller commented on GERONIMO-6086: I guess that's not quite right. java.io.tmpdir is configured properly. Just that somebody (activemq, i assume) is writing into $GERONIMO_HOME/bin/tmp. > geronimo commands to not configure the java.io.tmp directory properly > - > > Key: GERONIMO-6086 > URL: https://issues.apache.org/jira/browse/GERONIMO-6086 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Kevan Miller > > The geronimo commands are currently configuring GERONIMO_TMPDIR=var/temp. > Since the current directory is the bin directory, that means our temp files > end up in $GERONIMO_HOME/bin/tmp -- which is certainly not where they are > intended to be... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6086) geronimo commands to not configure the java.io.tmp directory properly
geronimo commands to not configure the java.io.tmp directory properly - Key: GERONIMO-6086 URL: https://issues.apache.org/jira/browse/GERONIMO-6086 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Kevan Miller The geronimo commands are currently configuring GERONIMO_TMPDIR=var/temp. Since the current directory is the bin directory, that means our temp files end up in $GERONIMO_HOME/bin/tmp -- which is certainly not where they are intended to be... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6085) stop setting java.ext.dirs in geronimo scripts
stop setting java.ext.dirs in geronimo scripts -- Key: GERONIMO-6085 URL: https://issues.apache.org/jira/browse/GERONIMO-6085 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Reporter: Kevan Miller Fix For: 3.0 We should stop setting the java.ext.dirs property. We don't include lib/ext any longer. So, there's no reason to be configuring it differently from the default value the JRE/JDK will generate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6055) improve server startup time
[ https://issues.apache.org/jira/browse/GERONIMO-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067029#comment-13067029 ] Kevan Miller commented on GERONIMO-6055: The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=351438 can make a pretty big performance improvement in some environments. There isn't an Equinox 3.7.1 integration build available, yet (I'm told Wednesday). Once available, I'll plan on incorporating it into Geronimo. > improve server startup time > --- > > Key: GERONIMO-6055 > URL: https://issues.apache.org/jira/browse/GERONIMO-6055 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 3.0 >Reporter: Kevan Miller > Attachments: BeanValidationCallStack.png, OpenWebBeansCallStack.png > > > 3.0 server startup has gotten kind of slow. Time to see if we can boost it, a > bit. > I've made some measurements of server startup time using YourKit Java > Profiler (which I think is a great memory and performance analysis tool). If > anybody is trying to use it with Geronimo, you need to update > etc/config.properties in order to run YourKit with Geronimo 3.0. Add > "com.yourkit.*" to the org.osgi.framework.bootdelegation setting. > There are a few surprising hot spots. There may be some improvements that we > can suggest to the Equinox project. However, I think there are some > improvements that we should be making, also... > I'll attach some screen captures that should illustrate some of the issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5729) Access the wrong web console page should get appropriate error message
[ https://issues.apache.org/jira/browse/GERONIMO-5729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-5729: --- Fix Version/s: (was: 3.0) 3.0.1 > Access the wrong web console page should get appropriate error message > -- > > Key: GERONIMO-5729 > URL: https://issues.apache.org/jira/browse/GERONIMO-5729 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.2.2, 3.0-M2, 3.0 >Reporter: Shawn Jiang >Assignee: Shenghao Fang >Priority: Minor > Fix For: 3.0.1 > > Attachments: GERONIMO-5729-updated-1.patch, > GERONIMO-5729-updated.patch, GERONIMO-5729.patch > > > I have also found the reason why I sometimes did not see the menu at the left > hand: > When you log in to "/console/portal/welcome" (which was the default location > in previeous versions) then you do _not_ see the menu. > When you log in to "/console/" the you'll be forwarded to > "/console/portal/0/Welcome, and you see everything correctly. > It seems, that the content I've seen is the default page that will be > displayed for users when they've called illegal page names. It also shows up > for /console/portal/Testpage . Unfortunately the message displayed says > "Welcome to the Apache Geronimo™ Administration Console!" etc. instead of a > error message... > As I think it's not critical enough to delay release, I gave +1. > Thank you all for all the development works! > Johannes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5729) Access the wrong web console page should get appropriate error message
[ https://issues.apache.org/jira/browse/GERONIMO-5729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-5729: --- Fix Version/s: (was: 3.0.1) 3.0 > Access the wrong web console page should get appropriate error message > -- > > Key: GERONIMO-5729 > URL: https://issues.apache.org/jira/browse/GERONIMO-5729 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.2.2, 3.0-M2, 3.0 >Reporter: Shawn Jiang >Assignee: Shenghao Fang >Priority: Minor > Fix For: 3.0 > > Attachments: GERONIMO-5729-updated-1.patch, > GERONIMO-5729-updated.patch, GERONIMO-5729.patch > > > I have also found the reason why I sometimes did not see the menu at the left > hand: > When you log in to "/console/portal/welcome" (which was the default location > in previeous versions) then you do _not_ see the menu. > When you log in to "/console/" the you'll be forwarded to > "/console/portal/0/Welcome, and you see everything correctly. > It seems, that the content I've seen is the default page that will be > displayed for users when they've called illegal page names. It also shows up > for /console/portal/Testpage . Unfortunately the message displayed says > "Welcome to the Apache Geronimo™ Administration Console!" etc. instead of a > error message... > As I think it's not critical enough to delay release, I gave +1. > Thank you all for all the development works! > Johannes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6077) Display usage information after server startup?
[
https://issues.apache.org/jira/browse/GERONIMO-6077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065683#comment-13065683
]
Kevan Miller commented on GERONIMO-6077:
Right. Which is really what I meant. The 'geronimo>' prompt (and the usage
information) has typically scrolled off the screen and is probably 'no longer
visible' to the user.
> Display usage information after server startup?
> ---
>
> Key: GERONIMO-6077
> URL: https://issues.apache.org/jira/browse/GERONIMO-6077
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
>Reporter: Kevan Miller
>
> The usage information:
> {code}
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or 'osgi:shutdown' to shutdown Geronimo.
> {code}
> Would be better displayed after a server startup is complete. Also, the
> command prompt (i.e. 'geronimo>') is not visible after the server has been
> started. So, it's not apparent to new users that they can enter a command.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6077) Display usage information after server startup?
Display usage information after server startup?
---
Key: GERONIMO-6077
URL: https://issues.apache.org/jira/browse/GERONIMO-6077
Project: Geronimo
Issue Type: Improvement
Security Level: public (Regular issues)
Reporter: Kevan Miller
The usage information:
{code}
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or 'osgi:shutdown' to shutdown Geronimo.
{code}
Would be better displayed after a server startup is complete. Also, the command
prompt (i.e. 'geronimo>') is not visible after the server has been started.
So, it's not apparent to new users that they can enter a command.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMODEVTOOLS-762) GEP needs a nightly builds repositary
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064532#comment-13064532 ] Kevan Miller commented on GERONIMODEVTOOLS-762: --- Janet, We never should have been using http://apache.org/dist for this purpose. Please make sure any processes dist for nightly builds have been stopped. dist is *only* for released artifacts voted on by the Geronimo PMC. --kevan > GEP needs a nightly builds repositary > - > > Key: GERONIMODEVTOOLS-762 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-762 > Project: Geronimo-Devtools > Issue Type: Wish > Components: eclipse-plugin >Affects Versions: 3.0 >Reporter: Yi Xiao >Assignee: Yi Xiao > Labels: build, gep,, nightly > Attachments: gep_nightly_build.patch > > > The GEP had a nightly build repo before(refer to: > http://geronimo.apache.org/development-tools.html#DevelopmentTools-NightlyBuilds), > but it does not work now. So, I thought we should set up a environment to > redo it. > I've attached a patch to resolve the issue temporally. If you want to test it > in your local environment, should add below content to your maven's > settings.xml file: > > geronimo-devtools-nightly-repo > people.apache.org.username > people.apache.org.password > > Thank Janet for helping me test to upload the devtools onto the apache site. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6055) improve server startup time
[ https://issues.apache.org/jira/browse/GERONIMO-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063447#comment-13063447 ] Kevan Miller commented on GERONIMO-6055: Some of the data from the .png attachments seems a bit skewed. So, I instrumented some code to look at where we're spending some time... Here's some of the results: _Startup completed in 19.411s seconds_ Of that time, we spent nearly half of that time in o.a.g.bval.ValidatorFactoryGBean.createDefaultFactory() and o.a.g.tomcat.TomcatContainer.addContext() (following times are in milliseconds): _ValidatorFactoryGBean.createDefaultFactory() time: 249, Cumulative time: 4064, Average: 254_ and _TomcatContainer.addContext() time: 1704, Cumulative time: 5454, Average: 495_ Of the addContext() time, we spent nearly all of the time in the following 2 methods during the addContext() processing: _GeronimoStandardContext.setContextProperties() time: 321, Cumulative time: 3266, Average: 296_ _GeronimoStandardContext.startInternal() time: 1382, Cumulative time: 2125, Average: 193_ This final startInternal() call occurred during the start of uddi-tomcat. > improve server startup time > --- > > Key: GERONIMO-6055 > URL: https://issues.apache.org/jira/browse/GERONIMO-6055 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 3.0 >Reporter: Kevan Miller > Attachments: BeanValidationCallStack.png, OpenWebBeansCallStack.png > > > 3.0 server startup has gotten kind of slow. Time to see if we can boost it, a > bit. > I've made some measurements of server startup time using YourKit Java > Profiler (which I think is a great memory and performance analysis tool). If > anybody is trying to use it with Geronimo, you need to update > etc/config.properties in order to run YourKit with Geronimo 3.0. Add > "com.yourkit.*" to the org.osgi.framework.bootdelegation setting. > There are a few surprising hot spots. There may be some improvements that we > can suggest to the Equinox project. However, I think there are some > improvements that we should be making, also... > I'll attach some screen captures that should illustrate some of the issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6055) improve server startup time
[ https://issues.apache.org/jira/browse/GERONIMO-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-6055: --- Attachment: OpenWebBeansCallStack.png BeanValidationCallStack.png Meant to mention -- we should look at some basic operations (e.g. application deploy). Will do that in another jira > improve server startup time > --- > > Key: GERONIMO-6055 > URL: https://issues.apache.org/jira/browse/GERONIMO-6055 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 3.0 >Reporter: Kevan Miller > Attachments: BeanValidationCallStack.png, OpenWebBeansCallStack.png > > > 3.0 server startup has gotten kind of slow. Time to see if we can boost it, a > bit. > I've made some measurements of server startup time using YourKit Java > Profiler (which I think is a great memory and performance analysis tool). If > anybody is trying to use it with Geronimo, you need to update > etc/config.properties in order to run YourKit with Geronimo 3.0. Add > "com.yourkit.*" to the org.osgi.framework.bootdelegation setting. > There are a few surprising hot spots. There may be some improvements that we > can suggest to the Equinox project. However, I think there are some > improvements that we should be making, also... > I'll attach some screen captures that should illustrate some of the issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6055) improve server startup time
improve server startup time --- Key: GERONIMO-6055 URL: https://issues.apache.org/jira/browse/GERONIMO-6055 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Kevan Miller 3.0 server startup has gotten kind of slow. Time to see if we can boost it, a bit. I've made some measurements of server startup time using YourKit Java Profiler (which I think is a great memory and performance analysis tool). If anybody is trying to use it with Geronimo, you need to update etc/config.properties in order to run YourKit with Geronimo 3.0. Add "com.yourkit.*" to the org.osgi.framework.bootdelegation setting. There are a few surprising hot spots. There may be some improvements that we can suggest to the Equinox project. However, I think there are some improvements that we should be making, also... I'll attach some screen captures that should illustrate some of the issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6039) testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller resolved GERONIMO-6039. Resolution: Fixed Fix Version/s: 3.0 Error that I was seeing was: error: Could not create declaration for annotation type javax.inject.Inject After adding geronimo-atinject_1.0_apec jar to the wsdlgen classpath, the test is passing for me. > testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest) > -- > > Key: GERONIMO-6039 > URL: https://issues.apache.org/jira/browse/GERONIMO-6039 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins >Assignee: Kevan Miller > Fix For: 3.0 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6039) testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-6039: -- Assignee: Kevan Miller > testInjectionIntoWebServiceEndpoint(org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest) > -- > > Key: GERONIMO-6039 > URL: https://issues.apache.org/jira/browse/GERONIMO-6039 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins >Assignee: Kevan Miller > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6021) International characters in groupId/artifactId names
[
https://issues.apache.org/jira/browse/GERONIMO-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller resolved GERONIMO-6021.
Resolution: Fixed
Fix Version/s: 3.0
2.2.2
Use UTF-8 encoding to read/write the config.info file.
> International characters in groupId/artifactId names
>
>
> Key: GERONIMO-6021
> URL: https://issues.apache.org/jira/browse/GERONIMO-6021
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Kevan Miller
>Assignee: Kevan Miller
> Fix For: 2.2.2, 3.0
>
>
> Running with the java property '-Dfile.encoding=UTF8' looks like it's
> possible to support bean names with international characters. However, if you
> specify a moduleId with international characters, you can run into problems
> like:
> {quote}
> 2011-05-25 20:16:35,195 INFO [DirectoryHotDeployer] Undeploying test.jar
> 2011-05-25 20:16:35,304 ERROR [DirectoryHotDeployer] Unable to undeploy
> org.apache.geronimo.common.DeploymentException:
> com.foo.test/Geológico/1.0/car does not appear to be a the name of a module
> available on the selected server. Perhaps it has already been stopped or
> undeployed? If you're trying to specify a TargetModuleID, use the syntax
> TargetName|ModuleName instead. If you're not sure what's running, try the
> list-modules command.
> at
> org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:205)
> at
> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.fileRemoved(DirectoryHotDeployer.java:372)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.scanDirectory(DirectoryMonitor.java:409)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:289)
> at java.lang.Thread.run(Thread.java:619)
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6021) International characters in groupId/artifactId names
[
https://issues.apache.org/jira/browse/GERONIMO-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller reassigned GERONIMO-6021:
--
Assignee: Kevan Miller
> International characters in groupId/artifactId names
>
>
> Key: GERONIMO-6021
> URL: https://issues.apache.org/jira/browse/GERONIMO-6021
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Kevan Miller
>Assignee: Kevan Miller
>
> Running with the java property '-Dfile.encoding=UTF8' looks like it's
> possible to support bean names with international characters. However, if you
> specify a moduleId with international characters, you can run into problems
> like:
> {quote}
> 2011-05-25 20:16:35,195 INFO [DirectoryHotDeployer] Undeploying test.jar
> 2011-05-25 20:16:35,304 ERROR [DirectoryHotDeployer] Unable to undeploy
> org.apache.geronimo.common.DeploymentException:
> com.foo.test/Geológico/1.0/car does not appear to be a the name of a module
> available on the selected server. Perhaps it has already been stopped or
> undeployed? If you're trying to specify a TargetModuleID, use the syntax
> TargetName|ModuleName instead. If you're not sure what's running, try the
> list-modules command.
> at
> org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:205)
> at
> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.fileRemoved(DirectoryHotDeployer.java:372)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.scanDirectory(DirectoryMonitor.java:409)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:289)
> at java.lang.Thread.run(Thread.java:619)
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6021) International characters in groupId/artifactId names
International characters in groupId/artifactId names
Key: GERONIMO-6021
URL: https://issues.apache.org/jira/browse/GERONIMO-6021
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Kevan Miller
Running with the java property '-Dfile.encoding=UTF8' looks like it's possible
to support bean names with international characters. However, if you specify a
moduleId with international characters, you can run into problems like:
{quote}
2011-05-25 20:16:35,195 INFO [DirectoryHotDeployer] Undeploying test.jar
2011-05-25 20:16:35,304 ERROR [DirectoryHotDeployer] Unable to undeploy
org.apache.geronimo.common.DeploymentException: com.foo.test/Geológico/1.0/car
does not appear to be a the name of a module available on the selected server.
Perhaps it has already been stopped or undeployed? If you're trying to specify
a TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not
sure what's running, try the list-modules command.
at
org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:205)
at
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.fileRemoved(DirectoryHotDeployer.java:372)
at
org.apache.geronimo.deployment.hot.DirectoryMonitor.scanDirectory(DirectoryMonitor.java:409)
at
org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:289)
at java.lang.Thread.run(Thread.java:619)
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5966) Geronimo start failure: Error while starting; GBean is now in the FAILED state: abstractName="org.apache.geronimo.configs/transaction-1_6/3.0-SNAPSHOT/car
[ https://issues.apache.org/jira/browse/GERONIMO-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050699#comment-13050699 ] Kevan Miller commented on GERONIMO-5966: I don't understand completely. But this problem is caused because 'geronimo start' configures the following parameter setting: -Dkaraf.startLocalConsole=false and geronimo run sets: -Dkaraf.startLocalConsole=true A simple change to geronimo.bat (and always setting -Dkaraf.startLocalConsole=true) will avoid the problem. I assume we'll figure out why startLocalConsole=true is needed. > Geronimo start failure: Error while starting; GBean is now in the FAILED > state: > abstractName="org.apache.geronimo.configs/transaction-1_6/3.0-SNAPSHOT/car > -- > > Key: GERONIMO-5966 > URL: https://issues.apache.org/jira/browse/GERONIMO-5966 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: JVM-compatibility >Affects Versions: 3.0 > Environment: Windows XP SP3 x86 > IBM jdk IBMJava60 SR9-FP1 > Geronimo build on 20110519 >Reporter: Jacky Liu > > 1. cd %Geronimo Home%\bin > 2. input command: geronimo start or startup > ERROR OCCURS! > 2011-05-19 11:19:13,955 ERROR [GBeanInstanceState] Error while starting; > GBean is now in the FAILED state: > abstractName="org.apache.geronimo.configs/transaction-1_6/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction-1_6/3.0-SNAPSHOT/car,j2eeType=GBean,name=SecurityContextHandler" > java.lang.ExceptionInInitializerError > at java.lang.J9VMInternals.initialize(J9VMInternals.java:222) > at > org.apache.geronimo.connector.wrapper.work.SecurityContextHandler.(SecurityContextHandler.java:71) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:56) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39) > at java.lang.reflect.Constructor.newInstance(Constructor.java:527) > at > org.apache.xbean.recipe.ReflectionUtil$ConstructorFactory.create(ReflectionUtil.java:958) > 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:933) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:226) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:702) > at > org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:211) > at > org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:91) > at > org.apache.geronimo.system.osgi.BootActivator$1.execute(BootActivator.java:107) > at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) > at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) > at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32) > Caused by: java.lang.SecurityException: > at javax.security.auth.Policy.getPolicyNoCheck(Policy.java:268) > at javax.security.auth.Policy.getPolicy(Policy.java:219) > at > javax.security.auth.SubjectDomainCombiner$5.run(SubjectDomainCombiner.java:513) > at > java.security.AccessController.doPrivileged(AccessController.java:202) > at > javax.security.auth.SubjectDomainCombiner.compatPolicy(SubjectDomainCombiner.java:509) > at > javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:223) > at java.security.AccessController.getContext(AccessController.java:141) > at > org.apache.geronimo.security.ContextManager$3.run(ContextManager.java:
[jira] [Commented] (GERONIMO-5997) Missing commands for startup
[
https://issues.apache.org/jira/browse/GERONIMO-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047359#comment-13047359
]
Kevan Miller commented on GERONIMO-5997:
Right. And the 'geronimo.sh' command does exactly that -- 'bin/geronimo.sh jpda
run'
> Missing commands for startup
>
>
> Key: GERONIMO-5997
> URL: https://issues.apache.org/jira/browse/GERONIMO-5997
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: commands, Jetty, startup/shutdown
>Affects Versions: 2.2
> Environment: Debian linux/squeeze
> Java 1.6 v19 sun
>Reporter: Leonardo Bueno Postacchini
> Attachments: geronimo.sh, geronimo_old.sh
>
>
> Documentations instructs launching geronimo with:
> geronimo jpda run
> or
> geronimo jpda start
> for remote debugging but attempting to do that result in message:
> Usage: geronimo {start|stop|restart|status}
> Edit: Change jpda -> jdpa
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6002) Can't configure defaultJspServlet parameters
[
https://issues.apache.org/jira/browse/GERONIMO-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046952#comment-13046952
]
Kevan Miller commented on GERONIMO-6002:
With these changes, can now override xml attributes in config.xml. For instance:
{code}
http://java.sun.com/xml/ns/javaee";>
jsp
org.apache.jasper.servlet.JspServlet
development
true
trimSpaces
true
fork
false
logVerbosityLevel
DEBUG
xpoweredBy
false
engineOptionsClass
org.apache.geronimo.jasper.JspServletOptions
0
jsp
*.jsp
*.jspf
*.jspx
*.xsp
{code}
Could add this to for jasper-deployer. But, should
consider letting var/catalina/conf/web.xml control these settings. Something
for later...
> Can't configure defaultJspServlet parameters
>
>
> Key: GERONIMO-6002
> URL: https://issues.apache.org/jira/browse/GERONIMO-6002
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Tomcat
>Affects Versions: 3.0
>Reporter: Kevan Miller
>Assignee: Kevan Miller
> Fix For: 3.0
>
>
> It's not currently possible to configure the defaultJspServlet properties.
> This means that you can't configure 'development' mode or trimSpaces.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6002) Can't configure defaultJspServlet parameters
Can't configure defaultJspServlet parameters Key: GERONIMO-6002 URL: https://issues.apache.org/jira/browse/GERONIMO-6002 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 3.0 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 3.0 It's not currently possible to configure the defaultJspServlet properties. This means that you can't configure 'development' mode or trimSpaces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5997) Missing commands for startup
[
https://issues.apache.org/jira/browse/GERONIMO-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046946#comment-13046946
]
Kevan Miller commented on GERONIMO-5997:
Hi Leonardo, thanks for the info. So, your geronimo_old.sh file looks like it
was generated by the gserviceReg.sh command. See
https://cwiki.apache.org/GMOxDOC22/running-geronimo-as-a-linux-service.html for
more information. I assume you or someone else ran './gserviceReg add geronimo'
(or similar) to generate a geronimo service. The resulting service script file
would look like your geronimo_old.sh.
gserviceReg.sh was not designed to create a service script which supported the
'jpda' option. I suppose it could, but I'm not sure it's a common use case...
If somebody feels it would be valuable, speak up...
So, if you use the 'geronimo.sh' script that's included in a geronimo download,
I believe you have the function you're looking for.
> Missing commands for startup
>
>
> Key: GERONIMO-5997
> URL: https://issues.apache.org/jira/browse/GERONIMO-5997
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: commands, Jetty, startup/shutdown
>Affects Versions: 2.2
> Environment: Debian linux/squeeze
> Java 1.6 v19 sun
>Reporter: Leonardo Bueno Postacchini
> Attachments: geronimo.sh, geronimo_old.sh
>
>
> Documentations instructs launching geronimo with:
> geronimo jpda run
> or
> geronimo jpda start
> for remote debugging but attempting to do that result in message:
> Usage: geronimo {start|stop|restart|status}
> Edit: Change jpda -> jdpa
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5997) Missing commands for startup
[
https://issues.apache.org/jira/browse/GERONIMO-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046194#comment-13046194
]
Kevan Miller commented on GERONIMO-5997:
OK. I don't know where your geronimo_old.sh file comes from. AFAIK, it's not
something maintained by the Geronimo project. Can you you tell us where it
comes from?
> Missing commands for startup
>
>
> Key: GERONIMO-5997
> URL: https://issues.apache.org/jira/browse/GERONIMO-5997
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: commands, Jetty, startup/shutdown
>Affects Versions: 2.2.1
> Environment: Debian linux/squeeze
> Java 1.6 v19 sun
>Reporter: Leonardo Bueno Postacchini
> Attachments: geronimo.sh, geronimo_old.sh
>
>
> Documentations instructs launching geronimo with:
> geronimo jpda run
> or
> geronimo jpda start
> for remote debugging but attempting to do that result in message:
> Usage: geronimo {start|stop|restart|status}
> Edit: Change jpda -> jdpa
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5997) Missing commands for startup
[
https://issues.apache.org/jira/browse/GERONIMO-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045530#comment-13045530
]
Kevan Miller commented on GERONIMO-5997:
What documentation are you referring to? That should be 'jpda' not 'jdpa'
./geronimo.sh jpda run works fine for me (though you've now got me trying to
type jdpa... ;-)
'./geronimo.sh jdpa run' gives me:
{quote}
$ ./geronimo.sh jdpa run
Using GERONIMO_HOME: /Users/kevan/Servers/geronimo-jetty7-javaee5-2.2.1
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
Usage: geronimo.sh command [geronimo_args]
commands:
debug Debug Geronimo in jdb debugger
jpda run Start Geronimo in foreground under JPDA debugger
jpda startStart Geronimo in background under JPDA debugger
run Start Geronimo in the foreground
start Start Geronimo in the background
stop Stop Geronimo
stop --force Stop Geronimo (followed by kill -KILL)
{quote}
> Missing commands for startup
>
>
> Key: GERONIMO-5997
> URL: https://issues.apache.org/jira/browse/GERONIMO-5997
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: commands, Jetty, startup/shutdown
>Affects Versions: 2.2.1
> Environment: Debian linux/squeeze
> Java 1.6 v19 sun
>Reporter: Leonardo Bueno Postacchini
>
> Documentations instructs launching geronimo with:
> geronimo jdpa run
> or
> geronimo jdpa start
> for remote debugging but attempting to do that result in message:
> Usage: geronimo {start|stop|restart|status}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5980) Improper encryption/obfuscation of passwords in configuration files
Improper encryption/obfuscation of passwords in configuration files
---
Key: GERONIMO-5980
URL: https://issues.apache.org/jira/browse/GERONIMO-5980
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Kevan Miller
Several users have reported problems starting Geronimo. The cause seems to be
improperly encrypted passwords. Plain text passwords will be
encrypted/obfuscated in configuration files. A very good hypothesis posed by
Michael Peterson is that the problem occurs if you try to start Geronimo with
an improperly configured JAVA_HOMEStarting Geronimo without a JAVA_HOME
configured may cause passwords to be improperly encrypted. They may end up
encrypted as {Simple}null
>From an email:
{quote}
On May 25, 2011, at 9:56 PM, michael.peterson wrote:
Ok...I think I see what was happening.
When I first installed and tried to run "geronimo.sh run" I didn't
have JAVA_HOME set. it failed with a bunch of messages. Then I
realized that problem and set JAVA_HOME...but it looks like that time
the property files have already been rewritten and the install
corrupted. I didn't realize it was happening at the time of
course...but since the new install was working I tried to redo the
step to get to that broken state. The only way I could achieve that
was to remove the JAVA_HOME and try and run geronimo.
Does that make sense to you?
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5975) Please give me Steps and Patch to Upgrade to Tomcat 6.0.29 from 5.5.20 in Apache Ofbiz
[ https://issues.apache.org/jira/browse/GERONIMO-5975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038222#comment-13038222 ] Kevan Miller commented on GERONIMO-5975: Hi. Are you using Apache Geronimo? If you want to run versions of Geronimo that contain Tomcat 6.0.29, then download Geronimo 2.1.7 or 2.2.1. If you have Apache Ofbiz questions, then create an OFBiz Jira (or send an email to their user list). > Please give me Steps and Patch to Upgrade to Tomcat 6.0.29 from 5.5.20 in > Apache Ofbiz > -- > > Key: GERONIMO-5975 > URL: https://issues.apache.org/jira/browse/GERONIMO-5975 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 2.1.6, 2.2 > Environment: Windows 2008 Standard Edition Server >Reporter: Daniel Olatunde >Assignee: Rex Wang >Priority: Blocker > Fix For: 2.1.7, 2.2.1 > > > Please give me Steps and Patch to Upgrade to Tomcat 6.0.29 from 5.5.20 in > Apache Ofbiz. I am having urgent PCI compliance faliures due to an > old/vulnerable TOMCAT version and i am unable to see clear and concise steps > to upgrade. My site is www.xzuberance.com and please note i am a NOVICE to > Apache Ofbiz. I can also be reahced via email at xzubera...@gmail.com. Please > HELP ASAP. > Thanks -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5751) LinkageError running CDI TCK
[ https://issues.apache.org/jira/browse/GERONIMO-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034503#comment-13034503 ] Kevan Miller commented on GERONIMO-5751: New builds of Equinox contain a fix for LinkageError's caused by cyclical classloading. > LinkageError running CDI TCK > > > Key: GERONIMO-5751 > URL: https://issues.apache.org/jira/browse/GERONIMO-5751 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 3.0-M2 >Reporter: Kevan Miller >Assignee: Kevan Miller > Fix For: 3.0 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-5751) LinkageError running CDI TCK
[ https://issues.apache.org/jira/browse/GERONIMO-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller resolved GERONIMO-5751. Resolution: Fixed Fix Version/s: (was: 3.0-M2) 3.0 > LinkageError running CDI TCK > > > Key: GERONIMO-5751 > URL: https://issues.apache.org/jira/browse/GERONIMO-5751 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 3.0-M2 >Reporter: Kevan Miller >Assignee: Kevan Miller > Fix For: 3.0 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5751) LinkageError running CDI TCK
[
https://issues.apache.org/jira/browse/GERONIMO-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032143#comment-13032143
]
Kevan Miller commented on GERONIMO-5751:
Here's a better stacktrace. At the top of the call stack, defineClass() has
been called for the second time, on the same thread, for the same class. This
defineClass will work.
{code}
"DefaultThreadPool 196" prio=5 tid=101dd3000 nid=0x12545e000 at
breakpoint[125458000]
java.lang.Thread.State: RUNNABLE
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:580)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:550)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:481)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:469)
- locked <7a66bf170> (a
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at
org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at
org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:338)
at
org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:232)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1197)
at
org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:75)
at java.lang.ClassLoader.loadClass(ClassLoader.java:296)
- locked <7a6b2b9b8> (a
org.apache.geronimo.kernel.classloader.TemporaryClassLoader)
at
org.apache.geronimo.kernel.classloader.TemporaryClassLoader.loadClass(TemporaryClassLoader.java:104)
- locked <7a6b2b9b8> (a
org.apache.geronimo.kernel.classloader.TemporaryClassLoader)
at
org.apache.geronimo.kernel.classloader.TemporaryClassLoader.loadClass(TemporaryClassLoader.java:62)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at
org.apache.openjpa.enhance.PCClassFileTransformer.needsEnhance(PCClassFileTransformer.java:195)
at
org.apache.openjpa.enhance.PCClassFileTransformer.transform0(PCClassFileTransformer.java:137)
at
org.apache.openjpa.enhance.PCClassFileTransformer.transform(PCClassFileTransformer.java:124)
at
org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.transform(PersistenceProviderImpl.java:294)
at
org.apache.geronimo.persistence.TransformerWrapper.transform(TransformerWrapper.java:43)
at
org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:52)
at
sun.instrument.TransformerManager.transform(TransformerManager.java:169)
at
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:580)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:550)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:481)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:469)
- locked <7a66bf170> (a
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
[jira] [Commented] (GERONIMO-5751) LinkageError running CDI TCK
[ https://issues.apache.org/jira/browse/GERONIMO-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032076#comment-13032076 ] Kevan Miller commented on GERONIMO-5751: This wasn't really a fix, but a work around. We've now got this hack in multiple places and it's still not enough. There are classloading environments not under our control. We need a better solution... I've created an Equinox bug report -- https://bugs.eclipse.org/bugs/show_bug.cgi?id=345500 There may be other solutions, but would be cool if Equinox could help detect this situation like Felix does. > LinkageError running CDI TCK > > > Key: GERONIMO-5751 > URL: https://issues.apache.org/jira/browse/GERONIMO-5751 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 3.0-M2 >Reporter: Kevan Miller >Assignee: Kevan Miller > Fix For: 3.0-M2 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (GERONIMO-5897) LinkageError running JCDI TCK
[
https://issues.apache.org/jira/browse/GERONIMO-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller closed GERONIMO-5897.
--
Resolution: Duplicate
This change didn't fix the fundamental problem. Though bumping up the OpenJPA
version was definitely a good thing to do...
It's also a duplicate of https://issues.apache.org/jira/browse/GERONIMO-5751
> LinkageError running JCDI TCK
> -
>
> Key: GERONIMO-5897
> URL: https://issues.apache.org/jira/browse/GERONIMO-5897
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: OpenWebBeans
>Affects Versions: 3.0
>Reporter: Kevan Miller
> Fix For: 3.0
>
>
> JCDI PersistenceContext tests are failing due to a LinkageError during
> deployment. This is basically the same sort of problem we saw a few months
> back (GERONIMO-5751) where OpenJPA class transformation is causing redundant
> defineClass() invocations in the same thread:
> {code}
> 2011-04-11 17:22:33,500 ERROR [GBeanInstanceState] Error while starting;
> GBean is now in the FAILED state:
> abstractName="default/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest/1302556935208/war?J2EEApplication=null,j2eeType=EJBModule,name=default/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest/1302556935208/war"
> org.apache.openejb.OpenEJBException: Creating application failed:
> /Users/kevan/geronimo/tck/branches/3.0/jcdi-tck-runner/target/geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT/var/temp/geronimo-deployer2101508723951611178.tmpdir/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest.war:
> loader (instance of
> org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader): attempted
> duplicate class definition for name: "org/testng/annotations/Test"
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:753)
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:462)
> at
> org.apache.geronimo.openejb.OpenEjbSystemGBean.createApplication(OpenEjbSystemGBean.java:438)
> at
> org.apache.geronimo.openejb.EjbModuleImpl.doStart(EjbModuleImpl.java:182)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:975)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560)
> at
> org
[jira] [Reopened] (GERONIMO-5751) LinkageError running CDI TCK
[ https://issues.apache.org/jira/browse/GERONIMO-5751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reopened GERONIMO-5751: Assignee: Kevan Miller > LinkageError running CDI TCK > > > Key: GERONIMO-5751 > URL: https://issues.apache.org/jira/browse/GERONIMO-5751 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 3.0-M2 >Reporter: Kevan Miller >Assignee: Kevan Miller > Fix For: 3.0-M2 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (GERONIMO-5897) LinkageError running JCDI TCK
[
https://issues.apache.org/jira/browse/GERONIMO-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller reopened GERONIMO-5897:
> LinkageError running JCDI TCK
> -
>
> Key: GERONIMO-5897
> URL: https://issues.apache.org/jira/browse/GERONIMO-5897
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: OpenWebBeans
>Affects Versions: 3.0
>Reporter: Kevan Miller
> Fix For: 3.0
>
>
> JCDI PersistenceContext tests are failing due to a LinkageError during
> deployment. This is basically the same sort of problem we saw a few months
> back (GERONIMO-5751) where OpenJPA class transformation is causing redundant
> defineClass() invocations in the same thread:
> {code}
> 2011-04-11 17:22:33,500 ERROR [GBeanInstanceState] Error while starting;
> GBean is now in the FAILED state:
> abstractName="default/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest/1302556935208/war?J2EEApplication=null,j2eeType=EJBModule,name=default/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest/1302556935208/war"
> org.apache.openejb.OpenEJBException: Creating application failed:
> /Users/kevan/geronimo/tck/branches/3.0/jcdi-tck-runner/target/geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT/var/temp/geronimo-deployer2101508723951611178.tmpdir/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest.war:
> loader (instance of
> org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader): attempted
> duplicate class definition for name: "org/testng/annotations/Test"
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:753)
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:462)
> at
> org.apache.geronimo.openejb.OpenEjbSystemGBean.createApplication(OpenEjbSystemGBean.java:438)
> at
> org.apache.geronimo.openejb.EjbModuleImpl.doStart(EjbModuleImpl.java:182)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:975)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
> at
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460)
> at
> org.apach
[jira] [Commented] (GERONIMO-5952) Error when i start the server Apache Geronimo v3.0
[ https://issues.apache.org/jira/browse/GERONIMO-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030989#comment-13030989 ] Kevan Miller commented on GERONIMO-5952: Hi Antonio, thanks for the information. We've had a few bugs in that area. Where server state wasn't saved, prior to shutdown. I expect you've hit one of those situations. > Error when i start the server Apache Geronimo v3.0 > -- > > Key: GERONIMO-5952 > URL: https://issues.apache.org/jira/browse/GERONIMO-5952 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: application client >Affects Versions: 3.0-M1 > Environment: Windows XP >Reporter: Antonio Nobre >Priority: Critical > Fix For: 3.0-M2, 3.0 > > > Hi, > I have the error below and make me nuts, because before the server runs > normaly but when i interrupted the server abrutally never work again. I make > lot of changes in file var\config\config.xml and the error is always the same. > I remove the configuration for "j2ee-system" in file config.xml and the error > don't change ... I changed the jar geronimo-kernel-3.0-M1.jar that could be > corrupted but the message was the same ... > Please consider this email important and thanks in advance. > Their is the error on console: > 2011-05-09 19:07:39,171 ERROR [GBeanInstanceState] Error while starting; > GBean is now in the FAILED state: > abstractName="org.apache.geronimo.framework/j2ee-system/3.0-M1/car?ServiceModule=org.apache.geronimo.framework/j2ee-system/3.0-M1/car,j2eeType=GBean,name=GeronimoOBR" > java.util.zip.ZipException: error in opening zip file > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:127) > at java.util.jar.JarFile.(JarFile.java:135) > at java.util.jar.JarFile.(JarFile.java:99) > at > org.apache.geronimo.obr.GeronimoOBRGBean.generateOBRModel(GeronimoOBRGBean.java:114) > at > org.apache.geronimo.obr.GeronimoOBRGBean.generateOBR(GeronimoOBRGBean.java:96) > at > org.apache.geronimo.obr.GeronimoOBRGBean.generateOBR(GeronimoOBRGBean.java:92) > at > org.apache.geronimo.obr.GeronimoOBRGBean.doStart(GeronimoOBRGBean.java:172) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:959) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:530) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145) > at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:295) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:544) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:461) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:216) > at > org.apache.geronimo.system.osgi.BootActivator.start(BootActivator.java:70) > at > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:661) > at org.apache.felix.framework.Felix.activateBundle(Felix.java:1760) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1682) > at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1128) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:662) > 2011-05-09 19:07:39,328 ERROR [GBeanInstanceState] Error while starting; > GBean is now in the FAILED state: > abstractName="org.apache.geronimo.framewo
[jira] [Commented] (GERONIMO-5952) Error when i start the server Apache Geronimo v3.0
[ https://issues.apache.org/jira/browse/GERONIMO-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030867#comment-13030867 ] Kevan Miller commented on GERONIMO-5952: Are you sure your install (tar x/unzip) worked? A bad install would be my first guess. M1 starts fine for me. We don't capture the name of the archive file in error. Has the server ever started? What OS are you running? I'd first try and re-install into a fresh/clean directory. You won't be able to start without j2ee-system. Attempts to delete j2ee-system from config.xml will be futile... ;-) M1 is pretty dated. If you want to experiment with recent, unreleased, trunk builds, you can try a download from https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6-web/3.0-SNAPSHOT/ (or similar location for the assembly of your choice). However, don't think there is a "fix" for this issue. Not a problem I recall anyone running into, previously. > Error when i start the server Apache Geronimo v3.0 > -- > > Key: GERONIMO-5952 > URL: https://issues.apache.org/jira/browse/GERONIMO-5952 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: application client >Affects Versions: 3.0-M1 > Environment: Windows XP >Reporter: Antonio Nobre >Priority: Critical > Fix For: 3.0-M2, 3.0 > > > Hi, > I have the error below and make me nuts, because before the server runs > normaly but when i interrupted the server abrutally never work again. I make > lot of changes in file var\config\config.xml and the error is always the same. > I remove the configuration for "j2ee-system" in file config.xml and the error > don't change ... I changed the jar geronimo-kernel-3.0-M1.jar that could be > corrupted but the message was the same ... > Please consider this email important and thanks in advance. > Their is the error on console: > 2011-05-09 19:07:39,171 ERROR [GBeanInstanceState] Error while starting; > GBean is now in the FAILED state: > abstractName="org.apache.geronimo.framework/j2ee-system/3.0-M1/car?ServiceModule=org.apache.geronimo.framework/j2ee-system/3.0-M1/car,j2eeType=GBean,name=GeronimoOBR" > java.util.zip.ZipException: error in opening zip file > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:127) > at java.util.jar.JarFile.(JarFile.java:135) > at java.util.jar.JarFile.(JarFile.java:99) > at > org.apache.geronimo.obr.GeronimoOBRGBean.generateOBRModel(GeronimoOBRGBean.java:114) > at > org.apache.geronimo.obr.GeronimoOBRGBean.generateOBR(GeronimoOBRGBean.java:96) > at > org.apache.geronimo.obr.GeronimoOBRGBean.generateOBR(GeronimoOBRGBean.java:92) > at > org.apache.geronimo.obr.GeronimoOBRGBean.doStart(GeronimoOBRGBean.java:172) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:959) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:530) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145) > at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:295) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:544) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:461) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:216) > at > org.apache.geronimo.system.osgi.BootActivato
[jira] [Closed] (GERONIMO-5946) error when starting server with -noverify option
[
https://issues.apache.org/jira/browse/GERONIMO-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller closed GERONIMO-5946.
--
Working for me. Thanks Jarek.
> error when starting server with -noverify option
>
>
> Key: GERONIMO-5946
> URL: https://issues.apache.org/jira/browse/GERONIMO-5946
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 3.0
>Reporter: Kevan Miller
>Assignee: Jarek Gawor
> Fix For: 3.0
>
>
> If you set the "-noverify" java option will result in the following exception
> and server startup fails:
> {code}
> java.lang.NoClassDefFoundError: org/apache/xbean/asm/ClassReader
> at
> org.apache.xbean.recipe.XbeanAsmParameterNameLoader.createClassReader(XbeanAsmParameterNameLoader.java:201)
> at
> org.apache.xbean.recipe.XbeanAsmParameterNameLoader.getAllConstructorParameters(XbeanAsmParameterNameLoader.java:111)
> at
> org.apache.xbean.recipe.XbeanAsmParameterNameLoader.get(XbeanAsmParameterNameLoader.java:82)
> at
> org.apache.xbean.recipe.ReflectionUtil.getParameterNames(ReflectionUtil.java:906)
> at
> org.apache.xbean.recipe.ReflectionUtil.findConstructor(ReflectionUtil.java:636)
> at
> org.apache.xbean.recipe.ObjectRecipe.findFactory(ObjectRecipe.java:563)
> at
> org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:274)
> 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.ExecutorType.getExecutor(ExecutorType.java:127)
> at
> org.apache.geronimo.tomcat.model.ServiceType.getService(ServiceType.java:281)
> at
> org.apache.geronimo.tomcat.model.ServerType.build(ServerType.java:300)
> at
> org.apache.geronimo.tomcat.TomcatServerGBean.(TomcatServerGBean.java:141)
> 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:933)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
> at
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460)
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:226)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:702)
> at
> org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:211)
> at
> org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:91)
> at
> org.apache.geronimo.system.osgi.BootActivator$1.execute(BootActivator.java:107)
> at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
> at
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
> at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32)
> Caused by: java.lang.ClassNotFoundException: org.apache.xbean.asm.ClassReader
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
> at
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
> at java.lang.ClassLoader.loadClass(ClassLoader.j
[jira] [Created] (GERONIMO-5946) error when starting server with -noverify option
error when starting server with -noverify option
Key: GERONIMO-5946
URL: https://issues.apache.org/jira/browse/GERONIMO-5946
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 3.0
Reporter: Kevan Miller
Fix For: 3.0
If you set the "-noverify" java option will result in the following exception
and server startup fails:
{code}
java.lang.NoClassDefFoundError: org/apache/xbean/asm/ClassReader
at
org.apache.xbean.recipe.XbeanAsmParameterNameLoader.createClassReader(XbeanAsmParameterNameLoader.java:201)
at
org.apache.xbean.recipe.XbeanAsmParameterNameLoader.getAllConstructorParameters(XbeanAsmParameterNameLoader.java:111)
at
org.apache.xbean.recipe.XbeanAsmParameterNameLoader.get(XbeanAsmParameterNameLoader.java:82)
at
org.apache.xbean.recipe.ReflectionUtil.getParameterNames(ReflectionUtil.java:906)
at
org.apache.xbean.recipe.ReflectionUtil.findConstructor(ReflectionUtil.java:636)
at
org.apache.xbean.recipe.ObjectRecipe.findFactory(ObjectRecipe.java:563)
at
org.apache.xbean.recipe.ObjectRecipe.internalCreate(ObjectRecipe.java:274)
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.ExecutorType.getExecutor(ExecutorType.java:127)
at
org.apache.geronimo.tomcat.model.ServiceType.getService(ServiceType.java:281)
at
org.apache.geronimo.tomcat.model.ServerType.build(ServerType.java:300)
at
org.apache.geronimo.tomcat.TomcatServerGBean.(TomcatServerGBean.java:141)
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:933)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:226)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:702)
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:211)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:91)
at
org.apache.geronimo.system.osgi.BootActivator$1.execute(BootActivator.java:107)
at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32)
Caused by: java.lang.ClassNotFoundException: org.apache.xbean.asm.ClassReader
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 36 more
{code}
Problem is that -noverify is turning off early detection of classloading issues
in the following org.apache.xbean.recipe.ReflectionUtil code:
{code}
static
{
String[] impls = { "org.apache.xbean.recipe.XbeanAsmParameterNameLoader",
"org.apache.xbean.recipe.AsmParameterNameLoader" };
for (String impl : impls)
try {
Class loaderClass =
ReflectionUtil.class.getClassLoader().loadClass(impl)
[jira] [Commented] (GERONIMO-5096) Integrate Wink JAX-RS implementation into Geronimo.
[ https://issues.apache.org/jira/browse/GERONIMO-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027822#comment-13027822 ] Kevan Miller commented on GERONIMO-5096: Hi Sastry, don't think Jersey would make any difference one way or another on these issues. AFAIK, nobody has looked at Jersey integration. Only Wink, up to this point. Anything in particular that you're looking for? > Integrate Wink JAX-RS implementation into Geronimo. > > > Key: GERONIMO-5096 > URL: https://issues.apache.org/jira/browse/GERONIMO-5096 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: javaee6, webservices >Affects Versions: 3.0 >Reporter: Rick McGuire >Assignee: Shawn Jiang > Fix For: 3.0 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5941) JSR-299 Policy Available test failure
JSR-299 Policy Available test failure - Key: GERONIMO-5941 URL: https://issues.apache.org/jira/browse/GERONIMO-5941 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 We're getting the following test failure running JSR-299 CTS: Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 43.646 sec <<< FAILURE! testEnabledPolicyAvailable(org.jboss.jsr299.tck.tests.policy.enterprise.SessionBeanPolicyTest) Time elapsed: 1.895 sec <<< FAILURE! java.lang.AssertionError at org.jboss.jsr299.tck.tests.policy.enterprise.SessionBeanPolicyTest.testEnabledPolicyAvailable(SessionBeanPolicyTest.java:41) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5940) JSR-299 PersistenceContextInjectionTests are failing
[
https://issues.apache.org/jira/browse/GERONIMO-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller updated GERONIMO-5940:
---
Attachment:
org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest.war
Making things a bit easier, here's the war file that's being deployed...
> JSR-299 PersistenceContextInjectionTests are failing
>
>
> Key: GERONIMO-5940
> URL: https://issues.apache.org/jira/browse/GERONIMO-5940
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 3.0
>Reporter: Kevan Miller
> Fix For: 3.0
>
> Attachments:
> org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest.war
>
>
> The tests:
> {code}
> Failed tests:
>
> testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>
> testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>
> testBeanTypesAndBindingTypesOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>
> testInjectionOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>
> testInjectionOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
> {code}
> are failing because of the following deployment error:
> {code}
> org.apache.geronimo.common.DeploymentException: No default PersistenceUnit
> specified, and none located
> at
> org.apache.geronimo.persistence.builder.PersistenceRefBuilder.findPersistenceUnitQuery(PersistenceRefBuilder.java:215)
> at
> org.apache.geronimo.persistence.builder.PersistenceRefBuilder.buildNaming(PersistenceRefBuilder.java:165)
> at
> org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:70)
> at
> org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:70)
> at
> org.apache.geronimo.openwebbeans.deployment.OpenWebBeansModuleBuilderExtension.addGBeans(OpenWebBeansModuleBuilderExtension.java:154)
> at
> org.apache.geronimo.jetty8.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:538)
> at
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:174)
> at
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:724)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:252)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138)
> 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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
> at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:344)
> 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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
> at
> org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
> at
> javax.management.remote.rmi.RMI
[jira] [Updated] (GERONIMO-5940) JSR-299 PersistenceContextInjectionTests are failing
[
https://issues.apache.org/jira/browse/GERONIMO-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller updated GERONIMO-5940:
---
Affects Version/s: 3.0
Fix Version/s: 3.0
> JSR-299 PersistenceContextInjectionTests are failing
>
>
> Key: GERONIMO-5940
> URL: https://issues.apache.org/jira/browse/GERONIMO-5940
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 3.0
>Reporter: Kevan Miller
> Fix For: 3.0
>
>
> The tests:
> {code}
> Failed tests:
>
> testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>
> testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>
> testBeanTypesAndBindingTypesOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>
> testInjectionOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>
> testInjectionOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
> {code}
> are failing because of the following deployment error:
> {code}
> org.apache.geronimo.common.DeploymentException: No default PersistenceUnit
> specified, and none located
> at
> org.apache.geronimo.persistence.builder.PersistenceRefBuilder.findPersistenceUnitQuery(PersistenceRefBuilder.java:215)
> at
> org.apache.geronimo.persistence.builder.PersistenceRefBuilder.buildNaming(PersistenceRefBuilder.java:165)
> at
> org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:70)
> at
> org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:70)
> at
> org.apache.geronimo.openwebbeans.deployment.OpenWebBeansModuleBuilderExtension.addGBeans(OpenWebBeansModuleBuilderExtension.java:154)
> at
> org.apache.geronimo.jetty8.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:538)
> at
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:174)
> at
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:724)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:252)
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138)
> 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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
> at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:344)
> 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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
> at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
> at
> org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
> at java.se
[jira] [Created] (GERONIMO-5940) JSR-299 PersistenceContextInjectionTests are failing
JSR-299 PersistenceContextInjectionTests are failing
Key: GERONIMO-5940
URL: https://issues.apache.org/jira/browse/GERONIMO-5940
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Kevan Miller
The tests:
{code}
Failed tests:
testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testBeanTypesAndBindingTypesOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testInjectionOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testInjectionOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
{code}
are failing because of the following deployment error:
{code}
org.apache.geronimo.common.DeploymentException: No default PersistenceUnit
specified, and none located
at
org.apache.geronimo.persistence.builder.PersistenceRefBuilder.findPersistenceUnitQuery(PersistenceRefBuilder.java:215)
at
org.apache.geronimo.persistence.builder.PersistenceRefBuilder.buildNaming(PersistenceRefBuilder.java:165)
at
org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:70)
at
org.apache.geronimo.j2ee.deployment.NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:70)
at
org.apache.geronimo.openwebbeans.deployment.OpenWebBeansModuleBuilderExtension.addGBeans(OpenWebBeansModuleBuilderExtension.java:154)
at
org.apache.geronimo.jetty8.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:538)
at
org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:174)
at
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:724)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:252)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138)
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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:344)
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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
at
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1367)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Deleg
[jira] [Commented] (GERONIMO-5896) ContextNotActiveException running JCDI TCK
[
https://issues.apache.org/jira/browse/GERONIMO-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026670#comment-13026670
]
Kevan Miller commented on GERONIMO-5896:
For the record, the test failures caused by this basic issue are:
{code}
testApplicationScopeActiveDuringHttpSessionListenerInvocation(org.jboss.jsr299.tck.tests.context.application.ApplicationContextTest)
testApplicationScopeActiveDuringServiceMethod(org.jboss.jsr299.tck.tests.context.application.ApplicationContextTest)
testApplicationScopeActiveDuringServletRequestListenerInvocation(org.jboss.jsr299.tck.tests.context.application.ApplicationContextTest)
testApplicationScopeActiveDuringDoFilterMethod(org.jboss.jsr299.tck.tests.context.application.ApplicationContextTest)
testApplicationScopeActiveDuringServletContextListenerInvocation(org.jboss.jsr299.tck.tests.context.application.ApplicationContextTest)
testApplicationContextSharedBetweenServletRequests(org.jboss.jsr299.tck.tests.context.application.ApplicationContextTest)
{code}
My patch fixes these, but may not be the appropriate fix...
There are 9 remaining issues (and are the same in Tomcat and Jetty assemblies):
{code}
testDecoratorInvocation(org.jboss.jsr299.tck.tests.decorators.invocation.DecoratorInvocationTest)
testChainedDecoratorInvocation(org.jboss.jsr299.tck.tests.decorators.invocation.DecoratorInvocationTest)
testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest)
testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testInjectionOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testInjectionOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testBeanTypesAndBindingTypesOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
testEnabledPolicyAvailable(org.jboss.jsr299.tck.tests.policy.enterprise.SessionBeanPolicyTest)
{code}
> ContextNotActiveException running JCDI TCK
> --
>
> Key: GERONIMO-5896
> URL: https://issues.apache.org/jira/browse/GERONIMO-5896
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: OpenWebBeans
>Reporter: Kevan Miller
> Fix For: 3.0
>
> Attachments: owb-lifecycle.patch
>
>
> Running the JCDI tck can result in some exceptions like the following:
> {code}
> 2011-04-09 23:53:45,964 ERROR [ApplicationContextTest]] Exception sending
> context initialized event to listener instance of class
> org.jboss.jsr299.tck.test\
> s.context.application.TestServletContextListener
> javax.enterprise.context.ContextNotActiveException: WebBeans context with
> scope type annotation @ApplicationScoped does not exist within current thread
> at
> org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:341)
> at
> org.apache.webbeans.container.InjectableBeanManager.getContext(InjectableBeanManager.java:115)
> at
> org.jboss.jsr299.tck.tests.context.application.TestServletContextListener.contextInitialized(TestServletContextListener.java:38)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4521)
> at
> org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5004)
> at
> org.apache.catalina.core.StandardContext$1.call(StandardContext.java:4999)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> 2011-04-09 23:53:45,965 ERROR [StandardContext] Error listenerStart
> {code}
> This is because the OpenWebBeans application initialization is not being
> driven. Geronimo's WebBeansConfigurationListener
> (plugins/openwebbeans/geronimo-openwebbeans/src/main/java/org/apache/geronimo/openwebbeans/WebBeansConfigurationListener.java)
> is (has become?) somewhat different from OpenWebBeans
> WebBeansConfigurationListener). Namely, in
> contextInitialized(ServletConextEvent) we don't have:
> {code}
>this.lifeCycle.startApplication(event);
> {code}
--
This message is automatically generated by JIRA.
For m
[jira] [Updated] (GERONIMO-5896) ContextNotActiveException running JCDI TCK
[
https://issues.apache.org/jira/browse/GERONIMO-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller updated GERONIMO-5896:
---
Attachment: owb-lifecycle.patch
I hacked this together. There's probably a better solution. This got me down to
9 errors. I'm thinking that it's the same 9 failures we see with jetty (but
haven't verified it). My build environment is messed up, now...
> ContextNotActiveException running JCDI TCK
> --
>
> Key: GERONIMO-5896
> URL: https://issues.apache.org/jira/browse/GERONIMO-5896
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: OpenWebBeans
>Reporter: Kevan Miller
> Fix For: 3.0
>
> Attachments: owb-lifecycle.patch
>
>
> Running the JCDI tck can result in some exceptions like the following:
> {code}
> 2011-04-09 23:53:45,964 ERROR [ApplicationContextTest]] Exception sending
> context initialized event to listener instance of class
> org.jboss.jsr299.tck.test\
> s.context.application.TestServletContextListener
> javax.enterprise.context.ContextNotActiveException: WebBeans context with
> scope type annotation @ApplicationScoped does not exist within current thread
> at
> org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:341)
> at
> org.apache.webbeans.container.InjectableBeanManager.getContext(InjectableBeanManager.java:115)
> at
> org.jboss.jsr299.tck.tests.context.application.TestServletContextListener.contextInitialized(TestServletContextListener.java:38)
> at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4521)
> at
> org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5004)
> at
> org.apache.catalina.core.StandardContext$1.call(StandardContext.java:4999)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> 2011-04-09 23:53:45,965 ERROR [StandardContext] Error listenerStart
> {code}
> This is because the OpenWebBeans application initialization is not being
> driven. Geronimo's WebBeansConfigurationListener
> (plugins/openwebbeans/geronimo-openwebbeans/src/main/java/org/apache/geronimo/openwebbeans/WebBeansConfigurationListener.java)
> is (has become?) somewhat different from OpenWebBeans
> WebBeansConfigurationListener). Namely, in
> contextInitialized(ServletConextEvent) we don't have:
> {code}
>this.lifeCycle.startApplication(event);
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-5897) LinkageError running JCDI TCK
[
https://issues.apache.org/jira/browse/GERONIMO-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller resolved GERONIMO-5897.
Resolution: Fixed
Fix Version/s: 3.0
Fixed by 1092539. Looks like I forgot to include the JIRA info in my commit
message.
> LinkageError running JCDI TCK
> -
>
> Key: GERONIMO-5897
> URL: https://issues.apache.org/jira/browse/GERONIMO-5897
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: OpenWebBeans
>Affects Versions: 3.0
>Reporter: Kevan Miller
> Fix For: 3.0
>
>
> JCDI PersistenceContext tests are failing due to a LinkageError during
> deployment. This is basically the same sort of problem we saw a few months
> back (GERONIMO-5751) where OpenJPA class transformation is causing redundant
> defineClass() invocations in the same thread:
> {code}
> 2011-04-11 17:22:33,500 ERROR [GBeanInstanceState] Error while starting;
> GBean is now in the FAILED state:
> abstractName="default/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest/1302556935208/war?J2EEApplication=null,j2eeType=EJBModule,name=default/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest/1302556935208/war"
> org.apache.openejb.OpenEJBException: Creating application failed:
> /Users/kevan/geronimo/tck/branches/3.0/jcdi-tck-runner/target/geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT/var/temp/geronimo-deployer2101508723951611178.tmpdir/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest.war:
> loader (instance of
> org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader): attempted
> duplicate class definition for name: "org/testng/annotations/Test"
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:753)
> at
> org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:462)
> at
> org.apache.geronimo.openejb.OpenEjbSystemGBean.createApplication(OpenEjbSystemGBean.java:438)
> at
> org.apache.geronimo.openejb.EjbModuleImpl.doStart(EjbModuleImpl.java:182)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:975)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
>
[jira] [Commented] (GERONIMO-5930) deployed an ejb web application then "unable to clear Sun JarFileFactory cache" error message appeared in geronimo.log file after shutdown the server
[ https://issues.apache.org/jira/browse/GERONIMO-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023210#comment-13023210 ] Kevan Miller commented on GERONIMO-5930: Full information on the error log would be useful -- i.e. the exception that's occurring would be useful. I doubt that there is much point in OpenEJB attempting to clear this cache, any longer. And the "error" is almost certainly a non *error*. However, good to clean this up... BTW, changing the Jira like this from one problem to another makes things confusing. Would prefer to see us closing one jira and creating another. > deployed an ejb web application then "unable to clear Sun JarFileFactory > cache" error message appeared in geronimo.log file after shutdown the server > --- > > Key: GERONIMO-5930 > URL: https://issues.apache.org/jira/browse/GERONIMO-5930 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 3.0 > Environment: JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 > jvmwi3260sr9-20101209_70480 (JIT enabled, AOT enabled) >Reporter: Tina Li > Attachments: asynEJB-test-3.0-SNAPSHOT.war > > > 1. Use the server build 2011.04.18-19:18:09.016+0800 of geronimo server > 3.0-SNAPSHOT > 2. Start the server if it's not started > 3. Deploy the webapp in > trunk\testsuite\javaee6-testsuite\ejb3.1-test\asynEJB-test and jndiEJB-test > via admin console > 4. Warning message displyed on the server console: > 2011-04-22 16:13:22,961 WARN [Parameters] Parameters: Invalid chunk '' > ignored. > 2011-04-22 16:13:23,164 WARN [startup] Unresolved ejb reference > "org.apache.geronimo.javaee6.asynejb.servlet.testServlet/myEJB" in bean > "GeronimoEnc". Will attempt resolution again at runtime. > 2011-04-22 16:13:23,164 WARN [startup] Unresolved ejb reference > "org.apache.geronimo.javaee6.asynejb.servlet.writeDBServlet/myEJB" in bean > "GeronimoEnc". Will attempt resolution again at runtime. > 2011-04-22 16:13:23,305 WARN [startup] Unresolved ejb reference > "org.apache.geronimo.javaee6.asynejb.servlet.testServlet/myEJB" in bean > "GeronimoEnc". Will attempt resolution again at runtime. > 2011-04-22 16:13:23,305 WARN [startup] Unresolved ejb reference > "org.apache.geronimo.javaee6.asynejb.servlet.writeDBServlet/myEJB" in bean > "GeronimoEnc". Will attempt resolution again at runtime. > 2011-04-22 16:13:23,305 WARN [startup] Unresolved ejb reference > "org.apache.geronimo.javaee6.asynejb.servlet.testServlet/myEJB" in bean > "GeronimoEnc". Will attempt resolution again at runtime. > 2011-04-22 16:13:23,305 WARN [startup] Unresolved ejb reference > "org.apache.geronimo.javaee6.asynejb.servlet.writeDBServlet/myEJB" in bean > "GeronimoEnc". Will attempt resolution again at runtime. > 2011-04-22 16:13:23,945 INFO [SupportedModesServiceImpl] Portlet mode 'edit' > not found for portletId: 'plugin.Deployment!-2135677113|0' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5920) Error deploying EJB jar with bean names containing international characters
Error deploying EJB jar with bean names containing international characters
---
Key: GERONIMO-5920
URL: https://issues.apache.org/jira/browse/GERONIMO-5920
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.2.1
Reporter: Kevan Miller
A user reported the following error deploying an ejb jar containing beans with
international characters. They also reported that specifying
"-Dfile.encoding=UTF8" as GERONIMO/JAVA_OPTS resolved the issue. This was on
windows.
Are international characters valid, spec-wise? If so, we should consider
updating our startup script. This behavior may be windows specific.
{code}
2011-04-18 18:45:58,666 ERROR [DirectoryHotDeployer] Unable to deploy: EJB not
gbean not found 测试�务器.MapServer
org.apache.geronimo.common.DeploymentException: EJB not gbean not found
测试�务器.MapServer
at
org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.getEjbGBean(EjbDeploymentBuilder.java:462)
at
org.apache.geronimo.openejb.deployment.EjbDeploymentBuilder.buildEnc(EjbDeploymentBuilder.java:382)
at
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.addGBeans(EjbModuleBuilder.java:764)
at
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:652)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
at
org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:136)
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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
at
org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at
org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
at java.lang.Thread.run(Thread.java:619)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5919) WAB does not support jsp.
[ https://issues.apache.org/jira/browse/GERONIMO-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021559#comment-13021559 ] Kevan Miller commented on GERONIMO-5919: Thanks Shawn. As a permanent fix is added, let's be sure and get a JSP test added to our Junit tests. > WAB does not support jsp. > - > > Key: GERONIMO-5919 > URL: https://issues.apache.org/jira/browse/GERONIMO-5919 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: osgi >Affects Versions: 3.0 >Reporter: Shawn Jiang > Attachments: simple-wab-3.0-SNAPSHOT.jar > > > 1, deploy the attached simple wab > 2, access the simple jsp in it. http://localhost:8080/simple/index.jsp > 3, you could see following exception. > Can't recreate if you deploy a similar war package. I'm not sure if current > web extender has added the jsp servlet correctly to handle the jsp. > > HTTP Status 500 - > type Exception report > message > description The server encountered an internal error () that prevented it > from fulfilling this request. > exception > org.apache.jasper.JasperException: Unable to compile class for JSP: > An error occurred at line: 7 in the generated java file > org.apache.jasper.runtime.HttpJspBase cannot be resolved to a type > An error occurred at line: 8 in the generated java file > org.apache.jasper.runtime.JspSourceDependent cannot be resolved to a type > An error occurred at line: 10 in the generated java file > JspFactory cannot be resolved to a type > An error occurred at line: 10 in the generated java file > JspFactory cannot be resolved > An error occurred at line: 14 in the generated java file > javax.el.ExpressionFactory cannot be resolved to a type > An error occurred at line: 15 in the generated java file > org.apache.tomcat.InstanceManager cannot be resolved to a type > An error occurred at line: 22 in the generated java file > _el_expressionfactory cannot be resolved > An error occurred at line: 22 in the generated java file > _jspxFactory cannot be resolved > An error occurred at line: 22 in the generated java file > The method getServletConfig() is undefined for the type index_jsp > An error occurred at line: 23 in the generated java file > _jsp_instancemanager cannot be resolved > An error occurred at line: 23 in the generated java file > org.apache.jasper.runtime.InstanceManagerFactory cannot be resolved to a type > An error occurred at line: 23 in the generated java file > The method getServletConfig() is undefined for the type index_jsp > An error occurred at line: 32 in the generated java file > PageContext cannot be resolved to a type > An error occurred at line: 36 in the generated java file > JspWriter cannot be resolved to a type > An error occurred at line: 38 in the generated java file > JspWriter cannot be resolved to a type > An error occurred at line: 39 in the generated java file > PageContext cannot be resolved to a type > An error occurred at line: 44 in the generated java file > _jspxFactory cannot be resolved > An error occurred at line: 81 in the generated java file > SkipPageException cannot be resolved to a type > An error occurred at line: 88 in the generated java file > _jspxFactory cannot be resolved > Stacktrace: > > org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:92) > > org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:330) > > org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:443) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:367) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:345) > org.apache.jasper.compiler.Compiler.compile(Compiler.java:332) > > org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:594) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:327) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:363) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:306) > javax.servlet.http.HttpServlet.service(HttpServlet.java:668) > note The full stack trace of the root cause is available in the Apache > Tomcat/7.0.0.2-SNAPSHOT logs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-5915) IOException reading directory monitor state from .DirectoryMonitor java.io.EOFException appear in geronimo.log file as info
[ https://issues.apache.org/jira/browse/GERONIMO-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller resolved GERONIMO-5915. Resolution: Fixed Fix Version/s: 3.0 Cleaned up log message. In particular, removed the exception... This is not an error. > IOException reading directory monitor state from .DirectoryMonitor > java.io.EOFException appear in geronimo.log file as info > --- > > Key: GERONIMO-5915 > URL: https://issues.apache.org/jira/browse/GERONIMO-5915 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: commands >Affects Versions: 3.0 > Environment: JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 > jvmwi3260sr9-20101209_70480 (JIT enabled, AOT enabled) >Reporter: Tina Li >Assignee: Kevan Miller >Priority: Trivial > Fix For: 3.0 > > > 1.Use April 15 build of Geronimo server > 2.Start the server using command: startup.bat under /bin > directory if the server is not started > 3.Check geronimo.log and found the info : > 2011-04-18 16:21:26,640 INFO [DirectoryMonitor] IOException reading > directory monitor state from .DirectoryMonitor > java.io.EOFException > at > java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2298) > at > java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2767) > at > java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:794) > at java.io.ObjectInputStream.(ObjectInputStream.java:294) > at > org.apache.geronimo.deployment.hot.DirectoryMonitor.readState(DirectoryMonitor.java:241) > at > org.apache.geronimo.deployment.hot.DirectoryMonitor.(DirectoryMonitor.java:137) > at > org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(DirectoryHotDeployer.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:975) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:226) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:702) > at > org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:211) > at > org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:91) > at > org.apache.geronimo.system.osgi.BootActivator$1.execute(BootActivator.java:107) > at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) > at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) > at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-5915) IOException reading directory monitor state from .DirectoryMonitor java.io.EOFException appear in geronimo.log file as info
[ https://issues.apache.org/jira/browse/GERONIMO-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-5915: -- Assignee: Kevan Miller > IOException reading directory monitor state from .DirectoryMonitor > java.io.EOFException appear in geronimo.log file as info > --- > > Key: GERONIMO-5915 > URL: https://issues.apache.org/jira/browse/GERONIMO-5915 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: commands >Affects Versions: 3.0 > Environment: JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 > jvmwi3260sr9-20101209_70480 (JIT enabled, AOT enabled) >Reporter: Tina Li >Assignee: Kevan Miller >Priority: Trivial > > 1.Use April 15 build of Geronimo server > 2.Start the server using command: startup.bat under /bin > directory if the server is not started > 3.Check geronimo.log and found the info : > 2011-04-18 16:21:26,640 INFO [DirectoryMonitor] IOException reading > directory monitor state from .DirectoryMonitor > java.io.EOFException > at > java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2298) > at > java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2767) > at > java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:794) > at java.io.ObjectInputStream.(ObjectInputStream.java:294) > at > org.apache.geronimo.deployment.hot.DirectoryMonitor.readState(DirectoryMonitor.java:241) > at > org.apache.geronimo.deployment.hot.DirectoryMonitor.(DirectoryMonitor.java:137) > at > org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(DirectoryHotDeployer.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:975) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:226) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:702) > at > org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:211) > at > org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:91) > at > org.apache.geronimo.system.osgi.BootActivator$1.execute(BootActivator.java:107) > at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) > at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) > at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5898) ClassCastException during deployment of some JCDI TCK
ClassCastException during deployment of some JCDI TCK
-
Key: GERONIMO-5898
URL: https://issues.apache.org/jira/browse/GERONIMO-5898
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: OpenWebBeans
Reporter: Kevan Miller
Fix For: 3.0
Final JCDI TCK issue (I hope). During deployment of some apps, we're getting
the following exception (this is with an updated
WebBeansConfigurationListener.java). So, will need to resolve wrt. GERONIMO-5896
Here's the exception we get:
{code}
2011-04-10 20:28:22,185 ERROR [DecoratorInvocationTest]] Exception sending
context initialized event to listener instance of class
org.apache.geronimo.openwebbeans.WebBeansConfigurationListener
java.lang.ClassCastException: javax.servlet.ServletContextEvent cannot be cast
to org.apache.openejb.cdi.StartupObject
at
org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:110)
at
org.apache.geronimo.openwebbeans.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:86)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4521)
at
org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5004)
at
org.apache.catalina.core.StandardContext$1.call(StandardContext.java:4999)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
{code}
This appears to be the cause of the remaining test failures. So, this might be
the final fix needed to clear up the JSR-299 tests...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5897) LinkageError running JCDI TCK
LinkageError running JCDI TCK
-
Key: GERONIMO-5897
URL: https://issues.apache.org/jira/browse/GERONIMO-5897
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: OpenWebBeans
Affects Versions: 3.0
Reporter: Kevan Miller
JCDI PersistenceContext tests are failing due to a LinkageError during
deployment. This is basically the same sort of problem we saw a few months back
(GERONIMO-5751) where OpenJPA class transformation is causing redundant
defineClass() invocations in the same thread:
{code}
2011-04-11 17:22:33,500 ERROR [GBeanInstanceState] Error while starting; GBean
is now in the FAILED state:
abstractName="default/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest/1302556935208/war?J2EEApplication=null,j2eeType=EJBModule,name=default/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest/1302556935208/war"
org.apache.openejb.OpenEJBException: Creating application failed:
/Users/kevan/geronimo/tck/branches/3.0/jcdi-tck-runner/target/geronimo-tomcat7-javaee6-web-3.0-SNAPSHOT/var/temp/geronimo-deployer2101508723951611178.tmpdir/org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest.war:
loader (instance of
org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader): attempted duplicate
class definition for name: "org/testng/annotations/Test"
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:753)
at
org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:462)
at
org.apache.geronimo.openejb.OpenEjbSystemGBean.createApplication(OpenEjbSystemGBean.java:438)
at
org.apache.geronimo.openejb.EjbModuleImpl.doStart(EjbModuleImpl.java:182)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:975)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:546)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:175)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:253)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:560)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:460)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:226)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:702)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurati
[jira] [Created] (GERONIMO-5896) ContextNotActiveException running JCDI TCK
ContextNotActiveException running JCDI TCK
--
Key: GERONIMO-5896
URL: https://issues.apache.org/jira/browse/GERONIMO-5896
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: OpenWebBeans
Reporter: Kevan Miller
Fix For: 3.0
Running the JCDI tck can result in some exceptions like the following:
{code}
2011-04-09 23:53:45,964 ERROR [ApplicationContextTest]] Exception sending
context initialized event to listener instance of class
org.jboss.jsr299.tck.test\
s.context.application.TestServletContextListener
javax.enterprise.context.ContextNotActiveException: WebBeans context with scope
type annotation @ApplicationScoped does not exist within current thread
at
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:341)
at
org.apache.webbeans.container.InjectableBeanManager.getContext(InjectableBeanManager.java:115)
at
org.jboss.jsr299.tck.tests.context.application.TestServletContextListener.contextInitialized(TestServletContextListener.java:38)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4521)
at
org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5004)
at
org.apache.catalina.core.StandardContext$1.call(StandardContext.java:4999)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
2011-04-09 23:53:45,965 ERROR [StandardContext] Error listenerStart
{code}
This is because the OpenWebBeans application initialization is not being
driven. Geronimo's WebBeansConfigurationListener
(plugins/openwebbeans/geronimo-openwebbeans/src/main/java/org/apache/geronimo/openwebbeans/WebBeansConfigurationListener.java)
is (has become?) somewhat different from OpenWebBeans
WebBeansConfigurationListener). Namely, in
contextInitialized(ServletConextEvent) we don't have:
{code}
this.lifeCycle.startApplication(event);
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5894) deploy, undeploy, deploy of an app using hot-deploy directory fails on the second deploy
deploy, undeploy, deploy of an app using hot-deploy directory fails on the second deploy Key: GERONIMO-5894 URL: https://issues.apache.org/jira/browse/GERONIMO-5894 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Hot Deploy Dir Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 If you copy an app into deploy directory, delete it, and copy it back in, you're likely to get an error like: 2011-04-08 12:37:01,157 ERROR [DirectoryMonitor] Error during hot deployment java.lang.NullPointerException at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:59) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51) at org.apache.geronimo.deployment.hot.DirectoryMonitor.doRemoves(DirectoryMonitor.java:183) at org.apache.geronimo.deployment.hot.DirectoryMonitor.scanDirectory(DirectoryMonitor.java:258) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:219) at java.lang.Thread.run(Thread.java:680) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-5891) support application delete in hot-deploy when server is stopped
[ https://issues.apache.org/jira/browse/GERONIMO-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017538#comment-13017538 ] Kevan Miller commented on GERONIMO-5891: Fixed in branches/2.2 and trunk. There's a hot-deploy bug, but is separate from these changes. Will create a new Jira... > support application delete in hot-deploy when server is stopped > --- > > Key: GERONIMO-5891 > URL: https://issues.apache.org/jira/browse/GERONIMO-5891 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Hot Deploy Dir >Affects Versions: 2.2.1, 3.0 >Reporter: Kevan Miller >Priority: Minor > Fix For: 2.2.2, 3.0 > > > Somebody was complaining to me about hot deploy behavior... If server is > stopped and an application is deleted or updated, we'll never notice. Didn't > seem to hard to save hot-deploy state and read during start-up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (GERONIMO-5891) support application delete in hot-deploy when server is stopped
[ https://issues.apache.org/jira/browse/GERONIMO-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-5891. -- Resolution: Fixed > support application delete in hot-deploy when server is stopped > --- > > Key: GERONIMO-5891 > URL: https://issues.apache.org/jira/browse/GERONIMO-5891 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Hot Deploy Dir >Affects Versions: 2.2.1, 3.0 >Reporter: Kevan Miller >Assignee: Kevan Miller >Priority: Minor > Fix For: 2.2.2, 3.0 > > > Somebody was complaining to me about hot deploy behavior... If server is > stopped and an application is deleted or updated, we'll never notice. Didn't > seem to hard to save hot-deploy state and read during start-up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-5891) support application delete in hot-deploy when server is stopped
[ https://issues.apache.org/jira/browse/GERONIMO-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-5891: -- Assignee: Kevan Miller > support application delete in hot-deploy when server is stopped > --- > > Key: GERONIMO-5891 > URL: https://issues.apache.org/jira/browse/GERONIMO-5891 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Hot Deploy Dir >Affects Versions: 2.2.1, 3.0 >Reporter: Kevan Miller >Assignee: Kevan Miller >Priority: Minor > Fix For: 2.2.2, 3.0 > > > Somebody was complaining to me about hot deploy behavior... If server is > stopped and an application is deleted or updated, we'll never notice. Didn't > seem to hard to save hot-deploy state and read during start-up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5891) support application delete in hot-deploy when server is stopped
support application delete in hot-deploy when server is stopped --- Key: GERONIMO-5891 URL: https://issues.apache.org/jira/browse/GERONIMO-5891 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Hot Deploy Dir Affects Versions: 2.2.1, 3.0 Reporter: Kevan Miller Priority: Minor Fix For: 2.2.2, 3.0 Somebody was complaining to me about hot deploy behavior... If server is stopped and an application is deleted or updated, we'll never notice. Didn't seem to hard to save hot-deploy state and read during start-up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-5873) starttls.required is not supported by JavaMail
starttls.required is not supported by JavaMail -- Key: GERONIMO-5873 URL: https://issues.apache.org/jira/browse/GERONIMO-5873 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: mail Affects Versions: 2.2.1, 2.1.7, 3.0-M2, 3.0 Reporter: Kevan Miller starttls.required is not currently supported by our javamail implementation, but it looks like it should be. if starttls.enable is set to true, then we will require that the server support TLS. This appears to be incorrect. We should only require TLS, if starttls.required=true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-5864) ServletContext.log doesn't log
ServletContext.log doesn't log -- Key: GERONIMO-5864 URL: https://issues.apache.org/jira/browse/GERONIMO-5864 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 ServletContext.log() calls aren't logged anywhere (as far as i can tell). This is on a tomcat server. I didn't test a jetty assembly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-5837) NPE during second deploy using hot-deploy directory
[
https://issues.apache.org/jira/browse/GERONIMO-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller closed GERONIMO-5837.
--
Resolution: Duplicate
Oops. Not up to date reading recent Jiras... Duplicate of GERONIMO-5832
> NPE during second deploy using hot-deploy directory
>
>
> Key: GERONIMO-5837
> URL: https://issues.apache.org/jira/browse/GERONIMO-5837
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 3.0-M2
>Reporter: Kevan Miller
> Fix For: 3.0-M2
>
>
> I deployed an application, verified the application was deployed, undeployed
> the application, verified the application was undeployed, then attempted a
> second deploy of the application using the hot-deploy (i.e. 'deploy')
> directory. I got the following error on the server:
> {code}
> 2011-02-28 10:54:17,062 ERROR [DirectoryMonitor] Error during hot deployment
> java.lang.NullPointerException
> at
> org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:59)
> at
> org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.doRemoves(DirectoryMonitor.java:183)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.scanDirectory(DirectoryMonitor.java:258)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:219)
> at java.lang.Thread.run(Thread.java:680)
> {code}
> The mechanism of the initial deployment doesn't seem to matter (deploy
> command or hot-deploy).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-5837) NPE during second deploy using hot-deploy directory
[
https://issues.apache.org/jira/browse/GERONIMO-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller updated GERONIMO-5837:
---
Affects Version/s: 3.0-M2
Fix Version/s: 3.0-M2
> NPE during second deploy using hot-deploy directory
>
>
> Key: GERONIMO-5837
> URL: https://issues.apache.org/jira/browse/GERONIMO-5837
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 3.0-M2
>Reporter: Kevan Miller
> Fix For: 3.0-M2
>
>
> I deployed an application, verified the application was deployed, undeployed
> the application, verified the application was undeployed, then attempted a
> second deploy of the application using the hot-deploy (i.e. 'deploy')
> directory. I got the following error on the server:
> {code}
> 2011-02-28 10:54:17,062 ERROR [DirectoryMonitor] Error during hot deployment
> java.lang.NullPointerException
> at
> org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:59)
> at
> org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.doRemoves(DirectoryMonitor.java:183)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.scanDirectory(DirectoryMonitor.java:258)
> at
> org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:219)
> at java.lang.Thread.run(Thread.java:680)
> {code}
> The mechanism of the initial deployment doesn't seem to matter (deploy
> command or hot-deploy).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-5837) NPE during second deploy using hot-deploy directory
NPE during second deploy using hot-deploy directory
Key: GERONIMO-5837
URL: https://issues.apache.org/jira/browse/GERONIMO-5837
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Kevan Miller
I deployed an application, verified the application was deployed, undeployed
the application, verified the application was undeployed, then attempted a
second deploy of the application using the hot-deploy (i.e. 'deploy')
directory. I got the following error on the server:
{code}
2011-02-28 10:54:17,062 ERROR [DirectoryMonitor] Error during hot deployment
java.lang.NullPointerException
at
org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:59)
at
org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:51)
at
org.apache.geronimo.deployment.hot.DirectoryMonitor.doRemoves(DirectoryMonitor.java:183)
at
org.apache.geronimo.deployment.hot.DirectoryMonitor.scanDirectory(DirectoryMonitor.java:258)
at
org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:219)
at java.lang.Thread.run(Thread.java:680)
{code}
The mechanism of the initial deployment doesn't seem to matter (deploy command
or hot-deploy).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
