This question already has answers here:
With Java 7 Update 45, the System Properties no Longer Set from JNLP Tag "Property"
(5 answers)
Closed 9 years ago.
With the new Java 7 update 45, we are not able to set properties. We used to set it as follows
<resources>
...
<jar href="xxx.jar"/>
<property name="xxx.xxx.xxx.xxx.userName" value="Batman"/>
<property name="xxx.xxx.xxx.xxx.locale" value="en_US"/>
...
</resources>
We tried the work around, tried the following
<resources>
...
<jar href="xxx.jar"/>
<property name="jnlp.xxx.xxx.xxx.xxx.userName" value="Batman"/>
<property name="jnlp.xxx.xxx.xxx.xxx.locale" value="en_US"/>
...
</resources>
even tried "javaws." added as prefix.
Problem is we that we want to avoid making change in the codebase and want to fix the issue in the jnlp level.
Do we have any other work around or any ideas?
According to this OpenJDK bug report (https://bugs.openjdk.java.net/browse/JDK-8023821) there are three possible workarounds:
Sign the jnlp file.
Use either a signed-jnlp file (JNLP-INF/APPLICATION.JNLP) or a signed jnlp template (JNLP-INF/APPLICATION_TEMPLATE.JNLP).
Use secure properties.
Change all the properties in the jnlp file to pre-pend "jnlp." to the property name, and modify all code to use the new properties name.
Use secure properties and translate them in the main of your signed application to insecure properties.
Change jnlp files to have the property names in the jnlp file pre-pended with "jnlp.myapp.", then in your application read the system properties and for each property starting with "jnlp.myapp." set the corresponding property without the "jnlp.myapp." pre-pended to the name.
It sounds like 2 and 3 are not what you want. So that leaves you with option 1. (Or accept that you need to change your codebase.)
Related
I am working on a small JSP project...and I want to add a configuration that is mentioned here : https://openliberty.io/docs/latest/reference/config/jspEngine.html
Specifically, i want to add keepGenerated ="true"
2 questions:
Is the location of this config corect? I just placed it inside the server element (not clear to me from the link from above if the location is good)
<server description="My Project">
<featureManager>
<feature>servlet-5.0</feature>
<!-- needed to run JSP examples -->
<feature>pages-3.0</feature>
</featureManager>
<jspEngine keepGenerated ="true"/>
....
</server>
Where will the java files corresponding to the JSP files be generated? I want to see the java code that is generated...
By adding the property from question 1, I was unable to find the java files generated for the JSP file....I tried to run also a search but no use..I assume that the configuration might not be correct..
Thx!
I maintain an Eclipse RCP application launched with WebStart. Java 7 u45 made some security changes, and now my application crashes on startup.
I've added to the manifest:
Permissions: all-permissions
Codebase: *
Trusted-Library: true
This removed all of the warning messages from the Control Panel. But I still have a classloader issue when trying to load my IApplication implemenentation, probably the first of my classes to load. This is new to update 45.
I have experienced the same issue and managed to solve it by doing following:
In all manifest files (for each JAR in your RCP project) add these attributes:
Application-Name: My App Name
Permissions: all-permissions
Codebase: *
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Trusted-Library: true
Second part of solution is to make jnlp properties secure by adding jnlp prefix. I have found solution here. You need to do this for framework properties (osgi, eclipse..) and for your properties E.g. instead of:
<property name="eclipse.product" value="com.amdosoft.oct.ui.product"/>
<property name="osgi.instance.area" value="#user.home/Application Data/myApp"/>
<property name="osgi.configuration.area" value="#user.home/Application Data/myApp"/>
<property name="my.App.property" value="someValue"/>
use
<property name="jnlp.eclipse.product" value="com.amdosoft.oct.ui.product"/>
<property name="jnlp.osgi.instance.area" value="#user.home/Application Data/myApp"/>
<property name="jnlp.osgi.configuration.area" value="#user.home/Application Data/myApp"/>
<property name="jnlp.my.App.property" value="someValue"/>
Download eclipse launcher with sources from here
In web start launcher you need to change back property names to old values (without jnlp prefix). You can do that by adding this part of source into main method of WebStartLauncher class.
Properties properties = System.getProperties();
// copy properties to avoid ConcurrentModificationException
Properties copiedProperties = new Properties();
copiedProperties.putAll(properties);
Set<Object> keys = copiedProperties.keySet();
for (Object key : keys) {
if (key instanceof String) {
String keyString = (String) key;
if (keyString.startsWith("jnlp.")) {
// re set all properties starting with the jnlp-prefix
// and set them without the prefix
String property = System.getProperty(keyString);
String replacedKeyString = keyString.replaceFirst("jnlp.", "");
System.setProperty(replacedKeyString, property);
}
}
}
Export you new launcher as runnable JAR and put it in the same directory where your JNLP file is located.
Edit JNLP file by adding this line:
<jar href="myAppLauncher.jar"/>
inside tag and edit your application-desc tag like this:
<application-desc main-class="org.eclipse.equinox.launcher.WebStartMain">
</application-desc>
When 7u25 came out, my application would crash with a classloader issue (sometimes, it was weird). The fix involved nixing my "Components.jnlp" deployment strategy. I had my library files in a separate .jnlp (Components.jnlp, as per a solution I read online back in 2010) and my main .jnlp (launch.jnlp) would load that .jnlp.
Now, it seems the Netbeans-generated .jnlp is sufficient and I no longer need any separate .jnlp for library components. I'm not sure if eclipse gives you an auto-generated .jnlp or not.
In the end, changing the launch.jnlp involved me having to give my clients a new installer that would load the new .jnlp onto their computers. It sucked but it worked.
Also, I'm not sure what Codebase: * is supposed to do. Why don't you just put your actual codebase in there?
If you did not deploy your app with that approach then this answer probably won't help. Might help somebody.
We've had multiple JNLP files up until now, and it seemed to work.
We install our app on customer internal networks, so we can't set a codebase other than * without resigning the entire set of jars for each customer.
I'm working in a Java Web Project.
I need to change the folder of the files "jdbc.properties" and "log4j.properties" depending of the environment, because testing, demo and release have diferent values for those files.
I have this folders and subfolders:
c:\myProject\conf\dev
c:\myProject\conf\test
c:\myProject\conf\demo
I need to put diferent jdbc.properties and log4j.properties files in each of those folders
c:\myProject\conf\dev\log4j.properties
c:\myProject\conf\dev\jdbc.properties
c:\myProject\conf\test\log4j.properties
c:\myProject\conf\test\jdbc.properties
c:\myProject\conf\demo\log4j.properties
c:\myProject\conf\demo\jdbc.properties
The three project are in the same Server and in the same Apache (It is a Web Project)
First i made some changes to use a windows system variable to get the parent folder (c:\myProject). To do that, i made this on Spring appContext file:
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<value>file:${PARENT_FOLDER}/conf/dev/jdbc.properties</value>
</property>
</bean>
"PARENT_FOLDER" is defined on Windows environment variables/system variable
Those changes works OK.
But, as you can see, I always loking for file on "/conf/dev"
I need to make dynamic the "dev" part of the path.
I Can't use Windows environment variables/system variable because the 3 environments are deployed on the same Server.
I'm trying to use a "property" (using ) on web.xml, but I don't know how to find the property in my Spring appContext file.
I definy the property like this:
<env-entry>
<env-entry-name>ENVIRONMENT</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>Dev</env-entry-value>
</env-entry>
But I don't know how to access "ENVIRONMENT" property on Spring
I don't know what to do. I a little desperate
Can someone help me?
Thanks and sorry for my poor english
Have you considered using JNDI?
With JNDI you will define the db connection properties inside tomcat itself. This way your spring configuration is independent of the environment and you can deploy the same war on all environments. See also this.
If you need to run it locally that you can always use the 'new' spring environment profiles feature.
Other option (if JNDI is not an option and assuming you use maven) is the maven replacer plugin where you will generate the db.properties at build time.
I need to be able to build two different versions of my GWT application using two different sets of property values. For example, one version would be built with the value of custom_property set to "A" and another would be built with the value of custom_property set to "B".
Currently I am editing the application's module XML file in between builds by hand. So, to make one build I would first add:
<set-property name="custom_property" value="A"/>
And to make the other build I would change this line to:
<set-property name="custom_property" value="B"/>
This approach is working okay, but I would like to automate it if possible.
Is there a good way to accomplish this?
One powerful way to do this would be using Maven substitution. I've used this approach in many GWT- and non-GWT-based apps. Due to Maven's prevalence, you'll find loads of examples of Mavenizing your GWT app. Then you can use Maven substitution to make all the magic happen.
You can clone your app's module XML file and change values of your custom properties in it (e.g. MyAppStaging.gwt.xml and MyAppProd.gwt.xml). You'll thus be able to script builds of different app versions and have different run configurations in your IDE. The drawback here is in subsequently needing to maintain both module XML files.
Building on #BorisBrudnoy's idea of multiple module XML files, I placed all module XML that was not related to setting the properties that differ between builds in a MyAppBase.gwt.xml file. I then created MyAppA.gwt.xml with:
<module rename-to="myappA">
<inherits name="com.mycompany.MyAppBase"/>
<set-property name="custom_property" value="A"/>
</module>
and MyAppB.gwt.xml with:
<module rename-to="myappB">
<inherits name="com.mycompany.MyAppBase"/>
<set-property name="custom_property" value="B"/>
</module>
Now I can specify either com.mycompany.MyAppA or com.mycompany.MyAppB on the GWT compile command line, and there is no replication of configuration.
I have this in my build.xml:
<target depends="build-jar" name="proguard">
<taskdef resource="proguard/ant/task.properties" classpath="tools/proguard4.6/lib/proguard.jar" />
<proguard configuration="ant/proguard.conf" />
</target>
It works fine.
Inside the configuration file (i.e "ant/proguard.conf") I'm trying to access properties defined in this build.xml file but I'm always getting this kind of error:
Value of system property 'jar.final_name' is undefined in '<jar.final_name>' in line 1 of file '.......\ant\proguard.conf'
The error is clear. Question is how I do what I'm trying to?
If I'd do it the "Embedded ProGuard configuration options" way I could use these properties like any other property in build.xml, but I'm trying to keep the files separate.
How do I do that then?
By default, Ant doesn't provide a way to set java system properties for its tasks. You can only specify -D options in the ANT_OPTS system variable when starting Ant itself.
I'll consider supporting the use of Ant properties in referenced ProGuard configurations (being the developer of ProGuard).
For the time being, an acceptable solution might be to specify input and output jars in Ant's XML-style:
<proguard configuration="ant/proguard.conf">
<injar name="${injar}" />
<outjar name="${outjar}" />
<libraryjar name="${java.home}/lib/rt.jar" />
</proguard>
This part of the configuration is more closely tied to the Ant script anyway.