Bug 322627

Comment 1 chrisatpinguin 2010-08-16 10:54:20 EDT

I think the answer is already in the forum (http://www.eclipse.org/forums/index.php?t=msg&th=172227&start=0&S=123e4c380bfcb70670469d3c41ea3d89).

Comment 2 Steve Powell 2010-08-19 06:29:33 EDT

chrisatpinguin,

Is your problem fixed?  Please record the outcome here.

Whether it is fixed or not, please can you take the time to identify the problem more precisely so that we know what issue you encountered.

For example:
  You included a maven repository in your repository chain -- can we see the configuration settings you actually used?

  When the server fails to start can we have an extract from the log here (or the whole log if you want to attach it) -- rather than 'it says something like..."?

  Can we have an idea of what you expected to happen (that is, why you think this is a bug), and what you were attempting to achieve?

If there is no response in a few days, this issue will close (as unable to reproduce).

Thank you.

Comment 3 chrisatpinguin 2010-08-19 09:59:35 EDT

Hi,

thanks for the reply. My problem is "fixed" because I think I now understand the problem ;) Thanks to Glyn Normington in the forum thread mentioned in my last comment.

What I have done is add new external maven repository in the server config file org.eclipse.virgo.repository.properties:

ext.type=external
ext.searchPattern=repository/ext/{artifact}
usr.type=watched
usr.watchDirectory=repository/usr
p-ext.type=external
p-ext.searchPattern=${user.home}/.m2/repository/**/{bundle}.jar
chain=ext,usr,p-ext

If I understand the comment from Glyn in the forum correct the server failed at startup because there are more then 1 artifact in the available repository chain which exported the needed  dependencies for the server artifacts. (" If bundles are added to the repositories which export packages that are exported by other bundles, this can cause problems because of the OSGi resolver in Equinox "latching on" to specific providers of packages and running into a uses constraint violation." from the forum)

Attached you find an extract from the logfile with a more specific error message.

Before I read in the forum I simply expected that the server started without failure and if I try to deploy a bundle the server could search for all needed dependencies in my maven repository. I do not think that this is a very good solution for a "real server" but I just started evaluation of virgo and I want to see what is possible and what is not. 

Hope I could help with my comment, if you have more questions please ask, I try my best to help.

Thx
Chris

Comment 4 chrisatpinguin 2010-08-19 10:00:54 EDT

Created attachment 176996 [details]
extract from server logfile with local maven repository configured as external virgo repository

Comment 5 Steve Powell 2010-08-19 12:10:25 EDT

OK. Thank you for the information.

From the log you are not getting 'uses constraint' violations, but instead what appears to be happening is that extra bundles available in your maven repository are of a later version than one (or more) in the repository/ext and one (or more) of them is being deployed (and resolved) as part of the springdm plan deployment.

The references to org.springframework.jdbc.3.0.0.M3 is particularly strange, since there ought to be no direct references to that in the plan, but there very well may be an indirect reference to a range that includes it.

Now M3 is a bit old, and the 3.0.0.RELEASE version of this bundle ought be used -- you don't have it in the repository chain.  In theory, this ought to be solved by the resolver trying to resolve another way, but if the dependencies aren't optional this might inhibit that.  When Virgo uses these repositories, in particular using the maven repositories, the usage is purely passive.  Unlike Maven  builds which will 'fault-in' versions it cannot find from Maven Central, the server will not do that.  The chain is all it sees.

Looking in my old maven repo (I don't use Maven very much) I see that it has org.springframeworjk.jdbc.3.0.0.M3 in it, so I can try your setup....
....
and I get problems with the extender:

[2010-08-19 16:58:26.227] system-artifacts             <DE0000I> Installing plan 'org.eclipse.virgo.kernel.userregion.springdm' version '2.1.0'. 
[2010-08-19 16:58:26.340] system-artifacts             <DE0000I> Installing bundle 'org.springframework.osgi.core' version '1.2.1'. 
[2010-08-19 16:58:26.376] system-artifacts             <DE0000I> Installing bundle 'org.springframework.osgi.extender' version '1.2.1'. 
[2010-08-19 16:58:26.393] system-artifacts             <DE0000I> Installing bundle 'org.springframework.osgi.io' version '1.2.1'. 
[2010-08-19 16:58:26.408] system-artifacts             <DE0000I> Installing bundle 'org.eclipse.virgo.kernel.agent.dm' version '2.1.0.L'. 
[2010-08-19 16:58:26.420] system-artifacts             <DE0000I> Installing bundle 'org.eclipse.virgo.kernel.deployer.dm' version '2.1.0.L'. 
[2010-08-19 16:58:29.836] system-artifacts             <DE0001I> Installed bundle 'org.springframework.osgi.core' version '1.2.1'. 
[2010-08-19 16:58:29.840] system-artifacts             <DE0001I> Installed bundle 'org.springframework.osgi.extender' version '1.2.1'. 
[2010-08-19 16:58:29.844] system-artifacts             <DE0001I> Installed bundle 'org.springframework.osgi.io' version '1.2.1'. 
[2010-08-19 16:58:29.848] system-artifacts             <DE0001I> Installed bundle 'org.eclipse.virgo.kernel.agent.dm' version '2.1.0.L'. 
[2010-08-19 16:58:29.851] system-artifacts             <DE0001I> Installed bundle 'org.eclipse.virgo.kernel.deployer.dm' version '2.1.0.L'. 
[2010-08-19 16:58:29.865] system-artifacts             <DE0001I> Installed plan 'org.eclipse.virgo.kernel.userregion.springdm' version '2.1.0'. 
[2010-08-19 16:58:29.895] system-artifacts             <DE0004I> Starting plan 'org.eclipse.virgo.kernel.userregion.springdm' version '2.1.0'. 
[2010-08-19 16:58:29.904] system-artifacts             <DE0004I> Starting bundle 'org.springframework.osgi.core' version '1.2.1'. 
[2010-08-19 16:58:29.912] start-signalling-2           <DE0005I> Started bundle 'org.springframework.osgi.core' version '1.2.1'. 
[2010-08-19 16:58:29.913] system-artifacts             <DE0004I> Starting bundle 'org.springframework.osgi.extender' version '1.2.1'. 
[2010-08-19 16:58:30.270] system-artifacts             <DE0010I> Stopping bundle 'org.springframework.osgi.extender' version '1.2.1'. 
[2010-08-19 16:58:30.279] system-artifacts             <DE0011I> Stopped bundle 'org.springframework.osgi.extender' version '1.2.1'. 
[2010-08-19 16:58:30.291] start-signalling-2           <DE0006E> Start failed for bundle 'org.springframework.osgi.extender' version '1.2.1'. java.lang.RuntimeException: bundle stopped
	at org.eclipse.virgo.kernel.core.internal.BundleStartTracker$StartupTrackerBundleListener.bundleChanged(BundleStartTracker.java:246)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:919)
. . .

Now look at the version of ...agent.dm being used -- since I'm running with a local build my versions have qualifiers BUILD-2010... but there are older ones in the maven repository which have qualifier L -- and so they get loaded in preference, and the code base is entirely out-of-synch.  I'm likely to get runtime errors even if it does resolve.

What is happening is that the artifacts in the repository chain are considered as a whole -- and the highest version artifacts (in the range) are used to satisfy any import dependencies in bundle manifest headers.

If this is a problem for you I suggest you specify a search pattern for your maven repo that includes only jars that you want to find there, for example

p-ext.searchPattern=${user.home}/.m2/repository/your.package.root/**/{bundle}.jar

and start the server -clean.  Avoiding /org/**/*.jar should avoid the clashing bundles here.  You can put several ext repos in the chain if you want.... 

Please let me know how you get on.