Key: KERN-657
URL: http://jira.sakaiproject.org/browse/KERN-657
Project: Nakamura
Issue Type: Bug
Components: System - other
Affects Versions: 0.3
Environment: Linux with Java 5 or Java 6
Reporter: Ian Boston
Priority: Blocker
Fix For: 0.3
see thread http://groups.google.co.uk/group/sakai-kernel/browse_thread/thread/7abda5876d85a4eb
for future reference.
1. 100% CPU when the Repo tries to start.
2. All bundles at start level 0 in the jar and in sling/startup
Also
Failing
the eclipse core and Nakamura persistence bundle.
This is thought to be due to the location of the JPA bundle in the start order, possibly because of the resolution statements in the manifest of depedent bundles.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.sakaiproject.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Ian Boston commented on KERN-657:
---------------------------------
The current State of play is (moved javax.persistence to Start level 1)
javax.persistence bundle 54 1.99.0 is in start level 1. has started Ok
org.eclipse.persistence.core bundle 93, start level 11 also depends on javax.persistence 53 and has started OK
org.eclipse.persistence.jpa, bundle 95 is in start level 11 and according to the Logs has
24.02.2010 17:14:31.006 *ERROR* [24225764@qtp-32472548-5] org.apache.felix.webconsole Cannot start (org.osgi.framework.BundleException: Unable to resolve due to constraint violation.) org.osgi.framework.BundleException: Unable to resolve due to constraint violation.
But no indication of what the constraint violation is.
Finally org.sakaiproject.nakamura.persistence, bundle 13, startlevel 15 cant be started.
org.eclipse.persistence.internal.jpa.deployment,version=1.1.0 -- Cannot be resolved
!! org.eclipse.persistence.internal.jpa.deployment.osgi,version=1.1.0 -- Cannot be resolved
!! org.eclipse.persistence.jpa,version=1.1.0 -- Cannot be resolved
which *is* correct as these are in bundle 95 which didnt start.
So the key to all of this is,
org.eclipse.persistence.jpa does not start, but it doesn't say why it wont start. No errors in the log and the only items in the console say
!! com.sun.tools.javac,version=0.0.0 -- Cannot be resolved but is not required
!! org.apache.env,version=0.0.0 -- Cannot be resolved but is not required
!! org.apache.tools.ant.taskdefs.optional,version=0.0.0 -- Cannot be resolved but is not required
!! org.apache.tools.ant.util.java15,version=0.0.0 -- Cannot be resolved but is not required
!! sun.rmi.rmic,version=0.0.0 -- Cannot be resolved but is not required
!! sun.tools.javac,version=0.0.0 -- Cannot be resolved but is not required
ie all optional.
BTW, the bundle numbers will change.
Trying a startup with debug full on.
Ian Boston commented on KERN-657:
---------------------------------
Bundle-Require statements in the manifest are not reported as not being satisfied. Apparently its bad OSGi practice to use them, and not supported in some situations (bundle 0)
Ian Boston commented on KERN-657:
---------------------------------
I suspect this was discovered a few days ago, but I couldn't find it anywhere on list.
only appears with -l DEBUG for future reference.
DEBUG: WIRE: 93.0 -> org.apache.commons.logging -> 50.0
DEBUG: Constraint violation for 95.0 detected; module can see javax.transaction.xa from [56.0] and javax.transaction.xa from [0]
DEBUG: Constraint violation for 95.0 detected; module can see javax.transaction.xa from [0] and javax.transaction.xa from [56.0]
DEBUG: Constraint violation for 95.0 detected; module can see javax.transaction.xa from [56.0] and javax.transaction.xa from [0]
DEBUG: Constraint violation for 95.0 detected; module can see javax.transaction.xa from [0] and javax.transaction.xa from [56.0]
ERROR: Error starting slinginstall:org.eclipse.persistence.jpa-1.1.0-0.3-SNAPSHOT.jar (org.osgi.framework.BundleException: Unable to resolve due to constraint violation.)
org.osgi.framework.BundleException: Unable to resolve due to constraint violation.
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3270)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1597)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:619)
Ian Boston commented on KERN-657:
---------------------------------
If I switch to JDK 1.5 exactly the same thing happens with bundle 95 so this is not a JDK thing, its a load order thing exposed on Linux.
I also notice that other bundles successfully resolve javax.transaction and javax.transaction.xa although they appear to reference the version 1.1.0 explicitly.
Persistence bundle starting...
Persistence bundle started.
DEBUG: WIRE: 28.0 -> com.google.common.collect -> 59.0
DEBUG: WIRE: 28.0 -> javax.jcr -> 5.0
DEBUG: WIRE: 28.0 -> javax.servlet -> 109.0
DEBUG: WIRE: 28.0 -> org.apache.commons.lang -> 66.0
DEBUG: WIRE: 28.0 -> org.apache.sling.api -> 1.0
DEBUG: WIRE: 28.0 -> org.apache.sling.api.request -> 1.0
DEBUG: WIRE: 28.0 -> org.apache.sling.api.resource -> 1.0
DEBUG: WIRE: 28.0 -> org.apache.sling.api.servlets -> 1.0
DEBUG: WIRE: 28.0 -> org.apache.sling.commons.json -> 81.0
DEBUG: WIRE: 28.0 -> org.apache.sling.commons.json.io -> 81.0
DEBUG: WIRE: 28.0 -> org.sakaiproject.nakamura.api.connections -> 77.0
DEBUG: WIRE: 28.0 -> org.sakaiproject.nakamura.api.doc -> 91.0
DEBUG: WIRE: 28.0 -> org.sakaiproject.nakamura.api.memory -> 11.0
DEBUG: WIRE: 28.0 -> org.sakaiproject.nakamura.api.personal -> 57.0
DEBUG: WIRE: 28.0 -> org.sakaiproject.nakamura.util -> 71.0
DEBUG: WIRE: 28.0 -> org.slf4j -> 72.0
DEBUG: Constraint violation for 29.0 detected; module can see
javax.transaction.xa from [0] and javax.transaction.xa from [36.0]
DEBUG: Constraint violation for 29.0 detected; module can see
javax.transaction.xa from [36.0] and javax.transaction.xa from [0]
On Fedora 12 with JDK 1.6
Earle
On Feb 24, 1:40Â pm, "Ian Boston (JIRA)" <k2-j...@sakaiproject.org>
wrote:
> Â Â [http://jira.sakaiproject.org/browse/KERN-657?page=com.atlassian.jira....]
> > see threadhttp://groups.google.co.uk/group/sakai-kernel/browse_thread/thread/7a...
Carl Hall commented on KERN-657:
--------------------------------
I was able to get around this using the following settings in the JTA bundle's manifest
Export-Package: javax.transaction.xa;version="1.1";-split-package:=merge-first,javax.transaction;uses:="javax.transaction.xa";version="1.1";-split-package:=merge-first
Require-Bundle: org.apache.felix.framework
Ian Boston commented on KERN-657:
---------------------------------
Which bundle ?
geronimo JTA or the system ?
Ian Boston commented on KERN-657:
---------------------------------
Ok so I built a custom JTA Geronimo bundle and did merge-first and merge-last and neither work on OSX with JDK 1.6
Manfest is
Manifest-Version: 1.0
Export-Package: javax.transaction.xa;version="1.1";-split-package:=mer
ge-last,javax.transaction;uses:="javax.transaction.xa";version="1.1";
-split-package:=merge-last
Built-By: ieb
Tool: Bnd-0.0.357
Bundle-Category: sakai-nakamura
Bundle-Name: Sakai Java Transactions (JTA) Bundle
Created-By: Apache Maven Bundle Plugin
Require-Bundle: org.apache.felix.framework
Bundle-Vendor: The Sakai Foundation
Build-Jdk: 1.6.0_17
Bundle-Version: 0.3.0.SNAPSHOT
Bnd-LastModified: 1267050952959
Bundle-ManifestVersion: 2
Bundle-Description: Nakamura Experiments to evaluate approaches and ge
nerate Proof of Concept implementations.
Import-Package: javax.transaction;version="1.1",javax.transaction.xa;v
ersion="1.1"
Bundle-SymbolicName: org.sakaiproject.nakamura.specs.jta
Bundle-DocURL: http://groups.google.com/group/sakai-nakamura
And I have checked in the console to verify this is the one that is loaded and I still get
DEBUG: WIRE: 80.0 -> org.slf4j -> 36.0
DEBUG: Constraint violation for 84.0 detected; module can see javax.transaction.xa from [43.0] and javax.transaction.xa from [0]
DEBUG: Constraint violation for 84.0 detected; module can see javax.transaction.xa from [43.0] and javax.transaction.xa from [0]
DEBUG: Constraint violation for 84.0 detected; module can see javax.transaction.xa from [43.0] and javax.transaction.xa from [0]
ERROR: Error starting slinginstall:org.sakaiproject.nakamura.persistence-0.3-SNAPSHOT.jar (org.osgi.framework.BundleException: Unable to resolve due to constraint violation.)
org.osgi.framework.BundleException: Unable to resolve due to constraint violation.
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3270)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1597)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:637)
DEBUG: WIRE: 85.0 -> com.google.common.collect -> 38.0
DEBUG: WIRE: 85.0 -> javax.jcr -> 73.0
ProviderTracker: Added service
org.eclipse.persistence.jpa.osgi.PersistenceProviderOSGi
ERROR: Error starting slinginstall:D:\Data\svndirs\open-experiments
\slingtests\osgikernel\app\target\sling\startup
\15\org.sakaiproject.nakamura.persistence-0.3-SNAPSHOT.jar
(org.osgi.framework.BundleException: Unable to resolve due to
constraint violation.)
org.osgi.framework.BundleException: Unable to resolve due to
constraint violation.
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:
3270)
at org.apache.felix.framework.Felix.startBundle(Felix.java:
1597)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:619)
Ian Boston commented on KERN-657:
---------------------------------
Looking at the full set of bindings it looks like some packages dont have explicit versions for javax.transaction, hence they bypass the 1.1 version and bind directly to the 0.0 version. This causes a leak of the 0.0 version into other bundles which they see.
It looks like the cause of the problem may be org.eclipse.persistence.jpa wihch has no version set on the java.transaction.xa which causes it to be loaded from 0.0 rather than 1.1
org.apache.sling.jcr.jackrabbit.server (xa, dynamic, sql from 0, level 15) 75 -> 43
org.apache.sling.commons.scheduler (xa, no version, sql from 0, level 12) 62 -> 43
org.apache.sling.jcr.base xa, no version, no sql, level 15 74 -> 43
org.apache.jackrabbit.jackrabbit-api (no version. no sql,level 15) 70 -> 43
org.eclipse.persistence.jpa (xa to 0, sql to 0, level 11) 56 -> 0 no version on xa
56 -> 43
org.eclipse.persistence.core (no xa, sql, start level 10) 49 -> 43
org.sakaiproject.nakamura.specs.jms ( level 1, no version on XA ) 41 -> 0
org.sakaiproject.nakamura.activemq ( level 1, no version on XA ) 37 -> 0
org.sakaiproject.nakamura.specs.ejb (level 1, no version on transaction ) 40 -> 0
org.apache.geronimo.specs.geronimo-j2ee-connector_1.5_spec ( level 1, no version on transaction ) 31 -> 0
org.sakaiproject.nakamura.persistence 84 -> 0
84 -> 43
Ian Boston commented on KERN-657:
---------------------------------
No specifying a version on the javax.transaction.xa in org.eclipse.persistence.jpa just causes it to refuse to load.
Perhaps this is because its further down the line that the problem is.
org.eclipse.persistence.jpa only depends on org.sakaiproject.nakamura.specs.jta(43), org.eclipse.persistence.core (49), javax.persistence (bundle 33), and the framework (0),
Of those 49,33 dont depend on javax.transaction 0 and 43 do.
In 43 we have a manifest header of
Import-Package: javax.transaction; version="1.1", javax.transaction.xa; version="1.1"
However it reports
javax.transaction,version=0.0.0 from org.apache.felix.framework (0)
javax.transaction.xa,version=0.0.0 from org.apache.felix.framework (0)
Since javax.transaction.xa uses javax.transaction it will load from 0, hence the conflict (perhapse... another stab in the dark comming up).
Try and make geronimo use javax.transaction.* v 1.1 rather than 0.0 ( I suspect its an issue with the bundle-require which is not recommended)
Ian Boston commented on KERN-657:
---------------------------------
This is not possible, there is no way of making it import the right values and replace, and then some o fthe bundles above still bind to the 0.0 version since they take the lowest version available in the Container not the highest. JTA is available from the start.
Interestingly manually editing the list of packaged available from bundle 0 allows the system to start up with no merge-first or Require-Bundle.
We could either try and find out how to modify the boot framework, if that is possible, or work through all the bundles and prevent them from binding to the 0.0 version.
I will try to modify the boot loader in the build. We cant ask people to edit it after startup.
Ian Boston updated KERN-657:
----------------------------
Original Estimate: 3 days
Remaining Estimate: 3 days
> 0.3 RC1 Wont start on Linux
> ---------------------------
>
> Key: KERN-657
> URL: http://jira.sakaiproject.org/browse/KERN-657
> Project: Nakamura
> Issue Type: Bug
> Components: System - other
> Affects Versions: 0.3
> Environment: Linux with Java 5 or Java 6
> Reporter: Ian Boston
> Priority: Blocker
> Fix For: 0.3
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
Ian Boston commented on KERN-657:
---------------------------------
Its possible to replace the jre properties file in the base loader so we can replace the packages loaded from the framework.
This appears to work with the for OSX 1.6, FC8 JDK 1.6, DC8 JDK 1.5
It does not need any special JTA bundles or split packages etc, so I am going to revert all the changes back to when we got the packages in the right start levels.
> 0.3 RC1 Wont start on Linux
> ---------------------------
>
> Key: KERN-657
> URL: http://jira.sakaiproject.org/browse/KERN-657
> Project: Nakamura
> Issue Type: Bug
> Components: System - other
> Affects Versions: 0.3
> Environment: Linux with Java 5 or Java 6
> Reporter: Ian Boston
> Priority: Blocker
> Fix For: 0.3
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
Ian Boston logged work on KERN-657:
-----------------------------------
Author: Ian Boston
Created on: 25-Feb-2010 04:38
Start Date: 25-Feb-2010 04:38
Worklog Time Spent: 2 days, 4 hours
Issue Time Tracking
-------------------
Remaining Estimate: 4 hours (was: 3 days)
Time Spent: 2 days, 4 hours
> 0.3 RC1 Wont start on Linux
> ---------------------------
>
> Key: KERN-657
> URL: http://jira.sakaiproject.org/browse/KERN-657
> Project: Nakamura
> Issue Type: Bug
> Components: System - other
> Affects Versions: 0.3
> Environment: Linux with Java 5 or Java 6
> Reporter: Ian Boston
> Priority: Blocker
> Fix For: 0.3
>
> Original Estimate: 3 days
> Time Spent: 2 days, 4 hours
> Remaining Estimate: 4 hours
Ian Boston resolved KERN-657.
-----------------------------
Resolution: Fixed
Fixed, in revision 99cfae8d138065b9d8f474e871dbad9c6b6bd31b
> 0.3 RC1 Wont start on Linux
> ---------------------------
>
> Key: KERN-657
> URL: http://jira.sakaiproject.org/browse/KERN-657
> Project: Nakamura
> Issue Type: Bug
> Components: System - other
> Affects Versions: 0.3
> Environment: Linux with Java 5 or Java 6
> Reporter: Ian Boston
> Priority: Blocker
> Fix For: 0.3
>
> Original Estimate: 3 days
> Time Spent: 2 days, 4 hours
> Remaining Estimate: 4 hours
>
Ian Boston logged work on KERN-657:
-----------------------------------
Author: Ian Boston
Created on: 25-Feb-2010 04:41
Start Date: 25-Feb-2010 04:41
Worklog Time Spent: 5 minutes
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 4 hours)
Time Spent: 2 days, 4 hours, 5 minutes (was: 2 days, 4 hours)
> 0.3 RC1 Wont start on Linux
> ---------------------------
>
> Key: KERN-657
> URL: http://jira.sakaiproject.org/browse/KERN-657
> Project: Nakamura
> Issue Type: Bug
> Components: System - other
> Affects Versions: 0.3
> Environment: Linux with Java 5 or Java 6
> Reporter: Ian Boston
> Priority: Blocker
> Fix For: 0.3
>
> Original Estimate: 3 days
> Time Spent: 2 days, 4 hours, 5 minutes
> Remaining Estimate: 0 minutes