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 getLocalURL() to retrieve something usable with file or jar protocol. But Felix is open source, I have at least the chance to look at the implementation. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
