[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] M6 issue with javax.transaction
- From: Glyn Normington <gnormington@xxxxxxxxxx>
- Date: Tue, 12 Oct 2010 01:09:11 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: email@example.com
- Thread-index: Actp5MGCbhV8jxBrSmGYcLFLQW7i1w==
- Thread-topic: [virgo-dev] M6 issue with javax.transaction
This problem was reported under bug 327383 and the fix is to revert commit 09ce966db87b570eb40f384094b86588749e6d4c in the kernel. This places com.springsource.javax.transaction-1.1.0.jar back in lib and thereby makes it available on the classpath.
Dennis: your suggestion is workable too in general, but it does not preserve compatibility with dm Server 2.0.x so I prefer to be ultra-conservative as we are winding up to the 2.1.0 release of Virgo. (Also we've frozen the Virgo IP log, so we'd need to thaw it out to add a piggy-back CQ for the Orbit bundle. That alone could blow our schedule.)
Dmitry: the reason javax.transaction 1.1.0 needs to be on the class path is that the profile specifies:
org.osgi.framework.system.packages = \
and the JRE doesn't provide all the necessary classes.
On 11 Oct 2010, at 21:10, Dmitry Sklyut wrote:
Is there any specific reason why it is preferable to keep javax.transaction as part of system packages? I am fairly sure that no one will try to have two versions of apis and implementations floating around, just interested why that would be a better approach.
Virgo was using com.springsource.javax.transaction-1.1.0.jar from SpringSource Bundle Repository (http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.javax.transaction&version=1.1.0&searchType=bundlesBySymbolicName&searchQuery=javax.transaction). Because it was sitting in the lib directory, startup script was adding it to the boot classpath for server start up.
I will hold off on using fragment for now, as it will need to be included in the org.eclipse.virgo.kernel.launch.properties launcher.bundles list. Thus becoming one more artifact that I have to keep in synch for upgrades.
For now I just went with copying the jar to the lib directory and keeping java6-server.profile as is.
On Mon, Oct 11, 2010 at 1:21 PM, O'Flynn, Dennis <Dennis.OFlynn@xxxxxxxxxxxxx<mailto:Dennis.OFlynn@xxxxxxxxxxxxx>> wrote:
If I’m not mistaken, you want to keep javax.transaction as part of the system packages. But you also need to include the javax.transaction_1.1.1.v201004190952.jar bundle from the Eclipse Orbit repository. This bundle is a fragment bundle that is attached to the system bundle as its host bundle.
The combination of Java 1.6 and the fragment bundle will provide the javax.transaction packages and classes.
From: virgo-dev-bounces@xxxxxxxxxxx<mailto:virgo-dev-bounces@xxxxxxxxxxx> [mailto:virgo-dev-bounces@xxxxxxxxxxx<mailto:virgo-dev-bounces@xxxxxxxxxxx>] On Behalf Of Dmitry Sklyut
Sent: Monday, October 11, 2010 1:07 PM
To: Virgo Project
Subject: [virgo-dev] M6 issue with javax.transaction
It looks like javax.transaction is no longer in /lib. That caused me a few minutes of panic while upgrading from M3 to M6 right now.
javax.transaction.Transaction manager could not be resolved from org.springframework.orm bundle.
javax.transaction is in a list of org.osgi.framework.system.packages in java6-server.profile. I manually copied javax.transaction to lib and restarted and was back in a good graces of osgi gods.
The question is - should java6-server.profile be modified as well to remove javax.transaction from the list of system packages?
I did just that, removed all references to javax.transaction from java6-server.profile and deleted javax.transaction from lib and now bundles deployed in the userregion properly resolve to the javax.transaction bundle deployed in repository/ext.
So what is the right way to go here?
virgo-dev mailing list