Re: Wicket Felix
Hi Martin, Martin Grigorov wrote: Hi, On Mon, Aug 24, 2015 at 4:06 PM, Jörg Schaible joerg.schai...@swisspost.com wrote: Hi, I am migrating an old Wicket application running in Apache Felix and I wonder how I should register my initializer. According the migration docs I should move and rename the /wicket.properties file to META- INF/wicket/package.properties. However, in Felix I have an URL for this resource like bundle://18.0:1/META-INF/wicket/. This is obviously not supported in Application.collectWicketProperties(). We can make this method protected or add another method where you could plug custom logic. For now, I can return to the deprecated name and location, but I wonder what is the migration path when this support is dropped? Why do you iterate over all existing files anyway, when you stop the iteration at the first occurrence (at least for jar protocol)? The easiest solution would be to look again for a known resource, simply gain the name of the properties file from the current application instance: this.getClass().getPackage.getName() + .properties Because wicket.properties is something like a plugin system. It is not properties of the Application, but properties which may define Application extensions/mixins - o.a.w.IInitilizer. And in case of jar:// URL it stops at the first matching properties resource and ignores the rest. You cannot even control which one is taken. I.e. by using IInitialize any Wicket library could participate in the application start/stop to setup/cleanup whatever it needs. Yes, but the current implementation is not compatible with all kind of classloaders. A Java ClassLoader does not offer a browse functionality, it can only search for stuff with known name. A browsing implementation is simply a hack. Wicket contains now code to support all kind of unusual protocols, e.g. a special one in a JBoss environment. How does the protocol looks like in WebLogic, WepSphere, ...? It fails badly at least in a Felix environment. I wonder why Wicket does not simply use the standard Java SPI mechanism? Everyone could announce his personal initializers just by adding the class names in a resource named META-INF/services/org.apache.wicket.Initializer. Then you can stop making assumptions about the URL. Unfortunately it is not possible to overwrite this behavior now because the interesting methods are either final or private. Patches/PullRequests are very welcome! As long as any 3rd party Wicket library relies on the fact that anything in META-INF/wicket is automatically found, it does not help to overload the functionality. Then I can also stick with the deprecated mechanism. Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Felix
Hi, On Tue, Aug 25, 2015 at 9:20 AM, Jörg Schaible joerg.schai...@swisspost.com wrote: Hi Martin, Martin Grigorov wrote: Hi, On Mon, Aug 24, 2015 at 4:06 PM, Jörg Schaible joerg.schai...@swisspost.com wrote: Hi, I am migrating an old Wicket application running in Apache Felix and I wonder how I should register my initializer. According the migration docs I should move and rename the /wicket.properties file to META- INF/wicket/package.properties. However, in Felix I have an URL for this resource like bundle://18.0:1/META-INF/wicket/. This is obviously not supported in Application.collectWicketProperties(). We can make this method protected or add another method where you could plug custom logic. For now, I can return to the deprecated name and location, but I wonder what is the migration path when this support is dropped? Why do you iterate over all existing files anyway, when you stop the iteration at the first occurrence (at least for jar protocol)? The easiest solution would be to look again for a known resource, simply gain the name of the properties file from the current application instance: this.getClass().getPackage.getName() + .properties Because wicket.properties is something like a plugin system. It is not properties of the Application, but properties which may define Application extensions/mixins - o.a.w.IInitilizer. And in case of jar:// URL it stops at the first matching properties resource and ignores the rest. You cannot even control which one is taken. Yes. We do not expect more than one /META-INF/wicket/.../xyz.properties in a (single) jar https://github.com/apache/wicket/blob/8d23f188e8509e4fae945bbfb9710c489c57423c/wicket-core/src/main/java/org/apache/wicket/Application.java#L517 the break here is only for the browsing in the jar entries, but there is an outer while that iterates over all .jar files. I.e. by using IInitialize any Wicket library could participate in the application start/stop to setup/cleanup whatever it needs. Yes, but the current implementation is not compatible with all kind of classloaders. A Java ClassLoader does not offer a browse functionality, it can only search for stuff with known name. A browsing implementation is simply a hack. Wicket contains now code to support all kind of unusual protocols, e.g. a special one in a JBoss environment. How does the protocol looks like in WebLogic, WepSphere, ...? It fails badly at least in a Felix environment. WebSphere is covered at https://github.com/apache/wicket/blob/8d23f188e8509e4fae945bbfb9710c489c57423c/wicket-core/src/main/java/org/apache/wicket/Application.java#L501 - wsjar. AFAIR WebLogic uses normal protocol - jar. OSGi is designed to cause troubles :-) But I already suggested to make the logic pluggable. I wonder why Wicket does not simply use the standard Java SPI mechanism? Everyone could announce his personal initializers just by adding the class names in a resource named META-INF/services/org.apache.wicket.Initializer. Because this breaks when people use jarjar/uberjar/shaded. And people do use this a lot. Using ServiceLoader is no different than what we have in Wicket 6.x - ClassLoader#getResources(/wicket.properties). Then you can stop making assumptions about the URL. Unfortunately it is not possible to overwrite this behavior now because the interesting methods are either final or private. Patches/PullRequests are very welcome! As long as any 3rd party Wicket library relies on the fact that anything in META-INF/wicket is automatically found, it does not help to overload the functionality. Then I can also stick with the deprecated mechanism. Instead of overload (I think you actually mean override) you could extend the logic. E.g. we can move the error logging at https://github.com/apache/wicket/blob/8d23f188e8509e4fae945bbfb9710c489c57423c/wicket-core/src/main/java/org/apache/wicket/Application.java#L575 to a protected method. So Wicket will let the application to deal with unknown schemes. Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Felix
Hi Martin,
Martin Grigorov wrote:
On Tue, Aug 25, 2015 at 9:20 AM, Jörg Schaible
joerg.schai...@swisspost.com
wrote:
Martin Grigorov wrote:
On Mon, Aug 24, 2015 at 4:06 PM, Jörg Schaible
joerg.schai...@swisspost.com
wrote:
[snip]
Why do you iterate over all existing files anyway, when you stop the
iteration at the first occurrence (at least for jar protocol)? The
easiest solution would be to look again for a known resource, simply
gain the name
of the properties file from the current application instance:
this.getClass().getPackage.getName() + .properties
Because wicket.properties is something like a plugin system. It is not
properties of the Application, but properties which may define
Application
extensions/mixins - o.a.w.IInitilizer.
And in case of jar:// URL it stops at the first matching properties
resource
and ignores the rest. You cannot even control which one is taken.
Yes. We do not expect more than one /META-INF/wicket/.../xyz.properties in
a (single) jar
https://github.com/apache/wicket/blob/8d23f188e8509e4fae945bbfb9710c489c57423c/wicket-core/src/main/java/org/apache/wicket/Application.java#L517
the break here is only for the browsing in the jar entries, but there is
an outer while that iterates over all .jar files.
OK. So what is the role of the initializer registered in wicket-core.jar?
My application uses historically an own one derived from Initializer:
public class WicketInitializer extends Initializer {}
I.e. if the mechanism to detect the Wicket properties file works properly,
this initializer is completely superfluous or even bad.
I.e. by using IInitialize any Wicket library could participate in the
application start/stop to setup/cleanup whatever it needs.
Yes, but the current implementation is not compatible with all kind of
classloaders. A Java ClassLoader does not offer a browse functionality,
it can only search for stuff with known name. A browsing implementation
is simply a hack. Wicket contains now code to support all kind of
unusual protocols, e.g. a special one in a JBoss environment. How does
the protocol looks like in WebLogic, WepSphere, ...? It fails badly at
least in a Felix environment.
WebSphere is covered at
https://github.com/apache/wicket/blob/8d23f188e8509e4fae945bbfb9710c489c57423c/wicket-core/src/main/java/org/apache/wicket/Application.java#L501
- wsjar.
AFAIR WebLogic uses normal protocol - jar.
OSGi is designed to cause troubles :-)
Oh, yes. The old Wicket application sets a ClassResolver in its init method
that has been used to load the initializer ... now Wicket is improved and
the initializer is loaded (with the default ClassResolver) before the
Application is initialized ... boom! I have to overload
WicketFilter.getClassLoader() now. I am curious about other side-effects.
But I get sidetracked here.
But I already suggested to make the logic pluggable.
I wonder why Wicket does not simply use the standard Java SPI mechanism?
Everyone could announce his personal initializers just by adding the
class names in a resource named
META-INF/services/org.apache.wicket.Initializer.
Because this breaks when people use jarjar/uberjar/shaded. And people do
use this a lot.
Using ServiceLoader is no different than what we have in Wicket 6.x -
ClassLoader#getResources(/wicket.properties).
Similar. Just that you can expect that the jarjar/uberjar/shade
implementations at least know about Java SPI and merge the META-
INF/service/* files.
Then you can stop making assumptions about the URL. Unfortunately it
is not possible to overwrite this behavior now because the interesting
methods are either final or private.
Patches/PullRequests are very welcome!
As long as any 3rd party Wicket library relies on the fact that anything
in META-INF/wicket is automatically found, it does not help to overload
the functionality. Then I can also stick with the deprecated mechanism.
Instead of overload (I think you actually mean override) you could extend
the logic.
E.g. we can move the error logging at
https://github.com/apache/wicket/blob/8d23f188e8509e4fae945bbfb9710c489c57423c/wicket-core/src/main/java/org/apache/wicket/Application.java#L575
to a protected method. So Wicket will let the application to deal with
unknown schemes.
This is a possible extension point. However, it does not solve the main
problem, that you have to implement a browse functionality for every
unusual environment on your own. And just by passing a standard Java URL
instance with a bundle protocol is not really helpful ... oh, yes, did I
mention that the ClassResolver is still default ... ;-)
This approach with arbitrary resource names makes IMHO more trouble since it
might prevent to run Wicket in a special environment at all. E.g. the
URLConnection returned by the bundle URL of Felix is a package private
implementation and you would have to access a package private method
Re: Wicket Felix
Just a hint: If you like to use Wicket inside OSGi, maybe https://ops4j1.jira.com/wiki/display/paxwicket/Pax+Wicket might be an alternative instead of doing all things manually. You might also find a hint about the initilizer there... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Felix
Hi, On Mon, Aug 24, 2015 at 4:06 PM, Jörg Schaible joerg.schai...@swisspost.com wrote: Hi, I am migrating an old Wicket application running in Apache Felix and I wonder how I should register my initializer. According the migration docs I should move and rename the /wicket.properties file to META- INF/wicket/package.properties. However, in Felix I have an URL for this resource like bundle://18.0:1/META-INF/wicket/. This is obviously not supported in Application.collectWicketProperties(). We can make this method protected or add another method where you could plug custom logic. For now, I can return to the deprecated name and location, but I wonder what is the migration path when this support is dropped? Why do you iterate over all existing files anyway, when you stop the iteration at the first occurrence (at least for jar protocol)? The easiest solution would be to look again for a known resource, simply gain the name of the properties file from the current application instance: this.getClass().getPackage.getName() + .properties Because wicket.properties is something like a plugin system. It is not properties of the Application, but properties which may define Application extensions/mixins - o.a.w.IInitilizer. I.e. by using IInitialize any Wicket library could participate in the application start/stop to setup/cleanup whatever it needs. Then you can stop making assumptions about the URL. Unfortunately it is not possible to overwrite this behavior now because the interesting methods are either final or private. Patches/PullRequests are very welcome! Cheers, Jörg - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
