We Keep Coding

Calling a JAX-WS RI 2.2 service from Tomcat6 with java6

I am trying to access a JAX-WS 2.2 service from Tomcat6 with Java6. For what I have researched there is a problem with this, as Java tries to use first some of its default javax.xml.ws libraries which doesn't have the WebFault.messageName method. So it fails with this error:
GRAVE: javax.xml.ws.WebFault.messageName()Ljava/lang/String;
java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName()Ljava/lang/String;
at com.sun.xml.ws.model.RuntimeModeler.processExceptions(RuntimeModeler.java:1162)
...
The solution seems to be creating an "endorsed" directory in JAVA_HOME/jre/lib/ (or in TOMCAT_HOME) and putting there the required libraries.
However, some people say the library needed is webservices-api.jar, for example, here (#Issue 3):
https://www.fromdev.com/2010/01/trying-to-run-jax-ws-sample-application.html
And other people talk about jaxb-api-2.2.jar and jaxws-api.jar, for example here:
Grizzly - java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName
I have downloaded all three of them and placed them in both directories (inside JAVA_HOME and TOMCAT_HOME).
My problems:
· I have no issues accessing this service from a standalone java6 application, both from Netbeans or running the .jar from command-line, it fails only from Tomcat. So I am not sure if the stated above is the cause of my problems. Because, shouldn't it also fail from command line?
· I am not being able to test the above solutions, because Tomcat does not seem to know the "endorsed" directory. When I run this in the standalone application:
System.out.println(System.getProperty("java.endorsed.dirs"));
It prints:
/usr/lib/jvm/jdk1.6.0_45/jre/lib/endorsed
However, Tomcat prints a blank line.
I have tried to modify tomcat6.conf, with this (and restarting, of course):
JAVA_OPTS="-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -Djava.awt.headless=true -Xms1024m -Xmx1024m -XX:PermSize=1024m -XX:MaxPermSize=1024m"
But it still doesn't seem to know that property.
So, how can I tell Tomcat where the endorsed directory is located? Do you think that my problem can be another than the stated, as it works from a standalone application?

So, the solution:
Do you think that my problem can be another than the stated, as it works from a standalone application?
No, that was exactly the problem.
how can I tell Tomcat where the endorsed directory is located?
It seems that setting this option in tomcat6.conf:
-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed
is not enough. It is required to create a variable called JAVA_ENDORSED_DIRS. So these two lines are needed in tomcat6.conf:
JAVA_ENDORSED_DIRS="/usr/share/tomcat6/endorsed"
JAVA_OPTS="-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS [-Djava....]"
Not really well documented issue, I think.

cassandra 3.5 fails to load trigger class

I am trying to get started with Cassandra triggers, but I cannot get Cassandra to load them. I have built jar files from here and here, and put them under C:\Program Files\DataStax-DDC\apache-cassandra\conf\triggers. I have restarted the DataStax_DDC_Server service (on Windows) and reopened the CQLSH command line, but trying to use the trigger class in a create trigger command gives me only:
ConfigurationException: <ErrorMessage code=2300 [Query invalid because of configuration issue] message="Trigger class 'org.apache.cassandra.triggers.InvertedIndex' doesn't exist">
I checked the jar files, and they include the class files.
The only thing I could find in the log files of cassandra is Trigger directory doesn't exist, please create it and try again. But I don't know if that is relevant.
EDIT: Following the last line shown here, I edited the cassandra.bat file. Now if I stop the DataStax_DDC_Server service and run the bat file directly, the create trigger command succeeds. Nevertheless, the service seems to be independent of this bat file. The question now is how to apply the same config to the service?

After googling creatively, I found a solution. As mentioned here you need to explicitly set the cassandra.triggers_dir variable, but for the service to pick it up, as explained here, you must configure it in the registry. So the answer is to update the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\DataStax_CDC_Server\Parameters\Java\Options
and add the line
-Dcassandra.triggers_dir=C:\Program Files\DataStax-DDC\apache-cassandra\conf\triggers
Note that the path should not be enclosed in quotations, or it won't work.
Don't forget to restart the service.

Above solution is working for window. it's difficult in window to find registry option. so to find registry option go to start menu and type "regedit" it will open registry window then you can do above settings.

Avoid Cassandra 2.1 Warning trigger directory does not exist

Creating a new Cassandra and do a simple insert results in the unexpected warning:
SharedPool-Worker-1] WARN o.apache.cassandra.utils.FBUtilities - Trigger directory doesn't exist, please create it and try again.
Checking the source it seams that Cassandra is expecting a trigger directory (default name 'triggers') to exist.
Since I start a fresh Cassandra every time, I would like to know how I can advice Cassandra to create the triggers directory itself. I do not want to artificially fumble with it.
[update] The Cassandra uses the default main method and is started in the user space. Since during the cassandra.yaml definition the directories for cache, data and third one are created I wonder where to specify the trigger directory or how else it is going to be created.
#close screamers
Having an annoying warning in the logs that should not exist after all is what I consider a bug so please allow this question... . (no offense, just plain stackoverflow begging)

As I learned from the code of the FBUtilities.cassandraTriggerDir method, the property "cassandra.triggers_dir" is read before trying the default trigger directory "triggers". By setting the property to the correct directory (after creation) solved the issue.
The main reason for the problem was first, the triggers directory did not exist at all and second the Cassandra directory is not part of the class path. So there was no way Cassandra could not detect the trigger directory correctly.
So to summaries a cassandra.yaml entry is missing for this issue.
PS: Thanks Bryce for your help!

Do you have a trigger defined on the table you are inserting into, or in your schema? Or did you upgrade Cassandra from a pre 2.0 version?
In any case, the /triggers directory for 2.1 depends on your install type.
For a tarball install, it should be: {install_location}/conf/triggers
For a packaged install, it should be: /etc/cassandra/triggers

Not found exception while doing svn update

I'm having the following situation:
A configuration file (config.cfg) that gets accessed a lot by
different processes.
Config.cfg is under version control - SVN.
I develop and test on a staging environment, when everything is working I go to the server and execute svn up on the config.cfg.
The problem is: During svn up I get an exception by the processes accessing config.cfg: "config.cfg" not found.
It seems that svn causes a short period where the file is beeing replaced and therefore not accessible for my processes.
Any input on how to solve this issue is very much appreciated.

As suggested by ThisSuitIsBlackNot the way to go is to use a semaphor file.
Another solution which just came to my mind is to cache the config file in the process. If it is not there the cached version of the config file is used. As "svn update" doesn't take very long the process will work with cached version until it needs to use the config file the next time.

WebSphere App Server Not Compiling JSP/Tag Libs

This is a problem that only occurs on application update (only tested through Admin Console, not CLI). Also, this is only happening on our development environment, which is identical to our prod env. On uninstall/install, everything is compiled properly. However, this is a large application and it takes long enough to do an update--we do not want to uninstall/install everytime (esp. during dev. builds).
JSP .java and .smap files are being generated, but not .class. On prod, there is no .smap--only .java and .class. If the JSPs would compile, we believe the tag libs would be compiled also.
Has anyone faced this problem, or know what we are possibly overlooking?
WAS Version: 6.1.0.17
EDIT: This is only happening for one JSP and the tag library its using. We're trying to trouble shoot the issue. Let you know if we figure anything out. We think it may be an issue with the .SMAP file per this fix
SOLUTION

Solution:
Problem was: WAS had debugging enabled. This generated .smap files (source mappings) instead of .class files. Once we discovered this, we disabled the debugging service under the Admin Console (Application Servers > server1 > Debugging Processes > uncheck 'Start service'). I don't know why this created a bug upon an update only, but, whatever the case, the problem is solved.

One suggestion:
Have you checked that your environment has a JAVA_HOME pointing to a JDK and not just a JRE. The JRE doesn't have javac, so there won't be any way to compile .java files created at runtime by the JSP compiler into .classes?
EDIT: Also, perhaps this link may help?

I haven't worked with taglibs, but I can tell you this:
the application server checks timestamps. be very very sure that the "modified" timestamps of the JSP files are reasonable from the point of view of the application server (say, are not in the future)
Hope this helps you solve the problem...