You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jan Vermeulen <ja...@isencia.com> on 2007/06/19 15:13:56 UTC
NPE in PropertyResolver.getGetAndSetter()
After downloading the last changes in Wicket 1.3 TRUNK, we have a NPE in
PropertyResolver, due to the fact that there is no HashMap for the current
application. That's because the init(Application) is never called.
Debugging the problem, we found that the wicket.properties resource file
where the Initializer is registered is not correctly loaded:
// Load properties files used by all libraries
final Enumeration resources = getClass().getClassLoader().getResources(
"wicket.properties");
while (resources.hasMoreElements())
{...
In the code above (Application.initializeComponents()), the enum does not
seem to have any elements, although we see that the resource file is
available, and this code has not been changed lately.
So what is happening here ?
Jan.
--
View this message in context: http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11194510
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Jan Vermeulen <ja...@isencia.com>.
I applied the patch, and tested it adding an extra 'wicket.properties' to the
application bundle of an OSGI application. Wicket does correctly detect this
extra resource.
Jan.
Johan Compagner wrote:
>
> Jan,
>
> can you also test this patch and see if that works for you in OSGI?
>
> https://issues.apache.org/jira/browse/WICKET-1371
>
> johan
>
>
>
> On Tue, Jun 19, 2007 at 2:13 PM, Jan Vermeulen <ja...@isencia.com>
> wrote:
>
>>
>> After downloading the last changes in Wicket 1.3 TRUNK, we have a NPE in
>> PropertyResolver, due to the fact that there is no HashMap for the
>> current
>> application. That's because the init(Application) is never called.
>>
>> Debugging the problem, we found that the wicket.properties resource file
>> where the Initializer is registered is not correctly loaded:
>>
>> // Load properties files used by all libraries
>> final Enumeration resources =
>> getClass().getClassLoader().getResources(
>> "wicket.properties");
>> while (resources.hasMoreElements())
>> {...
>>
>> In the code above (Application.initializeComponents()), the enum does not
>> seem to have any elements, although we see that the resource file is
>> available, and this code has not been changed lately.
>>
>> So what is happening here ?
>>
>> Jan.
>> --
>> View this message in context:
>> http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11194510
>> Sent from the Wicket - Dev mailing list archive at
>> Nabble.com<http://nabble.com/>
>> .
>>
>>
>
>
--
View this message in context: http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tp11194510p15950654.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Johan Compagner <jc...@gmail.com>.
Jan,
can you also test this patch and see if that works for you in OSGI?
https://issues.apache.org/jira/browse/WICKET-1371
johan
On Tue, Jun 19, 2007 at 2:13 PM, Jan Vermeulen <ja...@isencia.com>
wrote:
>
> After downloading the last changes in Wicket 1.3 TRUNK, we have a NPE in
> PropertyResolver, due to the fact that there is no HashMap for the current
> application. That's because the init(Application) is never called.
>
> Debugging the problem, we found that the wicket.properties resource file
> where the Initializer is registered is not correctly loaded:
>
> // Load properties files used by all libraries
> final Enumeration resources =
> getClass().getClassLoader().getResources(
> "wicket.properties");
> while (resources.hasMoreElements())
> {...
>
> In the code above (Application.initializeComponents()), the enum does not
> seem to have any elements, although we see that the resource file is
> available, and this code has not been changed lately.
>
> So what is happening here ?
>
> Jan.
> --
> View this message in context:
> http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11194510
> Sent from the Wicket - Dev mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Eelco Hillenius <ee...@gmail.com>.
> Someone has had any problems with loading resources in OSGI ?
I have no experience with it, but I know that plenty of people are
using Wicket + OSGi. Hope they are reading with us?
Eelco
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Jan Vermeulen <ja...@isencia.com>.
It's worse than I thought: I turned back the upgrade, and it seems it didn't
enter in the old code neither.
So the NPE is a consequence of something that went wrong before already
(although we never noticed).
Seems we never got to the Initializer, but we never noticed, since it only
explicitly registered interfaces that register themselves implicitly.
We're running with in Equinox OSGI platform, and the implementation of the
Enumeration returned by the classloader is a 'sun.misc.CompoundEnumeration'.
It seems to have loaded the propertyFile, because it is visible within the
enumeration instance, but the hasNextElement() returns 'false'.
Someone has had any problems with loading resources in OSGI ?
Jan.
--
View this message in context: http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11196540
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Igor Vaynberg <ig...@gmail.com>.
On 6/20/07, Jan Vermeulen <ja...@isencia.com> wrote:
>
>
> It works with the classloader of the current thread, so that's OK.
>
> And yes, I was surprised to find a non-optional initialization like that
> of
> the PropertyResolver to be defined in an Initializer that might not always
> be called.
erm. initializer should always be called, they are non-optional as well
-igor
So 100% correct to move that to an internalInit.
>
> Jan.
> --
> View this message in context:
> http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11212249
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Jan Vermeulen <ja...@isencia.com>.
It works with the classloader of the current thread, so that's OK.
And yes, I was surprised to find a non-optional initialization like that of
the PropertyResolver to be defined in an Initializer that might not always
be called. So 100% correct to move that to an internalInit.
Jan.
--
View this message in context: http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11212249
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Johan Compagner <jc...@gmail.com>.
can't we call the class resolver? for this?
OSGI is supposed to implement this and then the defaults are also better
johan
On 6/20/07, Al Maw <wi...@almaw.com> wrote:
>
> Jan Vermeulen wrote:
> > So my question is now: is that 'wicket.properties' file meant to be a
> > resource that's always within the Wicket 'bundle' ? If so, would it not
> be
> > better to use the latter code to lookup resources, so that it works in
> > environments with multiple classloaders ?
>
> Yes, it will always be packaged in the Wicket JAR file, at any rate.
> What this means in an OSGI environment I'm afraid I don't know. ;-)
>
> > And if it's not that evident where the 'wicket.properties' file should
> > reside, don't you need some utility method for resource loading that
> tries
> > out different classloaders ? Something like:
> >
> > public static URL loadResource(String path) throws
> ClassNotFoundException {
> > try {
> > return
> > (Thread.currentThread().getContextClassLoader().getResource(path));
> > } catch (ClassNotFoundException e) {
> > return
> (getClass().getClassLoader().getResource(path));
> > }
> > }
> >
> > Jan.
> >
>
> Yep, absolutely. I've updated it to use the Thread's contextClassLoader,
> which I think should be sufficient, no?
>
> I've also updated things so that we don't run the PropertyResolver
> init/destroy code in the Initializer, but instead in internalInit() and
> internalDestroy(), as it seems a better place for it to live.
>
> Al
>
> --
> Alastair Maw
> Wicket-biased blog at http://herebebeasties.com
>
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Al Maw <wi...@almaw.com>.
Jan Vermeulen wrote:
> So my question is now: is that 'wicket.properties' file meant to be a
> resource that's always within the Wicket 'bundle' ? If so, would it not be
> better to use the latter code to lookup resources, so that it works in
> environments with multiple classloaders ?
Yes, it will always be packaged in the Wicket JAR file, at any rate.
What this means in an OSGI environment I'm afraid I don't know. ;-)
> And if it's not that evident where the 'wicket.properties' file should
> reside, don't you need some utility method for resource loading that tries
> out different classloaders ? Something like:
>
> public static URL loadResource(String path) throws ClassNotFoundException {
> try {
> return
> (Thread.currentThread().getContextClassLoader().getResource(path));
> } catch (ClassNotFoundException e) {
> return (getClass().getClassLoader().getResource(path));
> }
> }
>
> Jan.
>
Yep, absolutely. I've updated it to use the Thread's contextClassLoader,
which I think should be sufficient, no?
I've also updated things so that we don't run the PropertyResolver
init/destroy code in the Initializer, but instead in internalInit() and
internalDestroy(), as it seems a better place for it to live.
Al
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Jan Vermeulen <ja...@isencia.com>.
I did some new experiments, and I know what is the problem:
The classloader only finds the 'wicket.properties' file, when it's in the
classpath of that classloader. And the classloader used here is:
Application.initializeComponents() {
...
... getClass().getClassLoader()
...
}
So if one has implemented his subClass of Application, it will use the
classloader of that class, which will be normally the classloader of the
webapplication.
Now, if you use Wicket in an OSGI environment, most likely the Wicket
classes (and thus the 'wicket.properties' file) will be in another bundle,
on which your webapplication bundle depends. And each bundle has its own
classloader. So the 'wicket.properties' file has now become invisible.
I made the following small change to the code:
Application.initializeComponents() {
...
... Application.class.getClassLoader()
...
}
And then everything seems to work, because now we're using the classloader
of the bundle in which resides 'org.apache.wicket.Application'.
So my question is now: is that 'wicket.properties' file meant to be a
resource that's always within the Wicket 'bundle' ? If so, would it not be
better to use the latter code to lookup resources, so that it works in
environments with multiple classloaders ?
And if it's not that evident where the 'wicket.properties' file should
reside, don't you need some utility method for resource loading that tries
out different classloaders ? Something like:
public static URL loadResource(String path) throws ClassNotFoundException {
try {
return
(Thread.currentThread().getContextClassLoader().getResource(path));
} catch (ClassNotFoundException e) {
return (getClass().getClassLoader().getResource(path));
}
}
Jan.
--
View this message in context: http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11209399
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Jan Vermeulen <ja...@isencia.com>.
Actually, if I get the resource file (wicket.properties) out of the wicket
jar, and put it direclty in the classpath of the web application, then it is
correctly loaded and processed.
So it's a classloader problem with OSGI.
Jan.
--
View this message in context: http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11199816
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: NPE in PropertyResolver.getGetAndSetter()
Posted by Johan Compagner <jc...@gmail.com>.
does it load through the wrong getClass()?
or the wrong classloader?
that code itself is basic jdk so something else has to be changed.
johan
On 6/19/07, Jan Vermeulen <ja...@isencia.com> wrote:
>
>
> After downloading the last changes in Wicket 1.3 TRUNK, we have a NPE in
> PropertyResolver, due to the fact that there is no HashMap for the current
> application. That's because the init(Application) is never called.
>
> Debugging the problem, we found that the wicket.properties resource file
> where the Initializer is registered is not correctly loaded:
>
> // Load properties files used by all libraries
> final Enumeration resources =
> getClass().getClassLoader().getResources(
> "wicket.properties");
> while (resources.hasMoreElements())
> {...
>
> In the code above (Application.initializeComponents()), the enum does not
> seem to have any elements, although we see that the resource file is
> available, and this code has not been changed lately.
>
> So what is happening here ?
>
> Jan.
> --
> View this message in context:
> http://www.nabble.com/NPE-in-PropertyResolver.getGetAndSetter%28%29-tf3946346.html#a11194510
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>