Bugzilla – Full Text Bug Listing
| Summary: | [nosql] Constraints from the fragment conflict with the host: Import-Package: javax.naming; version="0.0.0" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Gunnar Wagenknecht <gunnar> | ||||||
| Component: | Eclipselink | Assignee: | Eric Gwin <eric.gwin> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | eric.gwin, tjwatson, tom.ware | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Gunnar Wagenknecht
Very strange that the march 19 version works... It doesn't appear as though we have changed the imports in either the core or the nosql bundle in that time. we seem to get javax.naming from the JDK... wonder if that has anything to do with the issue. (In reply to comment #0) > I wonder if it's just a false message because both (the nosql bundle as > well as the core bundle) have the package as optional which should be > fine. I can only imagine that it's something specific to the target > platform which may cause the issue. I'm wondering something similar. Specifically if this is some p2 resolution issue with optional dependencies. The only imported packages commom between core and nosql are: javax.naming;resolution:=optional, javax.resource;version="1.5.0";resolution:=optional, javax.resource.cci;version="1.5.0";resolution:=optional, and they are declared identically. I'm wondering if the buildisn't complaining about resource simply because the error condition with naming is hit first. A question about fragments, if B is a fragment of A; will B inherit the import access of A? If so, we could simply remove the imports above and avoid the issue. Add Tom, maybe he has some insights. I'm wondering if the conflict is because of some usage constraints. To me it seems that the fragment wants to import a different version of the "javax.naming" package which comes from a different bundle (not the JDK?). I also think it's not a p2 issue. The error message also pops up at launch time when validating the bundles with PDE. It's a messages generated by the Equinox OSGi framework. (In reply to comment #3) > A question about fragments, if B is a fragment of A; will B inherit the import > access of A? If so, we could simply remove the imports above and avoid the > issue. Yes, I think you should remove the duplicate imports from the fragment. Since they are both optional I am wondering if the resolver gets into a state where the host is resolved and it is trying to resolve the fragment. The hosts optional import of the package did not get resolved when the host was resolved. Then an attempt is made to resolve the fragment and for some reason the fragments optional import of the package does resolve. The resolver detects that the fragment is trying to insert a new constraint into an already resolved host. This is not allowed by the resolver. In order to allow such a fragment to attach to an already resolved host the host bundle would need to be re-resolved (refreshed). I am currently trying out Gunners attached target definition. Unfortunately it seems to take a very long time for the bundles to get downloaded to my target. Been going for now for as long as it took me to write this message ;-) Created attachment 214465 [details]
test project with target definition and OSGi launch config
I created a simple launch config. The thing is that javax.naming likely comes from the JDK. Thus I'm wondering why it shouldn't be wired to the host already.... Wait a minute, the host does define a higher BREE than the fragment. Once I modify the BREE of the fragment then all is fine again. Maybe that is causing the conflict responsible?
(In reply to comment #6) > Created attachment 214465 [details] > test project with target definition and OSGi launch config > > I created a simple launch config. The thing is that javax.naming likely comes > from the JDK. Thus I'm wondering why it shouldn't be wired to the host > already.... Wait a minute, the host does define a higher BREE than the > fragment. Once I modify the BREE of the fragment then all is fine again. Maybe > that is causing the conflict responsible? I was about to write a similar response from my findings. See bug 377510. I did not move this bug over to the framework since I still think the fragments should remove duplicate imports which are already defined by the host bundle. Fragments only need to specify additional constraints not already defined by the host. (In reply to comment #7) > I still think the fragments > should remove duplicate imports which are already defined by the host bundle. > Fragments only need to specify additional constraints not already defined by > the host. Ok. I will remove the duplicate entries from the fragment's manifest. FYI: M18 is already awaiting publication, so the change will show up in M19. Otherwise, it should be available in tonight's nightly build: 20120425 (In reply to comment #5) > Since they are both optional I am wondering if the resolver gets into a state > where the host is resolved and it is trying to resolve the fragment. The hosts > optional import of the package did not get resolved when the host was resolved. > Then an attempt is made to resolve the fragment and for some reason the > fragments optional import of the package does resolve. The resolver detects > that the fragment is trying to insert a new constraint into an already resolved > host. This is not allowed by the resolver. In order to allow such a fragment > to attach to an already resolved host the host bundle would need to be > re-resolved (refreshed). I am currently trying out Gunners attached target > definition. Unfortunately it seems to take a very long time for the bundles to > get downloaded to my target. Been going for now for as long as it took me to > write this message ;-) Upon review of the fix Tom Ware noticed a mismatch in the the Bundle-RequiredExecutionEnvironment settings; org.eclipse.persistence.core had been recently changed to: JavaSE-1.6 The fragments hadn't been updated yet and remained at: J2SE-1.5 We suspect that is the root cause. I expect I will be updating that as well. Though there is currently discussion regarding that change. Is there a way to update the Equinox error to report the mismatch rather than give a generic load failure message? (In reply to comment #9) > Is there a way to update the Equinox error to report the mismatch rather than > give a generic load failure message? My hope is to provide a fix to bug 377510 so that these false positives are not reported by the resolver. (In reply to comment #9) > > ... > > We suspect that is the root cause. I expect I will be updating that as well. > Though there is currently discussion regarding that change. The discussion continues. We may be reverting the original change in core. I'm holding off until tomorrow to await a decision. Both changes to the manifest merged in rev 377681. removed duplicate import-packages, and set RequiredExecEnv to match core (currently 1.6, though may revert with core to 1.5 in a week or so depending upon results of move to 1.6) Will be available in tonight's build (v20120427-r?????), and in the M19 milestone (scheduled for May 2 build) Moving ro resolved, so can be closed when fixavailable and verified. Also, FYI I did fix the original issue in the resolver that was reporting the false positive. I still think it is good that you removed the duplicate import. (In reply to comment #12) > Will be available in tonight's build (v20120427-r?????), and in the M19 > milestone (scheduled for May 2 build) I still get the error when using the M19 repo. Did it miss the build? (In reply to comment #15) > (In reply to comment #12) > > Will be available in tonight's build (v20120427-r?????), and in the M19 > > milestone (scheduled for May 2 build) > > I still get the error when using the M19 repo. Did it miss the build? Are you using the Equinox Juno M7 framework or still on M6? (In reply to comment #16) > > I still get the error when using the M19 repo. Did it miss the build? > > Are you using the Equinox Juno M7 framework or still on M6? Still on an old Equinox. Thus, I think it's the EclipseLink side that still has the conflict. (In reply to comment #15) > (In reply to comment #12) > > Will be available in tonight's build (v20120427-r?????), and in the M19 > > milestone (scheduled for May 2 build) > > I still get the error when using the M19 repo. Did it miss the build? Can you try the latest nightly build 20120509-r11315? There has been a lot of churn with the nosql bundle generation. Since the last update we've move it to generating with Tycho, fixed manifest issues with Glassfish, and many more. We also recently discovered that nosql was double building during the nightly process, and unfortunately the old incorrect build was overwriting the newer 'corrected' tycho bundle. We've also had to add back the javax.resource.cci import or Tycho failed to compile. It's possible that all these changes have undone this fix, so I'd like to see if your issue persists with the latest. (In reply to comment #17) > > Are you using the Equinox Juno M7 framework or still on M6? > > Still on an old Equinox. Thus, I think it's the EclipseLink side that still has > the conflict. Still the newer equinox may help. On our side, I've exploded M19 and have confirmed the bundle published was generated using the old bnd pathway and doesn't have the fixes. Unfortunately last night's build is unsuitable as a milestone for unrelated reasons. If I can confirm last night's build is good for you, I may be able to turn around a new milestone. I can confirm that the latest nightly does not expose the issue. (In reply to comment #20) > I can confirm that the latest nightly does not expose the issue. ok. we fixed our other issue and rebuilt. Promoted M19.1 based upon build 2.4.0.v20120509-r1132, however didn't want to risk Juno M7. Let me know if this doesn't solve your issue. The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |