I just wanted to report back and say that, after our installer team updated the distribution to maintain the individual JARs (and thus not overwrite the files with clashing filenames), that solved the problem! Thanks to Martin Grigorov and Andrew Geery for helping point me in the direction of the problem.

Garret

On 10/1/2014 1:04 PM, Garret Wilson wrote:
I think I've found the source of the problem (even though I don't understand the internal details). Our installer creates an uber-JAR that has all the dependencies exploded and then placed inside a single JAR file. I looked inside wicket-extensions-7.0.0-M3.jar, and it has a file wicket.properties /in the root of the JAR file!/ Unfortunately, wicket-core-7.0.0-M3.jar (and likely other Wicket JARs) also have a wicket.properties file in their root as well. As you might guess, these have conflicting values:

initializer=org.apache.wicket.extensions.Initializer

initializer=org.apache.wicket.Initializer

So when we create our uber-JAR only one of these wicket.properties files wins and gets placed in the uber-JAR. The one we happen to have now contains initializer=org.apache.wicket.Initializer.

I will check with the installer team to see if we can distribute the application with all its dependencies as separate JARs rather than an uber-JAR. But on Wicket's side, is it really a good practice to stick some file in the root directory of a JAR, outside of any package, with a name you expect to be identical across JARs but with different contents? I naively would imagine that some better approach exists.

Garret

On 10/1/2014 1:22 PM, Martin Grigorov wrote:
The .properties file is packed inside wicket-extensions.jar, not in his
application.

I have no other ideas but to attach a remote debugger
to org.apache.wicket.resource.loader.InitializerStringResourceLoader#loadStringResource(java.lang.Class<?>, java.lang.String, java.util.Locale, java.lang.String, java.lang.String) and
set condition on the "key" parameter to be equal to the missing resource
key.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Wed, Oct 1, 2014 at 5:55 PM, Andrew Geery <andrew.ge...@gmail.com> wrote:

As a sanity check, is the property file with the property
UploadProgressBar.starting
in the jar file?  Perhaps it didn't get copied over by the Maven build
process into the jar but the IDE was properly copying it over...

Andrew

On Wed, Oct 1, 2014 at 11:38 AM, Garret Wilson <gar...@globalmentor.com>
wrote:

On 10/1/2014 12:33 PM, Martin Grigorov wrote:

Hi,

Do you by chance manipulate the list of IStringResourceLoader's in
DEPLOYMENT mode ?

I don't think I touched anything related to IStringResourceLoader. The
only thing I've done relating to modes is this:

       //turn on Wicket development mode if in debug mode
final String wicketConfiguration = Debug.isDebug() ? "development"
:
"deployment";
       filterHolder.setInitParameter("configuration",
wicketConfiguration);
In other words, in embedded Jetty, if we've started up specifying a debug
mode (using a system variable), then I set the Wicket configuration to
"development"; otherwise, I set it to "deployment".


Garret

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to