[
http://issues.ops4j.org/jira/browse/PAXCONSTRUCT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_10971
]
Stuart McCulloch commented on PAXCONSTRUCT-61:
----------------------------------------------
managed to recreate this, but getting some very strange results
say I have some borked xml in target/contents and working xml in
target/classes then here's the results from updating with various
Bundle-ClassPath settings:
Bundle-Classpath: . PASS
Bundle-ClassPath: target/classes PASS (xml read 2x)
Bundle-ClassPath: target/contents FAIL (xml read 2x)
Bundle-ClassPath: .,target/classes PASS (xml read 2x)
Bundle-ClassPath: .,target/contents FAIL (xml read 2x)
Bundle-ClassPath: target/classes,. PASS (xml read 2x)
Bundle-ClassPath: target/contents,. FAIL (xml read 2x)
Bundle-ClassPath: target/classes,target/contents FAIL (xml read 3x)
Bundle-ClassPath: target/contents,target/classes PASS (xml read 3x)
so it looks as if Spring-DM is searching the bundle root first, then
all embedded entries on the Bundle-ClassPath - and takes the last
definition as the one to use...
so when it's just the root (.) and original contents (target/contents)
it will always use the XML from the original contents - even if the XML
in the root is OK, and no matter what the ordering is
the only way to get it to see the latest XML is to put target/classes
after target/contents, which tricks it into picking up the correct XML
(as it's not the root, and appears at the end)
however this is really messy and we're just really patching around
the way Spring-DM loads XML files from the bundle classpath - it's
still going to load it multiple times even with the workaround :(
so my plan is to improve the unpacking of target/contents so that
it only contains non-local classes and resources, which should then
stop this sort of thing from happening again
WDYT?
> pax:eclipse - target/contents classpath entry can cause strange issues with
> Spring-DM resource loading
> ------------------------------------------------------------------------------------------------------
>
> Key: PAXCONSTRUCT-61
> URL: http://issues.ops4j.org/jira/browse/PAXCONSTRUCT-61
> Project: Pax Construct
> Issue Type: Bug
> Components: maven-pax-plugin
> Affects Versions: 0.6.2
> Reporter: Wouter de Vaal
> Assignee: Stuart McCulloch
> Fix For: 0.6.3
>
>
> On Dec 11, 2007 3:31 AM, Stuart McCulloch <[EMAIL PROTECTED]> wrote:
> >
> > On 11/12/2007, Wouter de Vaal <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Hi,
> > >
> > > When I upgraded to the latest pax construct plugin, I get an extra
> > > manifest header for the eclipse manifest:
> > > Bundle-ClassPath: .,target/contents
> >
> >
> > yes - this is expected, because when using Bnd you may have classes inside
> > your bundle
> > that aren't on your sourcepath (for example classes or resources inlined
> > from other jars)
> >
> > therefore, the modified Eclipse mojo unpacks the final bundle and adds
> > target/contents
> > to the Eclipse classpath (_after_ the source entries) so that the
> > "non-source" classes are
> > available - it can't use target/classes, because this will be wiped by
> > Eclipse when doing
> > a clean build, so we use target/contents - and it's easier to unpack
> > everything than try
> > to work out which bits are related to local source files, and which
> > aren't...
> Ok now I have an idea why this is done. I allways told my collegues
> not to call project->clean, but I guess this is now ok to do, right?
> >
> >
> >
> > > This is quite annoying, as the class files are also copied there during a
> > > maven build but not when I edit an save a file within eclipse. Now there
> > > are two versions on the classpath when running equinox from within
> > > eclipse, which leads to freaky errors.
> >
> >
> > what sort of errors? when you edit and save a file in Eclipse it should do
> > an incremental
> > build to target/classes, which is before target/contents on the Eclipse
> > build path - so any
> > modified classes should always appear _before_ their previous unpacked
> > version.
> >
> > can you send instructions on how to recreate these errors, or at least
> > provide a bit more
> > detail - as it's better to fix the cause, not the symptom... just turning
> > the feature off isn't
> > an option for some users that need this unpacking
> Ok I've got more info now. We don't have any issues with classes. The
> issues lies in
> the use of a spring context .xml file. We have put this on the
> classpath using the Spring-Context: classpath:applicationContext.xml
> header. The file itself is in src/main/resources and gets updated to
> target/classes on safe, just like te rest of the classes, so nothing
> strange there.
> However when I foobar something in the beans definition (like changing
> a bean id without updating the references) and I call update
> <bundlenr> from the osgi console, this issue isn't picked up. When I
> remove the target/contents part from the Bundle-ClassPath header and
> update, spring shows an error. When I put the classpath entry back
> again and update, the error is gone.
> Is this enough information for you to go on, do you use spring yourself?
> - Hide quoted text -
> Wouter
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.ops4j.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
