[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [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:

Hi Dennis,

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