You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Patrick Forhan <fe...@muddyhorse.com> on 2008/09/04 17:54:38 UTC
Bringing Felix bundles up-to-date.
We're getting ready to roll out a new set of core bundles for our
application platform... updating to the following:
Felix core 1.0.4
shell 1.0.1
bundlerepository 1.0.3
scr 1.04
eventadmin 1.0.0
(... and pax-confman and pax-logging)
Everything went pretty smoothly, except for Felix core. We had three
issues, possibly all related:
- RepositoryAdmin got set, the removed, then set, which caused an NPE
in one of our declared service classes
- logging seemed to be going through a mix of PAX-logging and the
default Felix logger
- we could no longer load images from a Class.getResource() URL like
bundle://56.0:1/org/bjc/pt2/i18n/mock/background.png
We rolled felix back to 1.0.3 and these problems went away. Is there
some reason for this? Do we need 1.0.4?
Thanks,
Pat.
--
Defy mediocrity.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bringing Felix bundles up-to-date.
Posted by Patrick Forhan <fe...@muddyhorse.com>.
On Thu, Sep 4, 2008 at 5:13 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> You should be able to change reduce the number of messages you see by change
> the log level in conf/config.properties.
Cool! I know due to those same deadlock issues, we were told to
increase the log level. Now we can put it back down, yay!
> How is the URL being constructed? There were some changes in this area. If
> it is being manually constructed or converted to a String then back to a
> URL, then this could be the cause of the issue.
You hit the nail on the head. We have some really poor code (see a
theme here?) that does a Class.getResource(path) for a URL, does a
toString, and then reconstructs the URL. I'll do a rewrite ASAP.
> http://people.apache.org/~pauls/1.2
>
> Probably better for us to try to resolve your issues against this release
> than the last.
We'll give the bundles present at that URL a try.
Pat.
--
Defy mediocrity.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bringing Felix bundles up-to-date.
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Patrick Forhan wrote:
> Long ago, Richard and I were discussing URLs going to and from strings and such:
>
> 2008/9/4 Richard S. Hall <he...@ungoverned.org>:
>
>>>>> - we could no longer load images from a Class.getResource() URL like
>>>>> bundle://56.0:1/org/bjc/pt2/i18n/mock/background.png
>>>>>
>>> Basically, we have an i18n bundle that constructs a Swing ImageIcon
>>> for us, based on a URL. That ImageIcon is passed to other bundles,
>>> but it shouldn't have any trouble loading data from that URL, since it
>>> was created by the same bundle.
>>>
>>>
>> How is the URL being constructed? There were some changes in this area. If it is being manually constructed or converted to a String then
>> back to a URL, then this could be the cause of the issue.
>>
>
> Is there a way to change this? Can I go to a pure string mode back
> into a url? I vaguely think I saw a configuration property along
> these lines.
>
You can go from URLs to Stings and back, but it is generally not a good
idea if you can avoid it (especially if you are constructing a String
first, since this is platform specific). You need URL Handlers enabled
to convert a String to a URL.
-> richard
> Thanks,
>
> Pat.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bringing Felix bundles up-to-date.
Posted by Patrick Forhan <fe...@muddyhorse.com>.
Long ago, Richard and I were discussing URLs going to and from strings and such:
2008/9/4 Richard S. Hall <he...@ungoverned.org>:
>>>> - we could no longer load images from a Class.getResource() URL like
>>>> bundle://56.0:1/org/bjc/pt2/i18n/mock/background.png
>>>
>> Basically, we have an i18n bundle that constructs a Swing ImageIcon
>> for us, based on a URL. That ImageIcon is passed to other bundles,
>> but it shouldn't have any trouble loading data from that URL, since it
>> was created by the same bundle.
>>
> How is the URL being constructed? There were some changes in this area. If it is being manually constructed or converted to a String then
> back to a URL, then this could be the cause of the issue.
Is there a way to change this? Can I go to a pure string mode back
into a url? I vaguely think I saw a configuration property along
these lines.
Thanks,
Pat.
--
Defy mediocrity.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bringing Felix bundles up-to-date.
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Patrick Forhan wrote:
>>> - RepositoryAdmin got set, the removed, then set, which caused an NPE
>>> in one of our declared service classes
>>>
>
>
>> Not sure I have enough information to comment on this. Can you explain it
>> more?
>>
>
> I make no defense of the code (it's terrible, and has been rewritten),
> but I've attached the deployed version. When the RepositoryAdmin has
> been set, it spawns a thread that works with it. However, that
> instance variable gets nulled out by an immediate removeRepoAdmin()
> method call, which then causes the NPE.
>
> Since that's on a whole other thread, it shouldn't have any impact on
> startup, right? Anyway, the real question may be why it is getting
> set, then unset, then set again.
>
Not sure, I will try to look into it. There are also a few changes to
OBR in the next release...
>>> - logging seemed to be going through a mix of PAX-logging and the
>>> default Felix logger
>>>
>
>
>> Well, we were running into some deadlocking issues when Felix was calling
>> out to external Log Services, so for now we disabled that feature since it
>> was causing difficulties for people.
>>
>
> So how do I turn that off? I'm seeing thousands of
> ClassNotFoundExceptions and Missing Resources, that are not errors,
> coming out of Spring and JavaFX and javax.beans and some custom
> bundles... For example:
>
> (scanning all bundles for certain files):
> WARNING: config.txt
> (org.apache.felix.moduleloader.ResourceNotFoundException: config.txt)
> WARNING: bundle.zip
> (org.apache.felix.moduleloader.ResourceNotFoundException: bundle.zip)
>
> (using spring and spring-dm):
> WARNING: org.springframework.beans.factory.xml.NamespaceHandler
> (java.lang.ClassNotFoundException:
> org.springframework.beans.factory.xml.NamespaceHand
> ler)
> WARNING: org.osgi.framework.ServiceReference
> (java.lang.ClassNotFoundException:
> org.osgi.framework.ServiceReference)
>
You should be able to change reduce the number of messages you see by
change the log level in conf/config.properties.
>>> - we could no longer load images from a Class.getResource() URL like
>>> bundle://56.0:1/org/bjc/pt2/i18n/mock/background.png
>>>
>
>
>> Not sure why that would be the case. Again, we probably need more specific
>> details.
>>
>
> Basically, we have an i18n bundle that constructs a Swing ImageIcon
> for us, based on a URL. That ImageIcon is passed to other bundles,
> but it shouldn't have any trouble loading data from that URL, since it
> was created by the same bundle.
>
How is the URL being constructed? There were some changes in this area.
If it is being manually constructed or converted to a String then back
to a URL, then this could be the cause of the issue.
>> I would say upgrading definitely makes sense. You probably even should
>> consider Felix 1.2.0 which is currently under vote for release now.
>>
>
> We'd like to be as up-to-date as possible, as this is a moderately
> painful process for us. How far is 1.2.0 from release?
>
Felix 1.2.0 is being voted on right now, so it should actually be
officially release today/tomorrow, I would assume. It will also include
new versions of OBR. If you want to test these issues against it, here
is the release:
http://people.apache.org/~pauls/1.2
Probably better for us to try to resolve your issues against this
release than the last.
-> richard
> Thanks,
>
> Pat.
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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: Bringing Felix bundles up-to-date.
Posted by Patrick Forhan <fe...@muddyhorse.com>.
I have attached the bundle and a configuration that displays the
RepositoryAdmin problem.... note, I don't think the source I sent
earlier matches up with the stacktrace...
Be sure to point the OBR url to a valid OBR...
Pat.
--
Defy mediocrity.
Re: Bringing Felix bundles up-to-date.
Posted by Patrick Forhan <fe...@muddyhorse.com>.
>> - RepositoryAdmin got set, the removed, then set, which caused an NPE
>> in one of our declared service classes
> Not sure I have enough information to comment on this. Can you explain it
> more?
I make no defense of the code (it's terrible, and has been rewritten),
but I've attached the deployed version. When the RepositoryAdmin has
been set, it spawns a thread that works with it. However, that
instance variable gets nulled out by an immediate removeRepoAdmin()
method call, which then causes the NPE.
Since that's on a whole other thread, it shouldn't have any impact on
startup, right? Anyway, the real question may be why it is getting
set, then unset, then set again.
>> - logging seemed to be going through a mix of PAX-logging and the
>> default Felix logger
> Well, we were running into some deadlocking issues when Felix was calling
> out to external Log Services, so for now we disabled that feature since it
> was causing difficulties for people.
So how do I turn that off? I'm seeing thousands of
ClassNotFoundExceptions and Missing Resources, that are not errors,
coming out of Spring and JavaFX and javax.beans and some custom
bundles... For example:
(scanning all bundles for certain files):
WARNING: config.txt
(org.apache.felix.moduleloader.ResourceNotFoundException: config.txt)
WARNING: bundle.zip
(org.apache.felix.moduleloader.ResourceNotFoundException: bundle.zip)
(using spring and spring-dm):
WARNING: org.springframework.beans.factory.xml.NamespaceHandler
(java.lang.ClassNotFoundException:
org.springframework.beans.factory.xml.NamespaceHand
ler)
WARNING: org.osgi.framework.ServiceReference
(java.lang.ClassNotFoundException:
org.osgi.framework.ServiceReference)
>> - we could no longer load images from a Class.getResource() URL like
>> bundle://56.0:1/org/bjc/pt2/i18n/mock/background.png
> Not sure why that would be the case. Again, we probably need more specific
> details.
Basically, we have an i18n bundle that constructs a Swing ImageIcon
for us, based on a URL. That ImageIcon is passed to other bundles,
but it shouldn't have any trouble loading data from that URL, since it
was created by the same bundle.
> I would say upgrading definitely makes sense. You probably even should
> consider Felix 1.2.0 which is currently under vote for release now.
We'd like to be as up-to-date as possible, as this is a moderately
painful process for us. How far is 1.2.0 from release?
Thanks,
Pat.
--
Defy mediocrity.
Re: Bringing Felix bundles up-to-date.
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Patrick Forhan wrote:
> We're getting ready to roll out a new set of core bundles for our
> application platform... updating to the following:
>
> Felix core 1.0.4
> shell 1.0.1
> bundlerepository 1.0.3
> scr 1.04
> eventadmin 1.0.0
>
> (... and pax-confman and pax-logging)
>
> Everything went pretty smoothly, except for Felix core. We had three
> issues, possibly all related:
> - RepositoryAdmin got set, the removed, then set, which caused an NPE
> in one of our declared service classes
>
Not sure I have enough information to comment on this. Can you explain
it more?
> - logging seemed to be going through a mix of PAX-logging and the
> default Felix logger
>
Well, we were running into some deadlocking issues when Felix was
calling out to external Log Services, so for now we disabled that
feature since it was causing difficulties for people.
> - we could no longer load images from a Class.getResource() URL like
> bundle://56.0:1/org/bjc/pt2/i18n/mock/background.png
>
Not sure why that would be the case. Again, we probably need more
specific details.
> We rolled felix back to 1.0.3 and these problems went away. Is there
> some reason for this? Do we need 1.0.4?
>
I would say upgrading definitely makes sense. You probably even should
consider Felix 1.2.0 which is currently under vote for release now.
-> richard
> Thanks,
>
> Pat.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org