I'm trying to start my JBoss v4.2 server in Eclipse, but I'm getting some exceptions. Here's the log. Any clues what the problem might be? The only file the log lists is the jboss-service.xml file, and I don't see any problems with that.
So, the problem is that my java.security file points to a nss.cfg file which contains a ~ in it as follows:
nssLibraryDirectory = C:\PROGRA~2\Java\jdk1.6.0_32/bin
I could change that to C:\Program Files (x86)\Java\jdk1.6.0_32/bin, but it doesn't like parenthesis either. So I have to find some way to link to the folder without having any parenthesis or tildes.
Solved my problem for now. I copied the bin folder to a folder without any special characters (C:\javabin). A hopefully temporary solution.
The error is described here:
Caused by: sun.security.pkcs11.ConfigurationException: Unexpected value Token['~'], line 2
at sun.security.pkcs11.Config.excToken(Config.java:339)
It looks like you need to use XML code to represent the ~
Can you post the XML configuration?
Using an XML generated file (with freemarker) with CDATA tags will escape properly these characters.
It must work. I know it could be heavy at the first time, but you will do this one time per server implementation, and run it as much as you need these server implementation e.g. jboss 4.2.2 GA...
XML encoding is good too, but your XML file is not really human-readable after that.
To think about generated file, you could take the default jboss-service.xml and build it as a template jboss-service.ftl and you can generate it as many time you need a configuration update.
I think you could encode XML chars on the fly with freemarker too with the method to_xml("name",object) and look at Build-ins for Nodes (XML)... if you choose these way to go.
Related
I am simply trying to analyze all of the java files located inside the src directory, but I can't get this working.
The sonar-scanner configuration file I have added is :
sonar.projectKey=three
sonar.projectName=three
sonar.projectVersion=1.0
sonar.sources = C:/Users/Michael/Desktop/x/y/src
sonar.inclusions = C:/Users/Michael/Desktop/x/y/src/**/*.java
I have also tried brute forcing many combinations such as
sonar.projectKey=three
sonar.projectName=three
sonar.projectVersion=1.0
sonar.sources = C:/Users/Michael/Desktop/x/y/src
sonar.inclusions = src/**/*.java
I keep getting told when running that "39 files ignored by inclusion/exclusion patterns", why is it being ignored?? What am I missing here.
Also, how do the examples even work when starting with src/*, how does it even know what src they're referring to or where it is located?
There are a couple things going on here
First, paths in your analysis properties should be relative to your project root. So, not sonar.sources=C:/... but (guessing here) sonar.sources=y/src or more probably sonar.sources=src. Why does this work? Because you cd into your project root before running analysis.
This path confusion probably explains why your inclusion isn't working. However you don't need to set an inclusion if you simply want to analyze the files in src; all you need to do is properly set your sources path & the analyzer will do the rest.
One last thing: your first three properties have no spaces around the =, but your paths do. To be safe, you should omit them, for:
sonar.projectKey=three
sonar.projectName=three // note that this will default to key if omitted
sonar.projectVersion=1.0
sonar.sources=src
IBM Cognos generates EAR file which includes a lot of JARs in /WEB-INF/lib/
Of those JARs, a few (namely, idvisualizations_helpers.jar and some others) in their /META-INF/MANIFEST.MF contain the following:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: jvmwi3260sr10-20111207_96808 (IBM Corporation)
Main-Class: ${project.main.class}
Class-Path: ${relative.classpath}
Is this valid? I mean, who will be responsible for expanding those {} placeholders? To me this does not even make any sense: if software executing the JAR knows its main class, there is no reason to mention it in Manifest.
I can only think of two explanations. First, this is a plain and simple bug, a failure to substitute those placeholders when making a JAR. Second, such a notation is valid and assumes that the JVM using that JAR will provide values for those placeholders (but I don't believe in this, as specifying different value for each such JAR would be too inconvenient).
Someone please explain what does that mean. More practical part of the problem is that on Websphere Liberty 8.5.5 an error is produced because of "${relative.classpath}" not being a valid URI. I wonder why that does not happen on another environment running full Websphere (though the Cognos configuration there differs from mine).
No, having properties in your final manifest that is used by the Java JVM is not valid based on the Java specifications. When I say "final" I mean you might have properties in your manifest as part of your source code which are then filtered out during the build and replaced with the values of those properties. This is perfectly fine. Another possibility is that there may some post-build processing that replaces those properties with the correct values.
You said:
...on Websphere Liberty 8.5.5 an error is produced because of "${relative.classpath}" not being a valid URI. I wonder why that does not happen on another environment running full Websphere (though the Cognos configuration there differs from mine).
I'm not quite clear on what you meant with that last part about the Cognos configuration differing from yours, but it sounds like you're saying that the manifest you showed in your question is working on one platform but not on another. I would imagine that either one platform is performing post processing or the two platforms have different deployed code somehow. I suggest going back and confirming that you have the exact same manifest in both platforms and debug your build process to try to find where those variables' values are obtained and when.
Please see this link for more information about the manifest file.
I have following conf files in my play2.1.0 application
application.conf
override.dev.conf
override.qa.conf
override.prod.conf
And there is a application.mode property in the application.conf file which will have either one of dev/qa/prod values.
application.conf also has a line to include env/mode specific conf files as override. This is what is not working with substitution.
Reason:
To have the override properties in the env/mode specific conf files.
Referred:
http://www.playframework.com/documentation/2.0/Configuration
If an unquoted include at the start of a key is followed by anything other than a single quoted string, it is invalid and an error should be generated.
No substitutions are allowed, and the argument may not be an unquoted string or any other kind of value.
Tried:
Able to get the substitution done for another property but not for include like this
my.prop="override."${?application.mode}".conf"
The above outputs to override.dev.conf if application.mode=dev
If I have something like below its not working and i suppose its what is expected as per the documentation reference.
include "override."${?application.mode}".conf"
Expected the above to include/override props in a file named override.dev.conf
Question:
Should this be a future enhancement or this is what is expected out of it?
What are the other ways to implement what I wanted?
Any help would be really appreciated.
I prefer to override the GlobalSettings.onLoadConfig as described in PlayFramework 2 load different config according to current mode. It is done in Scala but it should be possible to do in Java as well.
It lets you overload configurations in a very nice way without the need to start the application with command line arguments, you still start the app with play run, play start, etc.
You should be able to use this method if you change your override.qa.conf to override.test.conf since qa is not a known mode in Play.
All shared settings in the application.conf and then override in the other ones.
We wanted to do something similar and the only way we got it to work was to reverse it.
In each environment we have a main-config.conf that has all of the configuration specific for that environment. Basically, what you are calling your override.[env].conf. The first line in each of those files is includes "application.conf" to merge in the default configuration for the application. So, application.conf has the general project configuration and the other files have the stuff specific to the environment.
To start your app you just tell it to use the environment-specific config file.
play -Dconfig.file=/path/to/main-config.conf start
The application will load main-config.conf which, in turn, includes the default application.conf from the project.
We actually also modify the build shell script (in the /framework directory, I believe) so it always specifies that config file parameter. That way we don't have to type that in when we're developing.
I need to transform one XML document into another using XSLT (for now from command line). I have to use Java 1.4.2. Based on that someone recommended using Saxon and provided the XSLT. It seems simple it should work, but I am lost.
I come more form a .NET environment, and have worked with XML and XSLT but not with Saxon and I am not that strong in Java.
Let me start by explaining what my problem is and what I have tried so far:
The Error:
C:\Projects\new_saxon_download>java net.sf.saxon.Transform -s:source.xml -xsl:style.xsl -o:output.xml
Exception in thread "main" java.lang.NoClassDefFoundError: org/xml/sax/ext/DefaultHandler2
at net.sf.saxon.Configuration.(Configuration.java:2047)
at net.sf.saxon.Transform.setFactoryConfiguration(Transform.java:81)
at net.sf.saxon.Transform.doTransform(Transform.java:133)
at net.sf.saxon.Transform.main(Transform.java:66)
Steps that led me here:
I downloaded Saxon-B by following a link from this page
I also found some information on a dependency about SAX2 from this
page and thus obtained that as well.
Set the CLASSPATH in my session:
set CLASSPATH=.;C:\Projects\new_saxon_download\saxon9.jar;C:\Projects\new_saxon_download\sax2r2.jar
Tried the transformation:
java net.sf.saxon.Transform -s:source.xml -xsl:style.xsl -o:output.xml
Then I get the error shown above. I have tried multiple google search, but nothing has helped.
Any advice or solution would be very helpful.
GOT IT - the description on how to fix the dependendcy issue is crap (sorry).
This file sax2r2.jar isn't the one you have to add to the classpath. It contains another jar (sax.jar) and that's the library you actually need. Just extract the sax2r2.jar and put sax.jar on the classpath, then it should work.
Give this a try: apache xml-commons includes xml-api.jar. I can't tell if this is usable with java 1.4.12 but it's worth a try.
Binary releases can be found here. Download one of the xml-commons-external archives, extract xml-api.jar and add that to your classpath.
I am writing a Java applet and embedding it in a web page.
It used to run Mac and Windows in different browsers without problem.
I was using NetBeans on the Mac to build the .jar file the applet used.
For some reason or another I decided to load the project on the Windows' NetBeans - I started getting the following error on the Windows machine when accessing the web page from any browser:
java.lang.ClassFormatError: Incompatible magic value 1008813135 in class file
Fearing that it must have been my decision to open the project on Windows that caused this error - I tried to build from the Mac's NetBeans - but the error persisted.
I started a while new project on the Mac and imported the existing source code: still same problem.
I was doing some reading about this error and it seems that the magic number expected is 0xCAFEBABE in hex which is 3405691582 in decimal, not 1008813135. So it looks like the Mac version of Java doesn't produce this file header any more? Hoe can that be? I didn't do any updates or anything.
Yes, 0xCAFEBABE is the usual first 4 bytes of a Java file.
1008813135 is <!DO in Latin encoding, which is, in all probability, the start of <!DOCTYPE....
It is therefore likely the start of a 404 error, or some other error page.
I have not experienced this problem, but Googling this error yields several possible solutions:
forum.sun.com - Java Applet Development - Incompatible magic value 1008813135 in class file MyApplet
Thanks God the problem is solved.
Its the Java cache, so the solution go to Java Control Panel, "General" tab, and under "Temporary Internet Files" click "Settings", then click "Delete Files". Try using the applet again.
"Incompatible magic value 1008813135" Error?
The problem is now solved: I found out that the website host I was using didn't support .jar files at all. I mass-uploaded the files with my ftp program and didn't notice that it ignored the .jar files completely.
Errors on java initialization
Alright, so it was an apache configuration issue, removed this line from my httpd.conf file:
# DefaultType application/x-httpd-php
Fixed the issue.
If you are using Spring security or some sort of custom Servlet Filters, make sure, that the archive or codebase location is in "permitAll" access. This was to problem in my case
I was facing the same problem.The reason in my case was all dependency library that Applet uses was not signed and also applet not able to locate them.
So i Have added all the dependent library along with main applet in jsp file like below :
app.archive = '/esense/resources/lib/Applet.jar, /esense/resources/lib/jasypt-1.7.jar, /esense/resources/lib/mysql-connector-java-5.1.30.jar, /esense/resources/lib/runtime-api-1.0.jar';
I have also signed all the jar.
Hope this may work in your case.
The incompatible magic number is the first four bytes of a html file that has some error message in it, probably a message that the file isn't found.
I encountered this phenomenon when I didn't take case sensitivity into account in the codebase element of the applet tag. Things worked well on Windows, but the internet server I was using was running UNIX where filename case sensitivity is important. Making the case of all file and directory names in the code and codebase elements solved the problem.
I just clicked on maven->update project->include snapshot release in my spring boot and it worked.