Ok, I'll open the bug.
If you need me to test something, don't hesitate to ask.
thanks;
/pierre.
Richard S. Hall wrote:
Pierre,
I have looked into this a little bit and I believe I understand what
is going wrong and it is quite likely a bug introduced in Felix 1.4.0.
It appears that Felix is effectively allowing bundles to dynamically
import the default package.
This is why it fails for you in the "*" case, but not in the "com.*"
case. The former allows a dynamic wire to the system bundle for the
default package. The exact details of why this is happening are not
clear yet, but I can clearly see that this is happening from the
wiring messages in your logs.
If you could open up a bug on this to track it, I will work on
resolving it. Thanks.
-> richard
Richard S. Hall wrote:
Pierre De Rop wrote:
Yes, If I replace "DynamicImport-Package: *" by
"DynamicImport-Package: alcatel.tess.*,com.alcatel.ims.charging.*",
then it works fine !
I tried to re-create a sample code with a similar code, but my
sample code works fine and I don't reproduce the error.
I only reproduce the pb with the real application ...
-> would you like me to send you by mail the framework logs
(felix.log.level=4) ?
By the way, I noticed the following in the felix 1.4.0 changelog.txt:
* [2008-09-15] Fixed a bug where class loader delegation for dynamic
imports was happening when it shouldn't. (FELIX-724)
-> do you think this could apply to my current issue ?
Yes, that could be related. Send me your logs with and without
dynamic import "*" and let me know which bundle ID is the app below.
-> richard
/pierre
Richard S. Hall wrote:
Pierre,
That doesn't really make sense to me and must be a bug if there is
not more too it.
Dynamic imports are the last thing searched when looking for a
class/resource, while the bundle class path is the second to last
thing searched. I don't see why dynamic imports would impact
anything here, since the entry should be found on the bundle class
path before we even worry about dynamic imports.
Sounds really strange, but I think we will need some way to
recreate it.
Out of curiosity, does it work if you use something like
"DynamicImport-Package: com.*" ?
-> richard
Pierre De Rop wrote:
Hello everyone,
One of our appserver user is currently facing a strange issue
(which I can't reproduce for now ... :-( , bu I will managed to do
it, if I can ...)
(We are running with jdk 1.5 on linux with Felix 1.4.0).
The application does the following:
* a dtd file is stored within the application bundle, in
WEB-INF/classes/anchoringPolicy.dtd
* in the manifest, there is the following:
o an Import-Package header with many things ...
o DynamicImport-Package: *
o Bundle-ClassPath: "., WEB-INF/classes, ..." (I don't
report
all the inner embedded jars)
* at startup, the application tries to parse an xml document using
its dtd (in WEB-INF/classes/anchoringPolicy.dtd)
* So, the application does the following:
try {
SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setValidating(true);
SAXParser parser = spf.newSAXParser();
XMLReader xmlReader = parser.getXMLReader();
xmlReader.setEntityResolver(new EntityResolver() {
public InputSource resolveEntity(String publicId, String
systemId)
throws SAXException, IOException
{
InputStream s =
getclass().getClassLoader().getResourceAsStream("anchoringPolicy.dtd");
if (s == null) {
if (logger.isDebugEnabled()) {
logger.debug("unable to get resource stream for our dtd");
}
s =
Thread.currentThread().getContextClassLoader().getResourceAsStream("anchoringPolicy.dtd");
}
if (s != null) {
return new InputSource(s);
}
if (logger.isDebugEnabled()) {
logger.debug("dtd not found from the classpath: ");
}
return null;
}
});
xmlReader.setContentHandler(handler);
xmlReader.setErrorHandler(new PolicyErrorHandler());
xmlReader.parse(new InputSource(new
ByteArrayInputStream(policyFile.getBytes())));
}
This application was working fine with the felix *1.0.4
*Now, with Felix* 1.4.0* (and also with the felix-trunk), the
EntityResolver can't find its dtd and the following line of code
returns null:
InputStream s =
getclass().getClassLoader().getResourceAsStream("anchoringPolicy.dtd");
-> I investigated and it turns out, that , if I remove the header
"DynamicImport-Package: *" header, then the dtd is properly loaded
from the
application bundle class loader !
-> But I don't understand the relation between this issue and the
"DynamicImport-Package: *" header ?
I know that using the DynImport: * header is not really clean,
but, well, it should work, doesn't it ?
Best Regards
/pierre
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
