osgi/jndi problem
I cleaned up a bunch of dependency problems and am getting the build further. I now have 3 plugins starting quickly on the first try and have fixed a class visibility problem in the JMXConnector. However, I'm now seeing this exception (if I debug in the right place) trying to start the JMXConnector gbean which tries to use jndi... java.lang.NullPointerException at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration $1.run(VersionHelper12.java:197) at java.security.AccessController.doPrivileged(Native Method) at com .sun .naming .internal .VersionHelper12 $InputStreamEnumeration.getNextElement(VersionHelper12.java:194) at com .sun .naming .internal .VersionHelper12$InputStreamEnumeration.hasMore(VersionHelper12.java: 214) at com .sun .naming .internal.ResourceManager.getApplicationResources(ResourceManager.java: 470) at com .sun .naming .internal.ResourceManager.getInitialEnvironment(ResourceManager.java: 159) at javax.naming.InitialContext.init(InitialContext.java:219) at javax.naming.InitialContext.init(InitialContext.java:197) at javax .management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java: 619) at javax .management .remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412) at org.apache.geronimo.jmxremoting.JMXConnector.doStart(JMXConnector.java: 206) at org .apache .geronimo .gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:953) 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.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at org .apache .geronimo .gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:542) at org .apache .geronimo .kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:385) at org .apache .geronimo .kernel .config .ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:459) at org .apache .geronimo .kernel .config .KernelConfigurationManager.start(KernelConfigurationManager.java:223) at org .apache .geronimo .kernel .config .SimpleConfigurationManager .startConfiguration(SimpleConfigurationManager.java:713) at org.apache.geronimo.system.osgi.BootActivator.start(BootActivator.java: 126) at org .apache .felix.framework.util.SecureAction.startActivator(SecureAction.java:667) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1699) at org.apache.felix.framework.Felix.startBundle(Felix.java:1621) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java: 1076) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java: 264) at java.lang.Thread.run(Thread.java:637) Anyone have a clue what might be wrong? thanks david jencks
[jira] Commented: (GERONIMO-4906) DB connection problem
[ https://issues.apache.org/jira/browse/GERONIMO-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765942#action_12765942 ] Jean-Jacques Parent commented on GERONIMO-4906: --- Is there a way to get trace from the jdbc ? Is it possible to manage the connections from the pool, to see if one is in a wrong state and eventually to kill it? See some similar post on http://www.nabble.com/Bad-JDBC-Connection-with-Oracle-td18079875s134.html DB connection problem - Key: GERONIMO-4906 URL: https://issues.apache.org/jira/browse/GERONIMO-4906 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0.1 Environment: Geronimo running on Windows server 2003 (Virtual Machine) Oracle 10g Driver jdbc 10.2.0.1 Spring-Version: 2.0.2 Hibernate-Version: 3.2.0.cr4 Reporter: Jean-Jacques Parent Attachments: config.xml, Errors_samples.txt Your expertise on my problem will be helpful. Once a week, I get a DB connectivity problem with my application. No new DB transaction can be open. After a few minutes, the situation can come back as normal, if not the Geronimo server has to be restarted. I ask our technicians about connectivity and performance, but they found nothing wrong. I give you the stack trace in attachment with the different kind of error message. You will see that it looks like a network problem, but maybe this could also be due to a jdbc, timeout...? My pool configuration is as follow Pool Min Size:25 The minimum number of connections in the pool. The default is 0. Pool Max Size:140 The maximum number of connections in the pool. The default is 10. Blocking Timeout: 5000 (in milliseconds) The length of time a caller will wait for a connection. The default is 5000. Idle Timeout: 5(in minutes) How long a connection can be idle before being closed. The default is 15. Any help will be appreciate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 825414
Geronimo Revision: 825414 built with tests included
See the full build-0300.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091015/build-0300.log
See the unit test reports at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091015/unit-test-reports
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor]
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] [install:install]
[INFO] Installing /home/geronimo/geronimo/trunk/plugins/openjpa2/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/plugins/openjpa2/3.0-SNAPSHOT/openjpa2-3.0-SNAPSHOT.pom
[INFO]
[INFO] Building Geronimo Plugins, OpenJPA2 :: Persistence 2.0
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] snapshot org.apache.openjpa:openjpa:2.0.0-SNAPSHOT: checking for updates
from codehaus.snapshots
[INFO] snapshot org.apache.openjpa:openjpa:2.0.0-SNAPSHOT: checking for updates
from apache.snapshots
Downloading:
http://repository.apache.org/snapshots/org/apache/openjpa/openjpa/2.0.0-SNAPSHOT/openjpa-2.0.0-SNAPSHOT.pom
11K downloaded
[INFO] snapshot org.apache.openjpa:openjpa-parent:2.0.0-SNAPSHOT: checking for
updates from codehaus.snapshots
[INFO] snapshot org.apache.openjpa:openjpa-parent:2.0.0-SNAPSHOT: checking for
updates from apache.snapshots
Downloading:
http://repository.apache.org/snapshots/org/apache/openjpa/openjpa-parent/2.0.0-SNAPSHOT/openjpa-parent-2.0.0-SNAPSHOT.pom
38K downloaded
Downloading:
http://repo.exist.com/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.pom
4K downloaded
Downloading:
http://repository.apache.org/snapshots/org/apache/openjpa/openjpa/2.0.0-SNAPSHOT/openjpa-2.0.0-SNAPSHOT.jar
3825K downloaded
Downloading:
http://repo.exist.com/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
185K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/main/resources
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/main/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:compile]
[INFO] Compiling 10 source files to
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/classes
[INFO] [resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/resources
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/test-classes
[WARNING]
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/java/org/apache/geronimo/persistence/PersistenceUnitGBeanTest.java:[51,41]
[deprecation] toURL() in java.io.File has been deprecated
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.persistence.CMPEntityManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.107 sec
Running org.apache.geronimo.persistence.PersistenceUnitGBeanTest
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.166 sec
FAILURE!
Results :
Tests in error:
testNonNullJavaFileUrls(org.apache.geronimo.persistence.PersistenceUnitGBeanTest)
Tests run: 11, Failures: 0, Errors: 1, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There are test failures.
Please refer to
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/surefire-reports
for the individual test results.
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: There are test failures.
Please refer to
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/surefire-reports
for the individual test results.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:580
[jira] Created: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
GBeanInstance to Ignore Missing Setters --- Key: GERONIMO-4907 URL: https://issues.apache.org/jira/browse/GERONIMO-4907 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: kernel Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Reporter: Quintin Beukes Fix For: 2.2, 3.0 Related to GERONIMO-4903 I submitted a patch which fixes the problem by removing the attributes which don't have setters. After reading the OpenEJB source I noticed an XBean feature which would be a more correct fix for the problem. Instead of removing the attributes which won't have setters in the class being instantiated as a GBean, configure the ObjectRecipe to rather ignore those properties which don't have setters. This has 2 benefits 1) Those properties can still be included for read access 2) If such a property exists for any other GBean, or is added in the future, this will help that those don't possibly create fatal bugs - which the JettyConnector bug almost was (you couldn't edit a connector - ever). This is achieved by adding the following line after the ObjectRecipe was created: objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); This permissions merely removes the property from the list of properties to create the object with, if the accessor wasn't found. Since those properties are still available, they can be accessed by the GBean API, and thus it doesn't become a requirement to have setter accessors for all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Quintin Beukes updated GERONIMO-4907: - Attachment: ignore-missing-accessors.patch Attached patch to add the IGNORE_MISSING_ACCESSOR option to the ObjectRecipe. GBeanInstance to Ignore Missing Setters --- Key: GERONIMO-4907 URL: https://issues.apache.org/jira/browse/GERONIMO-4907 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Reporter: Quintin Beukes Fix For: 2.2, 3.0 Attachments: ignore-missing-accessors.patch Related to GERONIMO-4903 I submitted a patch which fixes the problem by removing the attributes which don't have setters. After reading the OpenEJB source I noticed an XBean feature which would be a more correct fix for the problem. Instead of removing the attributes which won't have setters in the class being instantiated as a GBean, configure the ObjectRecipe to rather ignore those properties which don't have setters. This has 2 benefits 1) Those properties can still be included for read access 2) If such a property exists for any other GBean, or is added in the future, this will help that those don't possibly create fatal bugs - which the JettyConnector bug almost was (you couldn't edit a connector - ever). This is achieved by adding the following line after the ObjectRecipe was created: objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); This permissions merely removes the property from the list of properties to create the object with, if the accessor wasn't found. Since those properties are still available, they can be accessed by the GBean API, and thus it doesn't become a requirement to have setter accessors for all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4907) GBeanInstance to Ignore Missing Setters
[ https://issues.apache.org/jira/browse/GERONIMO-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765962#action_12765962 ] Quintin Beukes commented on GERONIMO-4907: -- If this is applied, GERONIMO-4903 could possibly be reversed. GBeanInstance to Ignore Missing Setters --- Key: GERONIMO-4907 URL: https://issues.apache.org/jira/browse/GERONIMO-4907 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0 Reporter: Quintin Beukes Fix For: 2.2, 3.0 Attachments: ignore-missing-accessors.patch Related to GERONIMO-4903 I submitted a patch which fixes the problem by removing the attributes which don't have setters. After reading the OpenEJB source I noticed an XBean feature which would be a more correct fix for the problem. Instead of removing the attributes which won't have setters in the class being instantiated as a GBean, configure the ObjectRecipe to rather ignore those properties which don't have setters. This has 2 benefits 1) Those properties can still be included for read access 2) If such a property exists for any other GBean, or is added in the future, this will help that those don't possibly create fatal bugs - which the JettyConnector bug almost was (you couldn't edit a connector - ever). This is achieved by adding the following line after the ObjectRecipe was created: objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES); This permissions merely removes the property from the list of properties to create the object with, if the accessor wasn't found. Since those properties are still available, they can be accessed by the GBean API, and thus it doesn't become a requirement to have setter accessors for all persistent properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4903) Jetty Advanced Integration Test Failure
[
https://issues.apache.org/jira/browse/GERONIMO-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765961#action_12765961
]
Quintin Beukes commented on GERONIMO-4903:
--
If GERONIMO-4907 is applied, it could become an option to revert revision
#824389 and #824390.
Jetty Advanced Integration Test Failure
---
Key: GERONIMO-4903
URL: https://issues.apache.org/jira/browse/GERONIMO-4903
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: connector
Affects Versions: 2.2
Reporter: Quintin Beukes
Assignee: Donald Woods
Fix For: 2.2, 3.0
Attachments: jetty-advanced-test-failure.patch
Hey,
I found the cause of the test failure.
In the file: {src
root}/plugins/jetty7/geronimo-jetty7/./src/main/java/org/apache/geronimo/jetty7/connector/JettyConnector.java
Line: 289
It reads: new String[]{host, port, minThreads, maxThreads,
bufferSizeBytes, headerBufferSizeBytes, acceptQueueSize,
lingerMillis, protocol, redirectPort, connectUrl,
maxIdleTimeMs},
Change to: new String[]{host, port, minThreads, maxThreads,
bufferSizeBytes, headerBufferSizeBytes, acceptQueueSize,
lingerMillis, redirectPort, maxIdleTimeMs},
Basically removing the protocol and connectUrl attributes from the
persistent interface attributes fixes the problem.
protocol is static for Jetty BIO connector, so it doesn't need to be
saved, or can't be specified.
connectUrl is generated on the fly through getConnectUrl(), so can't
be saved either.
So unless my understanding of what persistentAttributes are is
incorrect, this seems to be the correct solution? Please correct me if
I'm wrong.
What caused the problem is that the JettyConnector class doesn't have
a setter for these attributes, so when XBean searches all the
specified attributes' setters, it fails when it can't find these. This
caused the test to fail, because the connector doesn't start again
after being edited (enters the failed state).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4906) DB connection problem
[ https://issues.apache.org/jira/browse/GERONIMO-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765973#action_12765973 ] Quintin Beukes commented on GERONIMO-4906: -- I remember dealing with a similar problem once. I've been trying to think which pool manager this was, but am unable. Though I do remember how it was solved. It was an an option (possible 2 separate once - not sure) which routinely tested the actual connection, and if closed would remove it from the pool. Also, before the connection is given to a requesting client it would also be tested to ensure it's active, if not it would be removed and another connection tried - until one could be found. If none could be found an exception is raised. Maybe such an option is available? And if not, I definitely recommend it be added. If this isn't available yet, the code that requests the connection could perhaps (even temporarily) wrap the request in a method which has the above behavior (testing the connection and requesting a new one if the test fails). The pool should automatically remove it when an exception is raised, so I don't think this wrapper needs to worry about that. DB connection problem - Key: GERONIMO-4906 URL: https://issues.apache.org/jira/browse/GERONIMO-4906 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0.1 Environment: Geronimo running on Windows server 2003 (Virtual Machine) Oracle 10g Driver jdbc 10.2.0.1 Spring-Version: 2.0.2 Hibernate-Version: 3.2.0.cr4 Reporter: Jean-Jacques Parent Attachments: config.xml, Errors_samples.txt Your expertise on my problem will be helpful. Once a week, I get a DB connectivity problem with my application. No new DB transaction can be open. After a few minutes, the situation can come back as normal, if not the Geronimo server has to be restarted. I ask our technicians about connectivity and performance, but they found nothing wrong. I give you the stack trace in attachment with the different kind of error message. You will see that it looks like a network problem, but maybe this could also be due to a jdbc, timeout...? My pool configuration is as follow Pool Min Size:25 The minimum number of connections in the pool. The default is 0. Pool Max Size:140 The maximum number of connections in the pool. The default is 10. Blocking Timeout: 5000 (in milliseconds) The length of time a caller will wait for a connection. The default is 5000. Idle Timeout: 5(in minutes) How long a connection can be idle before being closed. The default is 15. Any help will be appreciate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4906) DB connection problem
[ https://issues.apache.org/jira/browse/GERONIMO-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765975#action_12765975 ] Quintin Beukes commented on GERONIMO-4906: -- I remember now that I was using c3p0 with Hibernate. These were the options I was referring to: http://www.mchange.com/projects/c3p0/index.html#configuring_connection_testing DB connection problem - Key: GERONIMO-4906 URL: https://issues.apache.org/jira/browse/GERONIMO-4906 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0.1 Environment: Geronimo running on Windows server 2003 (Virtual Machine) Oracle 10g Driver jdbc 10.2.0.1 Spring-Version: 2.0.2 Hibernate-Version: 3.2.0.cr4 Reporter: Jean-Jacques Parent Attachments: config.xml, Errors_samples.txt Your expertise on my problem will be helpful. Once a week, I get a DB connectivity problem with my application. No new DB transaction can be open. After a few minutes, the situation can come back as normal, if not the Geronimo server has to be restarted. I ask our technicians about connectivity and performance, but they found nothing wrong. I give you the stack trace in attachment with the different kind of error message. You will see that it looks like a network problem, but maybe this could also be due to a jdbc, timeout...? My pool configuration is as follow Pool Min Size:25 The minimum number of connections in the pool. The default is 0. Pool Max Size:140 The maximum number of connections in the pool. The default is 10. Blocking Timeout: 5000 (in milliseconds) The length of time a caller will wait for a connection. The default is 5000. Idle Timeout: 5(in minutes) How long a connection can be idle before being closed. The default is 15. Any help will be appreciate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: More OSGi progress
I just built dj's sandbox framework successfully, here is my footprint. Hope
this helps for the following guys, and also thanks for the clues above!
my env:
windowxp
maven2.2.1
jdk6
sandbox rev825381
checkout sandbox ramework
ps: modify pom.xml(xmlbeans denp: 2.4.0_2-SNAPSHOT - 2.4.0_3-SNAPSHOT)
checkout servicemix
ps:
add djencks patch to xstream-1.3/pom.xml
build root pom.xml
build: jaxb-impl-2.1.6, xmlbeans-2.4.0, woodstox-3.2.8, jline-0.9.94
copy the G-trunk root pom.xml to the parent dir of this sandbox frameowrk
build geronimo bundles
ps: plexus-utils pom.xml (version-1.4.5_1-SNAPSHOT ), build it before
plexus achiver and logging
checkout karaf from felix trunk and bunld it
checkout org.osgi.core/foundation/compendium and build them sequentially.
then, build the sandbox framework.
HTH.
-Rex
2009/10/13 Rick McGuire rick...@gmail.com
Time to start a new thread, I think. I'm getting further now. The
framework builds, but I'm getting errors trying to build the configs. I get
an IOException attempting to build the J2EE System config (see below). The
file in question is
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
which actually does exist. Strangely, this does not kill the build, but it
then dies trying to build the rmi-naming config with a similar error trying
to load the rmi-naming car file. This one does kill the build. Both
exceptions occur when starting the Felix framework, but I'm not sure where
the reference to that file is coming from. Any suggestions on where I might
start debugging this problem?
Rick
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Framework, Configs :: J2EE System
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
C:\jencks\g\framework\configs\j2ee-sy
stem\src\main\filtered-resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
C:\jencks\g\framework\configs\j2ee-system\target\work\plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\jencks\g\framework\configs\j2ee-system
\target\work\plan.xml
ERROR: Error creating archive. (java.io.IOException: Referenced file does
not ex
ist:
C:\jencks\g\framework\configs\j2ee-system\target\repository\org\apache\gero
nimo\framework\j2ee-system\3.0-SNAPSHOT\j2ee-system-3.0-SNAPSHOT.car)
java.io.IOException: Referenced file does not exist:
C:\jencks\g\framework\confi
gs\j2ee-system\target\repository\org\apache\geronimo\framework\j2ee-system\3.0-S
NAPSHOT\j2ee-system-3.0-SNAPSHOT.car
at
org.apache.felix.framework.cache.BundleArchive.createRevisionFromLoca
tion(BundleArchive.java:994)
at
org.apache.felix.framework.cache.BundleArchive.revise(BundleArchive.j
ava:631)
at
org.apache.felix.framework.cache.BundleArchive.init(BundleArchive.j
ava:206)
at
org.apache.felix.framework.cache.BundleCache.getArchives(BundleCache.
java:149)
at org.apache.felix.framework.Felix.init(Felix.java:558)
at org.apache.felix.framework.Felix.start(Felix.java:683)
at
org.apache.geronimo.mavenplugins.car.AbstractCarMojo.getFramework(Abs
tractCarMojo.java:771)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.createKernel(Package
Mojo.java:360)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(Package
Mojo.java:294)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.
java:234)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:453)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:500)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:142)
at
[BUILD] trunk: Failed for Revision: 825486
Geronimo Revision: 825486 built with tests included See the full build-0900.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091015/build-0900.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091015/unit-test-reports [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [INFO] [compiler:testCompile] [INFO] Compiling 4 source files to /home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/test-classes [WARNING] /home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/java/org/apache/geronimo/persistence/PersistenceUnitGBeanTest.java:[51,41] [deprecation] toURL() in java.io.File has been deprecated [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@58145814 [WARNING] Component returned which is not the same manager. Ignored. component
GEP 2.2
Building the current 2.2 version of the trunk I'm constantly getting the
following error:
[INFO]
[INFO] Building Geronimo Eclipse Plugin :: Testsuite :: Launcher
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file-set: /srv/project/autobuild/gep/trunk/testsuite/launcher
(included: [launcher/.metadata, launcher/eclipse, launcher/results,
launcher/server_v2.2, launcher/server_v2.1, launcher/server_v2.0,
launcher/workspace], excluded: [])
[INFO] [buildnumber:create {execution: default}]
[INFO] Storing buildNumber: 20091015161556 at timestamp: 1255616156287
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing /srv/project/autobuild/gep/trunk/testsuite/launcher/pom.xml
to
/srv/downloads/maven/org/apache/geronimo/devtools/testsuite-launcher/2.2.0/testsuite-launcher-2.2.0.pom
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:test' is invalid. It will
be ignored for artifact resolution. Reason: Not a v4.0.0 POM. for project
org.jvnet.staxex:stax-ex at
/srv/downloads/maven/org/jvnet/staxex/stax-ex/1.0/stax-ex-1.0.pom
[INFO] [antrun:run {execution: run-testsuite}]
[INFO] Executing tasks
Is there any resolution for that issue?
Best regards,
Johannes
Re: osgi/jndi problem
I just committed a fix for this problem. The Bundle.getResources() is allowed to return null but ClassLoader.getResources() is not. So I updated the BundleClassLoader.java to return an empty enumeration if Bundle.getResources() returns null. Now I'm getting: Module 4/5 org.apache.geronimo.framework/j2ee-security/3.0-SNAPSHOT/car ERROR: Error starting mvn:org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car (org.osgi.framework.BundleException: Activator start error in bundle org.apache.geronimo.framework.j2ee-system [49].) java.lang.NoClassDefFoundError: org.apache.geronimo.kernel.rmi.RMIClassLoaderSpiImpl at java.rmi.server.RMIClassLoader.initializeProvider(RMIClassLoader.java:668) at java.rmi.server.RMIClassLoader.access$000(RMIClassLoader.java:93) at java.rmi.server.RMIClassLoader$1.run(RMIClassLoader.java:103) at java.security.AccessController.doPrivileged(Native Method) at java.rmi.server.RMIClassLoader.clinit(RMIClassLoader.java:100) at sun.rmi.server.MarshalOutputStream.annotateClass(MarshalOutputStream.java:75) at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1250) at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1203) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source) at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:120) at com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:208) at javax.naming.InitialContext.bind(InitialContext.java:400) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:625) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412) at org.apache.geronimo.jmxremoting.JMXConnector.doStart(JMXConnector.java:207) Jarek On Thu, Oct 15, 2009 at 3:05 AM, David Jencks david_jen...@yahoo.com wrote: I cleaned up a bunch of dependency problems and am getting the build further. I now have 3 plugins starting quickly on the first try and have fixed a class visibility problem in the JMXConnector. However, I'm now seeing this exception (if I debug in the right place) trying to start the JMXConnector gbean which tries to use jndi... java.lang.NullPointerException at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration$1.run(VersionHelper12.java:197) at java.security.AccessController.doPrivileged(Native Method) at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.getNextElement(VersionHelper12.java:194) at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.hasMore(VersionHelper12.java:214) at com.sun.naming.internal.ResourceManager.getApplicationResources(ResourceManager.java:470) at com.sun.naming.internal.ResourceManager.getInitialEnvironment(ResourceManager.java:159) at javax.naming.InitialContext.init(InitialContext.java:219) at javax.naming.InitialContext.init(InitialContext.java:197) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:619) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412) at org.apache.geronimo.jmxremoting.JMXConnector.doStart(JMXConnector.java:206) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:953) 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.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:542) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:385) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:459) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:223) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:713) at org.apache.geronimo.system.osgi.BootActivator.start(BootActivator.java:126) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:667) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1699) at org.apache.felix.framework.Felix.startBundle(Felix.java:1621) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1076) at
[jira] Created: (GERONIMO-4908) RMIClassLoader is not compatible with osgi
RMIClassLoader is not compatible with osgi -- Key: GERONIMO-4908 URL: https://issues.apache.org/jira/browse/GERONIMO-4908 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: osgi Affects Versions: 3.0 Reporter: David Jencks We have RMIClassLoaderSpiImpl in geronimo-kernel. However, RMIClassLoader loads the spi impl using the system classloader. (http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html) So we'd have to get our impl into the system classloader unless osgi provides an additional level of delegation in the system classloader. For now I'm going to try not setting java.rmi.server.RMIClassLoaderSpi in RMIRegistryService -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: osgi/jndi problem
Ah, the RMIClassLoaderSpiImpl needs to be on the system classloader. I created a tiny jar file with the RMIClassLoader* classes and put it in ./target/assembly/lib directory and started the server: Module 1/5 org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car started in .000s Module 2/5 org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car started in .260s Module 3/5 org.apache.geronimo.framework/plugin/3.0-SNAPSHOT/car started in .169s Module 4/5 org.apache.geronimo.framework/j2ee-security/3.0-SNAPSHOT/car started in .471s Module 5/5 org.apache.geronimo.framework/server-security-config/3.0-SNAPSHOT/car started in .070s Startup completed in 5.158s seconds Listening on Ports: 1099 0.0.0.0 RMI Naming 0.0.0.0 JMX Remoting Connector Geronimo Application Server started Jarek On Thu, Oct 15, 2009 at 11:53 AM, Jarek Gawor jga...@gmail.com wrote: I just committed a fix for this problem. The Bundle.getResources() is allowed to return null but ClassLoader.getResources() is not. So I updated the BundleClassLoader.java to return an empty enumeration if Bundle.getResources() returns null. Now I'm getting: Module 4/5 org.apache.geronimo.framework/j2ee-security/3.0-SNAPSHOT/car ERROR: Error starting mvn:org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car (org.osgi.framework.BundleException: Activator start error in bundle org.apache.geronimo.framework.j2ee-system [49].) java.lang.NoClassDefFoundError: org.apache.geronimo.kernel.rmi.RMIClassLoaderSpiImpl at java.rmi.server.RMIClassLoader.initializeProvider(RMIClassLoader.java:668) at java.rmi.server.RMIClassLoader.access$000(RMIClassLoader.java:93) at java.rmi.server.RMIClassLoader$1.run(RMIClassLoader.java:103) at java.security.AccessController.doPrivileged(Native Method) at java.rmi.server.RMIClassLoader.clinit(RMIClassLoader.java:100) at sun.rmi.server.MarshalOutputStream.annotateClass(MarshalOutputStream.java:75) at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1250) at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1203) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source) at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:120) at com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:208) at javax.naming.InitialContext.bind(InitialContext.java:400) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:625) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412) at org.apache.geronimo.jmxremoting.JMXConnector.doStart(JMXConnector.java:207) Jarek On Thu, Oct 15, 2009 at 3:05 AM, David Jencks david_jen...@yahoo.com wrote: I cleaned up a bunch of dependency problems and am getting the build further. I now have 3 plugins starting quickly on the first try and have fixed a class visibility problem in the JMXConnector. However, I'm now seeing this exception (if I debug in the right place) trying to start the JMXConnector gbean which tries to use jndi... java.lang.NullPointerException at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration$1.run(VersionHelper12.java:197) at java.security.AccessController.doPrivileged(Native Method) at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.getNextElement(VersionHelper12.java:194) at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.hasMore(VersionHelper12.java:214) at com.sun.naming.internal.ResourceManager.getApplicationResources(ResourceManager.java:470) at com.sun.naming.internal.ResourceManager.getInitialEnvironment(ResourceManager.java:159) at javax.naming.InitialContext.init(InitialContext.java:219) at javax.naming.InitialContext.init(InitialContext.java:197) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:619) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412) at org.apache.geronimo.jmxremoting.JMXConnector.doStart(JMXConnector.java:206) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:953) 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.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125) at
[jira] Commented: (GERONIMO-4908) RMIClassLoader is not compatible with osgi
[ https://issues.apache.org/jira/browse/GERONIMO-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766123#action_12766123 ] David Jencks commented on GERONIMO-4908: RMI and osgi seems to be a major headache, see for example https://mail.osgi.org/pipermail/osgi-dev/2009-January/001639.html RMIClassLoader is not compatible with osgi -- Key: GERONIMO-4908 URL: https://issues.apache.org/jira/browse/GERONIMO-4908 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: osgi Affects Versions: 3.0 Reporter: David Jencks We have RMIClassLoaderSpiImpl in geronimo-kernel. However, RMIClassLoader loads the spi impl using the system classloader. (http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html) So we'd have to get our impl into the system classloader unless osgi provides an additional level of delegation in the system classloader. For now I'm going to try not setting java.rmi.server.RMIClassLoaderSpi in RMIRegistryService -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4909) How should we shut down plugin under osgi?
How should we shut down plugin under osgi? -- Key: GERONIMO-4909 URL: https://issues.apache.org/jira/browse/GERONIMO-4909 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: osgi Affects Versions: 3.0 Reporter: David Jencks ConfigurationActivator needs it's stop method to shut down the plugin. Calling configurationManager.unload(id) is symmetrical with start and should leave the configuration model in a consistent state, but resets the load attribute in config.xml to false, which prevents restarting the server. Just stopping and unloading the configuration gbean works fine but may leave the configuration model (in the configuration manager) in an inconsistent state. This needs further investigation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GEP 2.2
Can you please run and paste svn info from the route of your checkout.
Quintin Beukes
On Thu, Oct 15, 2009 at 4:18 PM, Johannes Weberhofer, Weberhofer GmbH
off...@weberhofer.at wrote:
Building the current 2.2 version of the trunk I'm constantly getting the
following error:
[INFO]
[INFO] Building Geronimo Eclipse Plugin :: Testsuite :: Launcher
[INFO] task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file-set:
/srv/project/autobuild/gep/trunk/testsuite/launcher (included:
[launcher/.metadata, launcher/eclipse, launcher/results,
launcher/server_v2.2, launcher/server_v2.1, launcher/server_v2.0,
launcher/workspace], excluded: [])
[INFO] [buildnumber:create {execution: default}]
[INFO] Storing buildNumber: 20091015161556 at timestamp: 1255616156287
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing
/srv/project/autobuild/gep/trunk/testsuite/launcher/pom.xml to
/srv/downloads/maven/org/apache/geronimo/devtools/testsuite-launcher/2.2.0/testsuite-launcher-2.2.0.pom
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:test' is invalid. It
will be ignored for artifact resolution. Reason: Not a v4.0.0 POM. for
project org.jvnet.staxex:stax-ex at
/srv/downloads/maven/org/jvnet/staxex/stax-ex/1.0/stax-ex-1.0.pom
[INFO] [antrun:run {execution: run-testsuite}]
[INFO] Executing tasks
Is there any resolution for that issue?
Best regards,
Johannes
Re: osgi/jndi problem
I commented out the attempt to use our implementation which also fixes
the problem :-) If you think that using our implementation actually
provides any more functionality than the default implementation could
you merge in your changes and undo my edit to RMIRegistryService?
thanks
david jencks
On Oct 15, 2009, at 9:57 AM, Jarek Gawor wrote:
Ah, the RMIClassLoaderSpiImpl needs to be on the system classloader.
I created a tiny jar file with the RMIClassLoader* classes and put it
in ./target/assembly/lib directory and started the server:
Module 1/5 org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car
started in .000s
Module 2/5 org.apache.geronimo.framework/rmi-naming/3.0-SNAPSHOT/car
started in .260s
Module 3/5 org.apache.geronimo.framework/plugin/3.0-SNAPSHOT/car
started in .169s
Module 4/5 org.apache.geronimo.framework/j2ee-security/3.0-SNAPSHOT/
car
started in .471s
Module 5/5 org.apache.geronimo.framework/server-security-config/3.0-
SNAPSHOT/car
started in .070s
Startup completed in 5.158s seconds
Listening on Ports:
1099 0.0.0.0 RMI Naming
0.0.0.0 JMX Remoting Connector
Geronimo Application Server started
Jarek
On Thu, Oct 15, 2009 at 11:53 AM, Jarek Gawor jga...@gmail.com
wrote:
I just committed a fix for this problem. The Bundle.getResources() is
allowed to return null but ClassLoader.getResources() is not. So I
updated the BundleClassLoader.java to return an empty enumeration if
Bundle.getResources() returns null.
Now I'm getting:
Module 4/5 org.apache.geronimo.framework/j2ee-security/3.0-SNAPSHOT/
car
ERROR: Error starting
mvn:org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car
(org.osgi.framework.BundleException: Activator start error in bundle
org.apache.geronimo.framework.j2ee-system [49].)
java.lang.NoClassDefFoundError:
org.apache.geronimo.kernel.rmi.RMIClassLoaderSpiImpl
at
java
.rmi.server.RMIClassLoader.initializeProvider(RMIClassLoader.java:
668)
at java.rmi.server.RMIClassLoader.access
$000(RMIClassLoader.java:93)
at java.rmi.server.RMIClassLoader$1.run(RMIClassLoader.java:
103)
at java.security.AccessController.doPrivileged(Native Method)
at
java.rmi.server.RMIClassLoader.clinit(RMIClassLoader.java:100)
at
sun
.rmi
.server.MarshalOutputStream.annotateClass(MarshalOutputStream.java:
75)
at
java
.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:
1250)
at
java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:
1203)
at
java
.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:
1387)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:
120)
at
com
.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:
208)
at javax.naming.InitialContext.bind(InitialContext.java:400)
at
javax
.management
.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:625)
at
javax
.management
.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412)
at
org
.apache.geronimo.jmxremoting.JMXConnector.doStart(JMXConnector.java:
207)
Jarek
On Thu, Oct 15, 2009 at 3:05 AM, David Jencks
david_jen...@yahoo.com wrote:
I cleaned up a bunch of dependency problems and am getting the build
further. I now have 3 plugins starting quickly on the first try
and have
fixed a class visibility problem in the JMXConnector. However,
I'm now
seeing this exception (if I debug in the right place) trying to
start the
JMXConnector gbean which tries to use jndi...
java.lang.NullPointerException
at
com.sun.naming.internal.VersionHelper12$InputStreamEnumeration
$1.run(VersionHelper12.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at
com
.sun
.naming
.internal
.VersionHelper12
$InputStreamEnumeration.getNextElement(VersionHelper12.java:194)
at
com
.sun
.naming
.internal
.VersionHelper12
$InputStreamEnumeration.hasMore(VersionHelper12.java:214)
at
com
.sun
.naming
.internal
.ResourceManager.getApplicationResources(ResourceManager.java:470)
at
com
.sun
.naming
.internal
.ResourceManager.getInitialEnvironment(ResourceManager.java:159)
at javax.naming.InitialContext.init(InitialContext.java:219)
at javax.naming.InitialContext.init(InitialContext.java:
197)
at
javax
.management
.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:619)
at
javax
.management
.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412)
at
org
.apache
.geronimo.jmxremoting.JMXConnector.doStart(JMXConnector.java:206)
at
org
.apache
.geronimo
[BUILD] trunk: Failed for Revision: 825617
Geronimo Revision: 825617 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091015/build-1500.log
See the unit test reports at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091015/unit-test-reports
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor]
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] [install:install]
[INFO] Installing /home/geronimo/geronimo/trunk/plugins/openjpa2/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/plugins/openjpa2/3.0-SNAPSHOT/openjpa2-3.0-SNAPSHOT.pom
[INFO]
[INFO] Building Geronimo Plugins, OpenJPA2 :: Persistence 2.0
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] snapshot org.apache.openjpa:openjpa:2.0.0-SNAPSHOT: checking for updates
from codehaus.snapshots
[INFO] snapshot org.apache.openjpa:openjpa:2.0.0-SNAPSHOT: checking for updates
from apache.snapshots
Downloading:
http://repository.apache.org/snapshots/org/apache/openjpa/openjpa/2.0.0-SNAPSHOT/openjpa-2.0.0-SNAPSHOT.pom
11K downloaded
[INFO] snapshot org.apache.openjpa:openjpa-parent:2.0.0-SNAPSHOT: checking for
updates from codehaus.snapshots
[INFO] snapshot org.apache.openjpa:openjpa-parent:2.0.0-SNAPSHOT: checking for
updates from apache.snapshots
Downloading:
http://repository.apache.org/snapshots/org/apache/openjpa/openjpa-parent/2.0.0-SNAPSHOT/openjpa-parent-2.0.0-SNAPSHOT.pom
38K downloaded
Downloading:
http://repo.exist.com/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.pom
4K downloaded
Downloading:
http://repository.apache.org/snapshots/org/apache/openjpa/openjpa/2.0.0-SNAPSHOT/openjpa-2.0.0-SNAPSHOT.jar
3825K downloaded
Downloading:
http://repo.exist.com/maven2/net/sourceforge/serp/serp/1.11.0/serp-1.11.0.jar
185K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/main/resources
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/main/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:compile]
[INFO] Compiling 10 source files to
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/classes
[INFO] [resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/resources
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/test-classes
[WARNING]
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/src/test/java/org/apache/geronimo/persistence/PersistenceUnitGBeanTest.java:[51,41]
[deprecation] toURL() in java.io.File has been deprecated
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/surefire-reports
---
T E S T S
---
Running org.apache.geronimo.persistence.CMPEntityManagerTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.123 sec
Running org.apache.geronimo.persistence.PersistenceUnitGBeanTest
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.167 sec
FAILURE!
Results :
Tests in error:
testNonNullJavaFileUrls(org.apache.geronimo.persistence.PersistenceUnitGBeanTest)
Tests run: 11, Failures: 0, Errors: 1, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There are test failures.
Please refer to
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/surefire-reports
for the individual test results.
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: There are test failures.
Please refer to
/home/geronimo/geronimo/trunk/plugins/openjpa2/geronimo-persistence-jpa20/target/surefire-reports
for the individual test results.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:580
Re: GEP 2.2
It's
Path: .
URL: http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/trunk
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 825495
Node Kind: directory
Schedule: normal
Last Changed Author: delos
Last Changed Rev: 824225
Last Changed Date: 2009-10-12 06:59:59 +0200 (Mon, 12 Oct 2009)
Hope, it helps!
Johannes
Am 15.10.2009 21:16, schrieb Quintin Beukes:
Can you please run and paste svn info from the route of your checkout.
Quintin Beukes
On Thu, Oct 15, 2009 at 4:18 PM, Johannes Weberhofer, Weberhofer GmbH
off...@weberhofer.at wrote:
Building the current 2.2 version of the trunk I'm constantly getting the
following error:
[INFO]
[INFO] Building Geronimo Eclipse Plugin :: Testsuite :: Launcher
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file-set:
/srv/project/autobuild/gep/trunk/testsuite/launcher (included:
[launcher/.metadata, launcher/eclipse, launcher/results,
launcher/server_v2.2, launcher/server_v2.1, launcher/server_v2.0,
launcher/workspace], excluded: [])
[INFO] [buildnumber:create {execution: default}]
[INFO] Storing buildNumber: 20091015161556 at timestamp: 1255616156287
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing
/srv/project/autobuild/gep/trunk/testsuite/launcher/pom.xml to
/srv/downloads/maven/org/apache/geronimo/devtools/testsuite-launcher/2.2.0/testsuite-launcher-2.2.0.pom
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:test' is invalid. It
will be ignored for artifact resolution. Reason: Not a v4.0.0 POM. for
project org.jvnet.staxex:stax-ex at
/srv/downloads/maven/org/jvnet/staxex/stax-ex/1.0/stax-ex-1.0.pom
[INFO] [antrun:run {execution: run-testsuite}]
[INFO] Executing tasks
Is there any resolution for that issue?
Best regards,
Johannes
--
|-
| weberhofer GmbH | Johannes Weberhofer
| information technologies
| Austria, 1080 Wien, Blindengasse 52/3
|
| Firmenbuch: 225566s, Handelsgericht Wien
| UID: ATU55277701
|
| phone : +43 (0)1 5454421 0| email: off...@weberhofer.at
| fax : +43 (0)1 5454421 19 | web : http://weberhofer.at
| mobile: +43 (0)699 11998315
|---
Re: There's still hope for 2.2...
Just rolled back to the 1.7 level of javamail. Also, Jarek updated the openejbVersion to 3.1.2. -Donald Donald Woods wrote: Agree, if that is the last set of artifacts holding up the release, then we can roll back to 1.7. -Donald Rick McGuire wrote: Donald Woods wrote: I did upgrade the javamail version to 1.8-SNAPSHOT, as Rick has checked in several fixes in the past few months I'm not sure those fixes are worth spinning a new javamail release just for inclusion on the 2.2 release. Rick -Donald David Jencks wrote: We may be able to release 2.2 soon. Activemq has fixed the last bug we had problems with and is fast approaching a release, openejb is getting very close to a release for 2.2, and I've started votes on a number of our snapshot dependencies. At this point I'd like anyone who is working on something they'd like to get into 2.2 to reply to this with a description of what they are working on and an estimate for completion. Also, if there is something you think is really necessary to get into 2.2 please reply and describe what you'd like. many thanks david jencks
osgi trunk
I have the sandbox osgi framework working enough to start the geronimo plugins, so I'm planning to move this work into trunk so we can all pitch in more easily on getting the rest of geronimo running on osgi. There's one legal issue to take care of first, since I copied in some plexus code that is not clearly available under asl2. The code appears to have been derived from ant, so I'm going to see if we can get the same results by importing or using ant code. I think that Donald is planning to make a branch off of trunk for a convenient place to try out jpa2 stuff at least until we have the equivalent working under osgi. If you have any concerns about this please speak up! thanks david jencks
Re: Wiki link to current version page
Hi Quintin, Thank you for your advice. That's very useful for us. I'll look into SEO and try to make our pages better. Best regards, Ellen 2009/10/14 Quintin Beukes quin...@skywalk.co.za Futher, if the old docs are taken out, it would leave a structure that's much more focused on a the newest version, and thus reduce the likeliness of GoogleBot seeing the pages as being too similar. GoogleBot is very sensitive with this and sometimes sees 2 completely irrelevant pages as being similar. I've found on 2 occasions that changing the wording on one page could cause another page to suddenly appear with the next index. This could be coincidence, as many reasons could cause a page to become indexed, but the similarity seems most probably since looking at the 2 pages you could understand how a bot could see them as similar. Further, updating the documentation with basic SEO in mind, and improving the link webs should help get more pages indexed - and possibly even listed higher. Quintin Beukes On Wed, Oct 14, 2009 at 5:19 PM, Quintin Beukes quin...@skywalk.co.za wrote: The 2.2 docs are on google. In fact, all the versions are there. By default it only lists 1/2 similar pages, and the rest can be viewed by clicking on the more results link. From what I could see on the pages, the reason 1.1 docs are listed first is an SEO issue, in that the 1.1 docs contain the word Geronimo more, and has a ranked page linking to it. To host all the documentation online would make a for a major SEO task added onto the list. Maybe the best would be to add the old docs into an archive (another domain would be best), link into the archive, and have only the latest docs actually stored on the xwiki.apache.org domain. I don't know if this is possible, but it should definitely clear up the documentation issue. If you're unlucky the archive ends up ranking higher than the original and you're back to where you started, though I think that would be unlikely if there is a link trail to Geronimo from the xwiki root, and back up wards (and the same for all apps). This should keep the rank tree farely high, and an archive would be unlikely to overtake it. I'm no SEO expert, so this might not be the best advice, but it would be what I would have done. Quintin Beukes On Wed, Oct 14, 2009 at 5:02 AM, Ellen Tang ltang.el...@gmail.com wrote: Hi, I found that the I'm feeling lucky function only takes you to the first website listed in Google responding to your query. This is why you are directed to 1.1 docs instead of 2.1. But I do see the problem that 2.2 docs are not listed in Google. I've seen the Confluence help pages with the links of the latest version as you suggested. It works very well on the Confluence websites. I think it's a very good function but yet takes a lot effort to implement because we have so many pages and versions of G docs right now. Plus, once we have a new release, all the links need to be updated. As discussed with Jeff, we can first try to make our latest docs display in Google. Please let us know if you have any suggestions for that. Thank you! Best regards, Ellen 2009/10/1 Juergen Weber webe...@gmail.com Fixing the links doesn't seem to be the general solution, e.g. with geronimo ra.xml and I'm feeling lucky you get the 1.1 docs, even if google knows the 2.1 docs. There should be a friendly big red box on old pages There exists a more recent version of this page with a link to it. Greetings, Juergen Ellen Tang-2 wrote: I've tried to find the page of the same topic (Daytrader) in documentation v2.1 by changing the link directly from http://cwiki.apache.org/GMOxDOC20/daytrader.html to http://cwiki.apache.org/GMOxDOC21/daytrader.html . The page does open and has correct contents, but when I tried to find the link of the same topic in the table of contents of v2.1 documentation ( http://cwiki.apache.org/GMOxDOC21/documentation.html ), I couldn't find the link for the Daytrader page, which does exist. I guess that this is why the google search can't find the page of Daytrader in Geronimo v2.1 documentation. Jeff, maybe you can have a check for this to see if you get the same result as me. Thanks! Ellen 2009/9/30 chi runhua chirun...@gmail.com I think it's the problem of the template in auto-export plugin, but only confluence admin could do some configuration to update the template. Jeff C On Wed, Sep 30, 2009 at 10:12 AM, Ellen Tang ltang.el...@gmail.comwrote: Hi Juergen, I guess that could be a good thing to do. We'll discuss about that to see if it's possible and necessary to do that. Thank you for your idea! Best regards, Ellen 2009/9/28 Juergen Weber webe...@gmail.com Hi, googling often leads to an old
Re: GEP 2.2
Are you building GEP testsuite? I don't know why you build GEP testsuite.
Indeed, there is some issues in current testsuite.
But if you only want to get the latest GEP, you don't have to build the
testsuite, just mvn clean install under trunk.
BTW, the latest build of GEP can be downloaded from the unstable site
http://people.apache.org/dist/geronimo/eclipse/unstable/2.2.0/
Hope it helps!
2009/10/16 Johannes Weberhofer, Weberhofer GmbH off...@weberhofer.at
It's
Path: .
URL:
http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/trunk
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 825495
Node Kind: directory
Schedule: normal
Last Changed Author: delos
Last Changed Rev: 824225
Last Changed Date: 2009-10-12 06:59:59 +0200 (Mon, 12 Oct 2009)
Hope, it helps!
Johannes
Am 15.10.2009 21:16, schrieb Quintin Beukes:
Can you please run and paste svn info from the route of your checkout.
Quintin Beukes
On Thu, Oct 15, 2009 at 4:18 PM, Johannes Weberhofer, Weberhofer GmbH
off...@weberhofer.at wrote:
Building the current 2.2 version of the trunk I'm constantly getting the
following error:
[INFO]
[INFO] Building Geronimo Eclipse Plugin :: Testsuite :: Launcher
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file-set:
/srv/project/autobuild/gep/trunk/testsuite/launcher (included:
[launcher/.metadata, launcher/eclipse, launcher/results,
launcher/server_v2.2, launcher/server_v2.1, launcher/server_v2.0,
launcher/workspace], excluded: [])
[INFO] [buildnumber:create {execution: default}]
[INFO] Storing buildNumber: 20091015161556 at timestamp: 1255616156287
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing
/srv/project/autobuild/gep/trunk/testsuite/launcher/pom.xml to
/srv/downloads/maven/org/apache/geronimo/devtools/testsuite-launcher/2.2.0/testsuite-launcher-2.2.0.pom
[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0:test' is invalid. It
will be ignored for artifact resolution. Reason: Not a v4.0.0 POM. for
project org.jvnet.staxex:stax-ex at
/srv/downloads/maven/org/jvnet/staxex/stax-ex/1.0/stax-ex-1.0.pom
[INFO] [antrun:run {execution: run-testsuite}]
[INFO] Executing tasks
Is there any resolution for that issue?
Best regards,
Johannes
--
|-
| weberhofer GmbH | Johannes Weberhofer
| information technologies
| Austria, 1080 Wien, Blindengasse 52/3
|
| Firmenbuch: 225566s, Handelsgericht Wien
| UID: ATU55277701
|
| phone : +43 (0)1 5454421 0| email: off...@weberhofer.at
| fax : +43 (0)1 5454421 19 | web : http://weberhofer.at
| mobile: +43 (0)699 11998315
|---
--
Best Regards,
Delos
Re: osgi trunk
Sounds good to me. I'll create a branch of the old 3.0 stuff to use with the EE6 TCKs while we're getting trunk converted. I just have one or two build problems to finish fixing and then I'll cut a branch in the next day or two -Donald David Jencks wrote: I have the sandbox osgi framework working enough to start the geronimo plugins, so I'm planning to move this work into trunk so we can all pitch in more easily on getting the rest of geronimo running on osgi. There's one legal issue to take care of first, since I copied in some plexus code that is not clearly available under asl2. The code appears to have been derived from ant, so I'm going to see if we can get the same results by importing or using ant code. I think that Donald is planning to make a branch off of trunk for a convenient place to try out jpa2 stuff at least until we have the equivalent working under osgi. If you have any concerns about this please speak up! thanks david jencks
[jira] Resolved: (GERONIMO-4693) Update OpenEJB version from 3.1.1 to 3.1.2
[ https://issues.apache.org/jira/browse/GERONIMO-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan resolved GERONIMO-4693. Resolution: Fixed Updated by Jarek, thanks ! Update OpenEJB version from 3.1.1 to 3.1.2 -- Key: GERONIMO-4693 URL: https://issues.apache.org/jira/browse/GERONIMO-4693 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.2 Reporter: Ivan Assignee: Ivan Fix For: 2.2 The version of OpenEJB trunk is 3.1.2-SNAPSHOT now, we need to update the OpenEJB version in Geronimo 2.2 to 3.1.2-SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
