We Keep Coding

Tomcat crashes because of native C code - Possible workarounds?

We have a web application hosted on tomcat and it contains calls to some of the legacy C code. Now, on in one of the scenario this C code crashed in production environment and caused the entire JVM to crash bringing the app server down for almost 15 minutes.
Question - Is there a better way to this, basically I want to load the native code in its own JVM so that the app server does not crash.

You answered your own question. Move it to another JVM and then make service calls to that JVM. If the server crashes, communications to the JVM will be lost, but your app server will still be running and can handle the failed communications gracefully.
Your options are, put the code in another app server and create a service API using JSON, Web Services etc, whatever you are more comfortable with. Or, depending on what the C code is doing, maybe just a socket level API.
Of course your C code could handle it's own sockets if you were up to writing that. But keeping it in an App server is probably best for management and monitoring reasons. And it would be quicker and more flexible in creating the API.
You would have to use your judgement as to which is the best solution for you.

We ended up by doing the following:
Moved and exposed the C specific code to a URL endpoint, i.e. RPC style web service (basically a remote call):
#WebService #SOAPBinding(style = Style.RPC)
And subsequently exposing its interface endpoint:
#WebService(endpointInterface..
During web server init published this endpoint Endpoint.publish(...) in a new java process using ProcessBuilder.
When using this, called the endpoint and got the object itself using javax.xml.ws.Service.
During server stop we destroyed the Process created in step 2.

Send PUSH Notification to Android Client from java class on app-Engine

I have the requirement to send a PUSH notification to an android client from my java class. The class has been written using the guidelines provided at the url : http://www.vogella.de/articles/AndroidCloudToDeviceMessaging/article.html (Section 2.4 - Send Messages) This works fine on the standard application servers like JBOSS and Weblogic.
But the application needs to be moved to google app-engine but the class throws a compilation error saying : 'The class javax.net.ssl.HostnameVerifier is not supported by GAE's Java runtime environment'. Similar error is thrown for 'SSLSession' class too.
Is there a way this can be overcome ? Or is there is any other way to send PUSH notifications from Java classes running on the app-engine ?
Thanks,
Vinay

It can't be overcome directly, meaning you can't make those classes run on GAE. As for a solution, I'm not sure why you would want to use a custom HostnameVerifier, so just try without it: use HttpURLConnection instead of HttpsURLConnection and remove all the "hostnameVerifier" parts.
Edit: you can also use App Engine's fetch API, that is supported for sure.

Regarding your question Is there is any other way to send PUSH notifications from Java classes running on the app-engine?, the answer is yes, third party services such as Beaconpush or Spire.io could be integrated well with app engine, and in some cases could be much cheaper in terms of cost compared to using the App Engine Channel API.

The Glassfish Server in NetBeans IDE 6.9.1 stopped working when an attempt was made to display a message box

I'm working with JSF web applications. Since Java doesn't support a direct way to display a message box in web applications, I decided to try something new and thought that the methods which are used to display a message box in conventional desktop applications should be tried out. For the sake of simplicity, I have tried the following method in Java Servlet.
JOptionPane.showMessageDialog(null, "A message from Java Servlet.");
without expecting that it would work but it indeed worked and a message appeared on the web browser! I felt that I had found something new but also found that the Glassfish server in my NetBeans 6.9.1 had stopped working in two or three attempts. It turned off with no warning , no error and no exception at all!
The screen shot can be seen below.
Now, if the use of this method in Java web is illegal, it should not be allowed to use this method at all in Java web and some errors or exceptions should be raised when an attempt is made to do so. It should be a compile-time error and if it is so then, how did the message appear through Java Servlet on the web browser? and also, Why did the Glassfish server stop working?

I have no idea why Glassfish stopped, I guess that it's been caused by dangling Swing/AWT threads in the background. It has always been an extremely bad idea to manually spawn (unmanaged) threads in a lifelong running Java EE webapplication. Once the request finishes, you loses the control. You'd have to collect references to the threads in the session or application scope, preferably in a pool which get properly cleaned up on session or application destroy/shutdown.
But that message is actually not displayed by the webbowser, but by the webserver. This means that your intention will only work when both the webserver and webbrowser runs at physically the same machine. This does obviously not happen when you publish your website into a production environment on the world wide web which get visited by clients using physically different machines.
All the webbrowser retrieves and executes is just plain HTML/CSS/JavaScript. In JSF, you need JavaScript's alert(), confirm(), etc or just some absolutely positioned <div> in an overlay if you want a more fine grained control over the markup and look'n'feel and/or executing managed bean actions. The latter is available in flavor of a single JSF component by a lot of 3rd party component libraries, such as PrimeFaces with <p:dialog> and <p:confirmDialog> and RichFaces with <rich:popupPanel>.
If you really need to run Swing/AWT in a web application for some reason, then you should rather be creating an applet instead and ultimately embed it in your web page by HTML <applet> or <object> tag. This will be downloaded from the server to the client and executed in the client's environment.

Passing on LPTA token on webservices call isn't working

I've got a j2ee web application using j2ee security, so the identity of the user is propagated from WebSEAL to the application, running in WAS7. I'm now trying to make a SOAP webservices call and propogate the user identity in that webservices call. To do this, I grab the LTPA (WSCredential) and LPTA2 (SingleSignOnToken) using the WSSubject calls and attach them to the webservices call using.
bp.getRequestContext().put(Constants.REQUEST_TRANSPORT_PROPERTIES,sendTransportHeaders);
where bp is my BindingProvider. This all should work. But when I make a webservices call, I get back this exception.
Cause =java.io.IOException: Unable to deserialize the Subjects in this Context
I looked at the fields within the LTPA token and all seems right (same realm between the token and the j2ee security realm webservice I'm calling, the token is forwardable, etc), and I cannot find much about this error online, except for (what seems to be an unrelated) case when trying to pass it into the EJB and one case where the realms don't match.
Any ideas? Thanks.

Can you state clearly as to what you are trying to do here?
You should be able to pass the LTPA tokens across transparently with just configuration instead of trying to write some code to achieve the same.
The Web Applications making the Web Service calls to another WebSphere server.
have a quick read at this.
http://www.ibm.com/developerworks/websphere/techjournal/0607_desprets/0607_desprets.html
Things in WAS7 should be very similar to WAS V6.
HTH
Manglu

#jeffsix: are you trying to make a webservice call from application running in one websphere server to another application in another websphere server? Make sure LTPA keys are same on both server.

Making a reliable web service unreliable, but in a controlled way?

I have a Java 6 based web service client using the standard Java 6 annotation based approach (i.e. no Axis or other third party web service library), which works very well. So does the web service I am calling, which is nice, but now I need to write error handling code, and I need to be able to make the existing web service unreliable in a controlled way.
There are many mock frameworks, and they may be helpful, but I don't need right now to be able to mock out the service with prerecorded answers or anything, just introduce unreliability causing the web service library to fail so I can handle the situation gracefully. This would probably be a proxy server running locally.
I work with Eclipse Java EE 3.6, but Netbeans, IntelliJ and JDeveloper are also options.
What would be the best way to do this?

Tcpmon, http://ws.apache.org/commons/tcpmon/index.html can be set up to act as a proxy and even simulate slow connections.
That would give you a chance to simulate both "sorry, not here" and "yes, we are here but we time out".

Any introduced instability is likely to lead to operation avenues of instability being missed. Aim to cover all potential error vectors in your code rather than trying to mitigate for specifics.

Since You've not disclosed enough details of your setup, maybe throwing Exception here and there would be enough?
Seriously, for integration tests like this I'd suggest running some subset of a real web service container.
Based on service's logic it may behave unreliably because of:
external system it is using is misbehaving - try to mock the external system and throw faults - different types - from it
database access problem - try mocking DAO layer and throw Exception from there
general hardware problem - depends :) try to stress your code as you see fit

I think rather than introducing unreliability to a running-instance of the web service application, you are better off simulating error conditions in your unit/integration tests and asserting that your top-layer of the service responds the way that you would like.
For example:
How does the service entry-point respond to a request if the data layer reports that it cannot communicate with the backend (if the data layer throws exceptions, or however it indicates failure)
How does the service entry-point behave if other required components are throwing "unavailable"-like exceptions?
Do you have any timeout logic in place, i.e. the service returns an error if it takes more than X seconds to process the request? If so, this can be simulated in a mock test as well.