You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Pierre De Rop <pi...@alcatel-lucent.fr> on 2009/01/22 12:34:42 UTC
issue with Felix 1.4.0 / ClassLoader.getResourceAsStream / DynamicImport-Package
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
Re: issue with Felix 1.4.0 / ClassLoader.getResourceAsStream / DynamicImport-Package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Sorry, meant to send that as a private message...
-> richard
Richard S. Hall wrote:
> Pierre,
>
> Are you available on Skype or Yahoo for an IM chat?
>
> -> richard
>
>
> Pierre De Rop wrote:
>> 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: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: issue with Felix 1.4.0 / ClassLoader.getResourceAsStream / DynamicImport-Package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Pierre,
Are you available on Skype or Yahoo for an IM chat?
-> richard
Pierre De Rop wrote:
> 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: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: issue with Felix 1.4.0 / ClassLoader.getResourceAsStream / DynamicImport-Package
Posted by Pierre De Rop <pi...@alcatel-lucent.fr>.
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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: issue with Felix 1.4.0 / ClassLoader.getResourceAsStream / DynamicImport-Package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: issue with Felix 1.4.0 / ClassLoader.getResourceAsStream / DynamicImport-Package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: issue with Felix 1.4.0 / ClassLoader.getResourceAsStream / DynamicImport-Package
Posted by Pierre De Rop <pi...@alcatel-lucent.fr>.
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 ?
/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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: issue with Felix 1.4.0 / ClassLoader.getResourceAsStream / DynamicImport-Package
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org