I've been assigned a piece of work to investigate and propose a fix for an intermittent and (apparently) non-replicable bug which is causing web service calls to fail with the following error:
Message does not conform to configured policy [ TimestampPolicy(S) AuthenticationTokenPolicy(S) ]: No Security Header found
The application is the Spring based back end for an online public facing high traffic web site. The web services are accessed with a Axis2 1.4 client.
I think I've managed to track the issue down to a possible concurrency issue, but it doesn't seem to be tied to load exactly, the failure statistics don't support it (sometimes days with low load are worse than days with high load).
Anyway, all of client code for the web services is contained within a single class with a #Repository annotation. Classes in the wider application that need access to this WebServiceClient class have it declared at class scope with #Resource annotation where it is autowired in as required.
The problem as I see it is that in the WebServiceClient the stubs are declared at class scope like so:
private ValidationStub validationStub;
private CustInfoStub custInfoStub;
and are initialised in method scope when the web service is called
this.validationStub= new ValidationStub (this.url);
prepareStub(this.validationPort, username, password);
where the prepareStub method creates the security header and adds it as follows:
stub._getServiceClient().addHeader(element);
I think if I move the stubs from class scope to method scope it will solve the issue, like so:
ValidationStub validationStub = new ValidationStub(this.url);
Has anyone ran into a similar issue? I'm a bit concerned that making this change will have a performance impact.
Related
I'm currently creating my own JDBCRealm and more specifically, I'm overriding the Authenticate method. The override was no problem, and I got it to work using SHA authentication.
The problems starting arising when I needed to access a different column that isn't covered by Tomcat's own methods, like getPassword(username) and getPrincipal(username).
I have a Hibernate method that retrieves a user based on their username and it looks like:
UsersDTO user = UsersDAO.getUser(username);
The problem is, that because the code is part of the Tomcat library and not the application, calling the method doesn't work. It throws no exceptions and nothing gets logged to catalina.out, it just presents me with a 500 HTTP error.
I have tried numerous things, but I'm at a loss at the moment. Can anyone shed a light on my problem?
You cannot call classes loaded by the app classloader from classes loaded by the server classloader.
You should deploy your jars in a way that all the invocations are done between classes loaded by the same classloader, or from classes loaded by a lower level classloader to classes loaded by a higher level classloader.
Take a look at this. It's related to Weblogic, but the same concepts apply to Tomcat.
http://docs.oracle.com/cd/E24329_01/web.1211/e24368/classloading.htm
Tomcat is implemented with Apache Commons Logging library. So with proper implementation of that logging library in your code, tomcat should be able to log your error properly.
see reference here
I have embedded Jetty container inside my main server and I also use Jersey 2.5 for handling REST resources.
everything seems to work well and now I would like to pass my server's context class into each of my REST resources.
I'm having hard time understanding how to do that...
If someone can provide full code example - it could be awesome!
Many thanks
What exactly do you mean when you say you have a Jetty container inside your "main server"? Are you programmatically executing Jetty within the application? Also, when you say "context" are you referring to the ServletContext?
Has anyone used GraniteDS successfully with a plain Java client and lazy-loading (a real Java client or a Java server application calling another server)?
Is any special client-side initialization needed? (the docs say nothing about this so we assumed no need, simply took the example code)
Based on the docs (3.0.M2), we have created a Spring backend and a Java client which works for simple POJOs but fails when Hibernate-loaded POJOs would need to be returned (both the RemoteService and Tide versions fail with the same deserialization exceptions).
Currently, we don't have a client-side GraniteDS configuration file, only this code:
String baseURL = "http://localhost:8080/WebApp_Development_Client_Maven/";
URI uri = new URI(baseURL + "graniteamf/amf.txt");
Transport tr = new ApacheAsyncTransport();
tr.start();
AMFRemotingChannel ch = new AMFRemotingChannel(tr, "graniteamf", uri);
RemoteService srv = new RemoteService(ch, "userService");
List users = (List)srv.newInvocation("listUsers").invoke().get().getData();
The de-serialization exception:
Caused by: java.lang.RuntimeException: The ActionScript3 class bound to limes.core.model.security.User (ie: [RemoteClass(alias="limes.core.model.security.User")]) implements flash.utils.IExternalizable but this Java class neither implements java.io.Externalizable nor is in the scope of a configured externalizer (please fix your granite-config.xml)
at org.granite.messaging.amf.io.AMF3Deserializer.readAMF3Object(AMF3Deserializer.java:500)
at org.granite.messaging.amf.io.AMF3Deserializer.readObject(AMF3Deserializer.java:130)
at org.granite.messaging.amf.io.AMF3Deserializer.readObject(AMF3Deserializer.java:92)
... 36 more
Context:
We have a client-server Java/Swing application that was originally designed for intranet use (utilizes Hibernate 3 as the ORM). It also works through the internet but the PostgreSQL database connection very often breaks which makes the client unreliable (random freezes due to lost/broken db connection). This seems to be impossible to solve correctly (the easy measures like manual re-connection is already implemented)
We need to deploy the app over the internet and since the complex logic is already refactored into service classes we would like to leave the GUI mostly unchanged and remote the service classes. We are moving the persistence layer and the service classes into a Spring backend and would like to use GraniteDS because transparent lazy-loading is heavily utilized in the application so it would be very hard to replace it with DTO usage and/or Initializers.
I have not found plain-Java client examples, only a JavaFX example app which is so heavily tied to JavaFX that it seems very hard to transform into a plain-Java client (even trying it out is slightly problematic on Linux since it has no Webstart config included).
It seems that lazy-loading doesn't work in this version of GraniteDS (3.0.0.M2) with the plain-Java client.
https://groups.google.com/forum/#!topic/graniteds/KDWNY31lG0I
In theory, it works in the JavaFX environment but it was implemented in a way that plain-Java clients cannot use transparent lazy loading.
Also, GraniteDS doesn't support lazy-loading on single entities, only on collections which makes it unsuitable for projects using such relations. Personally, I think this is a glaring omission especially since they often refer to their lazy-loading support as "full".
Unfortunately, the documentation doesn't say anything about the lazy-loading limitations and also fails to make the distinction between the capabilities of GraniteDS with JavaFX and plain Java.
When I publish a web service created from a WSDL, the WSDL which is created after publishing is different than the original one. The difference is that WSDL/XSD created after publishing had additional element(ARG0) which wraps all root elements.
Because of the reason above, I could not share original WSDL/XSD to client developers since original WSDL and the one created after publishing is not same.
I am using Java as a programming language and JAX-WS.
using API javax.xml.ws.Endpoint to publish the web service without needing any Application server.
Endpoint.publish(url,webserviceinstance)
Thanks in advance.
Since the problem is unneccesary wrapping issue, I focused on wrapping annotations. Eventually I have found out that there is a related annotation for this issue. After adding following annotation statement at the beginning of Class ,problem has been solved.
#SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.BARE)
public class WebServiceHandler implements WebService {
//....
}
From now on, I can make succesfull request created from original WSDL to deployed machine.
If you post the wsdl, a better assessment can be made. Given that you are seeing an unexpected wrapper, my guess is that jax-ws is interpreting your original wsdl differently than you intend. The page here (http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/) discusses different wsdl configurations. My suggestion is that you follow the instructions for using the document/literal/wrapped convention as it is more or less in the mainstream for soap-based services.
The resulting published wsdl will still likely be a little different in terms of service name, port name or namespace unless you use the #Webservice annotation attributes to force these to particular values, but they will be consistent such that you can provide the published wsdl to your clients and expect success.
The most common reason for this type of issue is that the class implementing the Web service doesn't have an #WebService annotation with the correct endpointInterface attribute. In fact, it is not sufficient to implement the endpoint interface generated from the WSDL.
I'm mantaining a EJB 2 CMP legacy app runing on a JBoss 4.0.4 GA application server with deployed entity/stateless session beans. All the EJB boilerplate code is generated via XDoclet from the EntityEJB/EntityEJBManager annotations.
I've noticed that when my GUI client invokes the facade create method, I have lots of cases of EJBException in my server log with the "Reentrant method call detected" message, which rollbacks the transaction.
What does this Exception means? How can I avoid having such error (which unfortunately, I wasn't able to reproduce yet)
Update: Found this link that explains what is meant by reentrancy, however, seems to me that it says my app cannot be accesed concurrently?
I've seen this before where EJB1 calls EJB2 which calls back to EJB1 within the container as part of the same transaction.
You can tell the container to allow this by marking EJB1 as reentrant which will allow it to be accessed multiple times in the same transaction.
This is done in the deployment descriptor with the following tag:
<reentrant>True</reentrant>
There should be a corresponding EntityEJB annotation that XDoclet can use to generate this for you.
we just came across the same problem and our solution was two-fold. Firstly we ensure that none of ejb's had transaction attributes of NotSupported within our ejb-jar.xml. We then used "instance per transaction" as our optimistic locking strategy. It's a bit of a belt-and-braces approach, but it works
It does mean that the Entity bean in question cannot be accessed concurrently, which makes sense since it would likely corrupt the data.