The docs say I can configure the Java 9 platform in JNLP like this:
<j2se version="9" ... />
However if I do so and try to run it using Java 9.0.4 I get a warning saying the requested Java version (9) is not installed. My code:
<j2se version="9" java-vm-args="-Xmx1g" href="http://java.sun.com/products/autodl/j2se"/>
If I do this instead, there is no such popup:
<j2se version="9.*" ... />
But I cannot find such a "*" wildcard in the specs. What is going on?
I found out what's wrong. My example was incomplete, because I did not mention the href attribute I was using in the j2se element.
Solution: In contrast to versions, platforms must be specified without href attributes.
If a platform version is specified (that is, no href attribute is
provided)
https://docs.oracle.com/javase/9/deploy/jnlp-file-syntax.htm
Fixed element (for the example in the question):
<j2se version="9" java-vm-args="-Xmx1g"/>
Related
The problem - I am receiving the following message:
java.lang.ClassCastException: com.ibm.connector2.cics.ECIConnectionFactory incompatible with com.ibm.connector2.cics.ECIConnectionFactory
I am receiving it when trying to make the following statement:
eisDci = (ECIConnectionFactory)ctx.lookup(eisn);
The 'eisDci' has been defined previously:
private static ECIConnectionFactory eisDci = null;
And the 'eisn' is the String with the name of the conection like 'eis/DCIXxxxECI'
These connection is defined in the Server.xml:
<connectionFactory id="DCIXxxxECI" jndiName="eis/DCIXxxxECI">
<properties.cicseci ServerName="XXXX" TPNName="xx" connectionUrl="url" portNumber="2006"/>
</connectionFactory>
I understand that this is warning me that the cast is not possible. What I don't know is what I'm doing wrong. That must be comparing one version of the ECIConnectionFactory class with a different version of ECIConnectionFactory.
The server I'm working with is a Liberty, I'm going crazy, I can't figure out why Eclipse is comparing two different versions.
Similar problems I have searched for:
ClassCastException when casting to the same class
Waxwing's answer seems good, but I don't have access to make those changes, This connection is carried out by an external library.
First Thank you for your answer Ben Cox, in Liberty's server.xml (for LOCAL) I have declared the library:
<fileset caseSensitive="false" dir="C:\CICSECI"/>
And in the Liberty Runtime/Shared/resources I have cicseci.rar which I have declared in the server.xml as a resourceAdapter:
<resourceAdapter autoStart="true" id="cicseci" location="${shared.resource.dir}/cicseci.rar">
<classloader apiTypeVisibility="spec, ibm-api, api, third-party"/>
</resourceAdapter>
I have checked the rest of the libraries that I am importing into the project, and so far I have not seen that I have the repeated library.
I think the issue here has to do with classloading between your resource adapter and your application. This is something we more commonly see with DataSources but the results are the same.
The problem is that the same jar is being loaded by two different classloaders. One classloader for the resource adapter, and another classloader for your application. The solution is to use a commonLibraryRef
<library id=cicseci>
<file name="${shared.resource.dir}/cicseci.rar"/>
</library>
<resourceAdapter autoStart="true" id="cicseciRA">
<classloader commonLibraryRef="cicseci"/>
</resourceAdapter>
<connectionFactory id="DCIXxxxECI" jndiName="eis/DCIXxxxECI">
<properties.cicseci ServerName="XXXX" TPNName="xx" connectionUrl="url" portNumber="2006"/>
</connectionFactory>
<!-- Location of app that is trying to cast ECIConnectionFactory -->
<application location="${shared.resource.dir}/cicseci.rar">
<classloader commonLibraryRef="cicseci"/>
</application>
In this configuration, the cicseci.rar will only be loaded once.
ClassCastException can happen when the same class is loaded by two different class loaders, making what otherwise looks like the same class incompatible.
The mechanism that you should be using to avoid this involves configuring the application's class loader with a classProviderRef to the resourceAdapter, which is documented here. For example,
<application location=...>
<classloader classProviderRef="cicseci"/>
</application>
Already resolved
I import global libraries from different directories of my computer, in two of them the libraries were repeated with different versions, the obsolete versions were renamed, but it doesn't matter, the system recognized them as .jar and loaded them, producing the conflict.
I deleted the leftover libraries and it started working.
You have helped me a lot, and for that, Thank you.
I have a web application currently deployed on Wildfly 23.0.2, using JSF 2.3 and OpenJDK 11.
I'm also using the latest version of OmniFaces (3.11).
One of the application requirements is PWA support. For this, I'm using PWAResourceHandler exactly as described in the omnifaces webpage.
I would like to use the ViewScoped annotation from OmniFaces instead of the one from JSF. I know this OmniFaces-JSF gap is reducing, but for testing purposes I changed the ViewScoped annotation import.
After this change, in all pages with
<f:metadata>
<f:viewParam name="myParam" value="#{omnifacesTest.myParam}" />
</f:metadata>
I get the following error:
Caused by: java.lang.IllegalStateException: Component ID omnifaces_omnifaces_js has already been found in the view.
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.util.Util.checkIdUniqueness(Util.java:1299)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.util.Util.checkIdUniqueness(Util.java:1283)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveView(FaceletPartialStateManagementStrategy.java:453)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.application.StateManagerImpl.saveView(StateManagerImpl.java:64)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.application.view.WriteBehindStateWriter.getState(WriteBehindStateWriter.java:310)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.application.view.WriteBehindStateWriter.flushToWriter(WriteBehindStateWriter.java:204)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:484)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:170)
at javax.faces.api#3.0.0.SP04//javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:132)
at javax.faces.api#3.0.0.SP04//javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:132)
at javax.faces.api#3.0.0.SP04//javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:132)
at deployment.my-application-0.0.1-SNAPSHOT.ear.my-web.war//org.omnifaces.viewhandler.OmniViewHandler.renderView(OmniViewHandler.java:155)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:102)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.lifecycle.Phase.doPhase(Phase.java:76)
at com.sun.jsf-impl#2.3.14.SP04//com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:199)
at javax.faces.api#3.0.0.SP04//javax.faces.webapp.FacesServlet.executeLifecyle(FacesServlet.java:708)
If I remove the viewParam from f:metadata, or disable PWA support, the error disappears.
I can't seem to find a reason for this behaviour.
Has anynone else found this problem? Any suggestions on how to handle this?
Thanks for your help!
I Nugot SpreadsheetLight. To subsequently use it, I need to add the following usings:
using DocumentFormat.OpenXml;
using DocumentFormat.OpenXml.Spreadsheet;
using SpreadsheetLight;
For the first two ("DocumentFormat") to be recognized, I needed to also NuGet Microsoft's "Open XML Format SDK"
I got the latest version of that, 2.5
However, even then, I got an err msg about needing a reference to it:
The type 'DocumentFormat.OpenXml.Spreadsheet.InlineString' is defined in an assembly that is not referenced. You must add a reference to assembly 'DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
This line of SpreadsheetLight code provoked that msg:
sl.SetCellValue("A1", true); // "sl" is an SLDocument
So, I removed the reference that I had NuGot (version 2.6.0.0, Runtime Version v4.0.30319) from my project, and then added back the reference by browsing to C:\Program Files(x86)\Open XML SDK\V2.0\lib and selecting "DocumentFormat.OpenXml.dll"
I then got a compiler Warning:
Found conflicts between different versions of the same dependent assembly. Please set the "AutoGenerateBindingRedirects" property to true in the project file. For more information, see http://go.microsoft.com/fwlink/?LinkId=294190.
I noticed that the DLL I added from the file system was version 2.5.5631.0, and the one that had been NuGot and installed as a reference that way was version 2.6.0.0 The Runtime Version was different, too (v4.0.30319 was installed by NuGetting "Open XML Format SDK", but the version of the DLL I manually added is 2.5.5631.0, Runtime Version v4.0.30319
According to this, I gathered that I should edit the .csproj file by changing <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects> to true - but AutoGenerateBindingRedirects does not exist there.
I don't know whether I should add it, and if so (in which "block"). I prefer to play it safe and assuage the Warning engine. How can I ensure that the OpenXml assembly doesn't cause a conflict?
Assuaging that Warning (so that it rides off into the sunset) is a matter of downgrading the version of DocumentFormat.OpenXML to Version 2.0.5022.0 (Runtime Version v2.0.50727)
I found this out because this code from the "Hello World" example here.
SLDocument sl = new SLDocument();
sl.SetCellValue("A1", true);
. . .
...failed on the first line with, "Could not load file or assembly 'DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies"
And so, since it's expecting version 2.0, I removed my 2.5.5631.0 of that file and then NuGot "OpenXML SDK 2.0" in its stead. That is Version 2.0.5022.0 and Runtime Version v2.0.50727
So: No need to update the project file with an arcane boolean property after all.
It kind of gives me the fantods, though, to have to use an older version of an assembly.
UPDATE
The need to "go retro" with DocumentFormat.OpenXml is corroborated here.
One can solve the problem by redirection of DocumentFormat.OpenXml from Version 2.0.5022.0 to more recent version, for example to version 2.5.5631.0. To do this one should add in web.config the new <dependentAssembly> item:
<configuration>
...
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
...
<dependentAssembly>
<assemblyIdentity name="DocumentFormat.OpenXml" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-2.0.5022.0" newVersion="2.5.5631.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
...
<configuration>
Spreadsheetlight works with DocumentFormat.OpenXml 2.5 since version 3.4.5:
"Version 3.4.5
- SmartTags is now removed from consideration (not so smart now, are you? ;). Which means the code is now ready for Open XML SDK 2.5! And yes, it now works with Open XML SDK 2.5 (have I mentioned that? lol)"
quote from: https://www.nuget.org/packages/SpreadsheetLight/
Im getting started in developing ionic app, I followed the guide in http://ionicframework.com/docs/guide/installation.html
just in case: the command "ionic platform add ios" works and i have android sdk installed.
when typing the command "ionic platform add android" i get this error:
Adding android project...
/Users/LihaiMac/.cordova/lib/npm_cache/cordova-android/3.7.1/package/bin/node_modules/q/q.js:126
throw e;
^
Package name must look like: com.company.Name
Error: /Users/LihaiMac/.cordova/lib/npm_cache/cordova-android/3.7.1/package/bin/create: Command failed with exit code 1
at ChildProcess.whenDone (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/cordova/superspawn.js:131:23)
at ChildProcess.emit (events.js:110:17)
at maybeClose (child_process.js:1008:16)
at Process.ChildProcess._handle.onexit (child_process.js:1080:5)
I tried searching an answer in other related posts, but not successful..
I'll appreciate any help in solving my problem..
What mladen5 said is correct. You need to go to the config.xml of your Cordova/Phonegap project and edit the id to meet the package name expectations.
The name can be found in the ID property and is "com.mydomainhere.appnamehere" in the example config below:
<?xml version='1.0' encoding='utf-8'?>
<widget id="com.mydomainhere.appnamehere" version="0.0.1" xmlns="http://www.w3.org/ns/widgets" xmlns:cdv="http://cordova.apache.org/ns/1.0">
<name>Awesome app</name>
<description>
The worlds most awesome app
</description>
<author email="your#email.com" href="http://www.anurlhere.com">
Author name
</author>
<content src="index.html" />
<access origin="*" />
</widget>
"Package name must look like: com.company.Name" that error is very helpful. You have package name that is invalid, probably starts with number.
Android package rules:
The first character after a period must not be a number
The first character must be a letter or underscore
Usually the app id is your company's reserved Internet domain name.
The app id must consist of letters, numbers, and underscores.
The best way to do it is when you're creating a new app. The Ionic command line interface(CLI) supports two options to do that the right way:
You can also app and package name define using command line interface(CLI) creation you project time like this bellow.
ionic start MyNewApp blank --appname MyNewApp --id com.ionicbyrequest.mynewapp
MyNewApp is my project app name.
Simple, no ? Now when you deploy to stores your id will be unique.
I had the same problem with Ionic a few weeks ago. The problem can be fixed by editing config.xml.
Find the line that starts with
The syntax inside id="" must be com.company.(company name)
ID should be without dashes, just words separated with dots: word.word.word
In your config.xml give the package name according to your project package name
Give widget id in your config.xml as com.test.testapp
I am using SuperDevMode with Chrome and it worked fine until suddently the sourcemaps stopped showing in Chrome.
And CodeServer throws the following exception: Multiple fragment 0 sourcemaps found. Too many permutations.
During compilation it shows:
Compiling 5 permutations
Compiling permutation 0...
Source Maps Enabled
Compiling permutation 1...
Source Maps Enabled
Compiling permutation 2...
Source Maps Enabled
Compiling permutation 3...
Source Maps Enabled
Compiling permutation 4...
Source Maps Enabled
Compile of permutations succeeded
Any ideas?
By default GWT compiles 6 basic permutations, one for each category of browser.
Firefox, all versions
All Webkit browsers (Safari, Chrome, Android Browser, etc)
IE6 and IE7
IE8
IE9 (and IE10)
Opera
There is a reported issue about that: Issue 7458: Super Dev Mode shouldn't compile 6 permutations when user.agent is missing
Suggested workaround from the issue description:
is to restrict the browser permutations in the gwt.xml file. For example, if you are using Chrome or Safari:
<set-property name="user.agent" value="safari"/>
Also if you're using Sencha GXT I also recommend look through the following article: Using the GWT Compiler for Better Builds
According to the article I also added following line to my gwt.xml:
<collapse-all-properties />
So finaly my config for SuperDev mode is the following:
<add-linker name="xsiframe"/>
<set-configuration-property name="devModeRedirectEnabled" value="true"/>
<set-property name="compiler.useSourceMaps" value="true" />
<set-property name="user.agent" value="safari"/>
<collapse-all-properties />
As result GWT compiles only one permutation:
binding: user.agent=safari
binding: compiler.useSourceMaps=true
binding: locale=en
Compiling module com.mycompany.Main
...
Compiling 1 permutation
Compiling permutation 0...
Source Maps Enabled
Compile of permutations succeeded
This can happen if you add locales but do not add the en locale explicitly and/or don't "remove" the default locale and you didn't Dev Mode Off before loading the page in your browser.
For instance, in my module, I had:
<extend-property name="locale" values="fr" />
<set-property-fallback name="locale" value="fr"/>
With this setting, there are 2 locales: fr and default (but the default locale is no longer used, as I override the fallback to fr).
When launching SuperDevMode, it compiles 2 permutations (probably because it forces the locale to en but doesn't actually checks whether such a locale exists in the module).
I had previously launched the app and turned Dev Mode On, but then stopped and restarted the SuperDevMode. When I refresh the page in Chrome, because it's still in dev mode (the state is stored in localStorage), it loads the script from SuperDevMode and tries to load the source maps right away, and this fails as the SuperDevMode compiled 2 permutations and not just one.
Clicking Dev Mode On and Compile forces the SuperDevMode to recompile using the properties from the browser environment (locale=fr here, as it's the fallback). It thus compiles a single permutation and source maps work again.
In my specific case, I needed a single permutation; all I had to do was to add <set-property name="locale" value="fr"/>.
You must be in a similar situation.
I'm sorry that's all the information I can share. Nothing authoritative.