I’m using Jboss 5, and invoking hundreds of EJBs with complex parameters.
There are some performance issues that I think are related to Java Serialization
As Jboss using JbossRemoting for remote invocations, I would like to use JbossSerialization to optimize serialization performance.
Like explained here, I'm using
-DSERIALIZATION="org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager"
at server side and in invocation code.
But JavaSerializationManager is still used by Jboss.
Can someone explain or exemplify how to configure JBOSS for using JBossSerializationManager.
In other words, what is the easiest way to make already deployed EJB application using Jboss Serialization instead of java Serialization?
This is confusing because JBoss remoting is a component that is used by JBoss Server. If you were using JBoss Remoting standalone that works (sort of). JBoss Server has its own set of config files.
For EJB3 calls you will need to update the InvokerLocator connection string in the location defined here. It looks something like below...
socket://myhost:6500/?datatype=test&loaderport=6501&marshaller=org.jboss.test.remoting.marshall.dynamic.remote.http.TestMarshaller&unmarshaller=org.jboss.test.remoting.marshall.dynamic.remote.http.TestUnMarshaller
The parameter you want to add is here under 5.11.1
SERIALIZATIONTYPE (actual value is 'serializationtype') - indicates the serialization implementation to use. Currently, the only possible values are 'java' and 'jboss'. Java serialization is the default. Setting to 'jboss' will cause JBoss Serialization to be used. In implementation, this equates to the parameter that will be passed to the SerializationStreamFactory.getManagerInstance() method. This configuration can be set as an invoker locator url parameter (e.g. socket://myhost:5400/?serializationtype=jboss) or as an entry to the configuration Map passed when constructing a remoting client or server.
So you would append
&serializationtype=jboss
Note that there is no way to use JBoss Serialization for JMS that I could find.
Related
I want to run few tasks asynchronously in a web application. My question is which Spring implementation of task executors i should use in a Container managed environment.
I refereed to this chapter in Spring documentation and found few options.
One option I considered is WorkManagerTaskExecutor. This is very simple and works seamlessly with the IBM Websepher server which I'm currently using but this is very specific to IBM Websphere and Oracle Weblogic servers. I don't want to tie my code specifically to one particular implementation as in some test and local regions we are using Jetty container & this implementation creates problems to run the code in Jetty.
Other options like SimpleThreadPoolTaskExecutor does not seem to be best fit to leverage thread pooling in container managed environment and I don't want to create new thread myself.
Could you pleas suggest how do I go about this. Any pointers to a sample implementation will be great help.
As usual, it depends. If you rely on the container's thread management and want to be able to set thread pools on its admin interface or if you're application is not the only app inside the container or you use specific features like setting thread pool priorities for EJB or JMS you should add support for the WorkManagerTaskExecutor and make it configurable. If not, you can use whatever you want cause in the end threads are just threads. Since Spring is an IOC container you can do it. To use the same app everywhere I wouldn't suggest to change the XML config per app version. Rather
use profiles with configuration to set the executor type and inside your java config return the proper bean type. If you use Jetty you should have a configuration for the thread pool sizes to to be able to tune it.
use spring boot like auto configuration which usually rely on available classes on classpath (#ConditionalOnClass). If your weblogic or websphere specific classes are available or any other container specific thing like env variables you can create the WorkManagerTaskExecutor
With both of these you can deploy the same war everywhere.
We have a Spring 4.0-based web application running in Tomcat 8 (alternatively we have a start-up script for Undertow). Spring MVC is handling requests. I am looking for a way to defer some of request handling code to Clojure library, with minimal changes to legacy Java code.
For instance, requests with URLs ending with .java would be handled by legacy Java, and requests ending with .clj would be handled by Clojure. For now, i see three options:
Include Clojure library jar in Java project's dependencies and use clojure.java.api to invoke Clojure code from Java.
Use some sort of RPC/RMI or message queues, e.g. Redis and Carmine's message queue processing capabilities. This way, Clojure would live in a separate JVM.
Use some sort of reverse proxy to perform URL routing.
Are above approaches actually feasible? What else would you suggest?
Thanks!
I've done a similar thing but on a DropWizard application rather than a Spring application. I went with approach #1.
I followed the example here - https://stackoverflow.com/a/2187427/827617
to create the library. That way you don't need to use clojure.java.api, your Clojure library compiles down into a jar that you can include in your Spring application and call directly from Java (the functions that you expose are static methods on a class).
I have to develop a JAX-WS client which has to be deployed to WebSpehere 7.
WebSphere 7 uses a custom Axis2 implementation.
I've read on this guide (http://axis.apache.org/axis2/java/core/docs/jaxws-guide.html) to use wsimport to generate classes necessary for client.
But generated classes reference to com.sun.xml.ws.spi.ProviderImpl in jaxws-rt.jar (present in JRE6), while when client runs on Websphere they reference org.apache.axis2.jaxws.spi.Provider.
Is it correct? Using Oracle JDK wsimport is the correct way to follow also if clients will be use Axis2 implementation?
There should be a wsimport tool as part of your WAS installation. I found mine under /IBM/WebSphere/AppServer/bin
Try using that tool to generate your classes, instead of the one from Oracle. It should generate classes that are more compatible with WebSphere.
You could also go get Axis2 from Apache. I imagine that Apache's wsimport (or equivalent) will produce classes that are most server independent.
http://axis.apache.org/axis2/java/core/download.cgi
Use WebSphere's own wsimport. There's a script you can run, a WSDL2Java Ant task you can use, or if you have RAD, you can do it within that.
Artifacts generated by wsimport are portable, i.e. they don't contain references to implementation specific classes. The actual JAX-WS implementation is selected at runtime. Therefore, it doesn't matter whether you use Oracle's or IBM's wsimport.
I am trying to write a JAX WS client for a service exposed using Axis2, WebSphere8, Java 1.6.
Standalone client(i.e. client running in my local machine) works fine but when I deploy the client in a application running in same websphere server I get
java.lang.ClassCastException: Cannot cast class org.apache.axis2.jaxws.spi.Provider to class javax.xml.ws.spi.Provider
at line OpenPortType service = OpenService
.create(wsdlFile.toURL(),
new QName( "http://www.test.com/schemas/public/open-api/Open/","OpenService")).getPort(
OpenPortType.class);
When I tried to google I found similar problem existed in weblogic : https://wso2.org/jira/browse/CARBON-4835
When we see source of axis2.jaxws.spi.Provider class we come to know that it's a subclass of javax.xml.ws.spi.Provider !!
I'm wondering what could be wrong ? Any idea ?
Unless you are calling Axis2 capabilities directly, rather than simply using JAX-WS APIs, you do not want to package Axis into your EAR. WebSphere does provide its own JAX-WS implementation which I'm not surprised conflicts with another JAX-WS implementation you've deployed in your app. (In particular, note that WebSphere's own implementation is based on Axis2.)
If you do need to deploy a different implementation, you'll probably have to at least adjust your WebSphere classloader policy to parent_last. There might be more to do as well; it's been a while since we did this ourselves. But it's much easier and cleaner to use the built-in JAX-WS implementation, which means not deploying any of those jars at all.
I know how I'd do this using JBoss: create a *-ds.xml file, and drop it into my deploy directory.
Is there a declarative way to do the same with GlassFish (v3.1)?
Am I thinking about this the wrong way? (See next question)
Is there a more-Glassfishy way to get my Java EE application to talk to a database?
Other potentially-revelant info:
I want to connect to a SQL Server 2008 database
I'm using Eclipse + GlassFish Server Tools
I know next to nothing about GlassFish. I'm much more familiar with JBoss
You can define it in application.xml or ejb-jar.xml of your EAR. You can even use annotations.
Long answer short: DataSource Resource Definition in Java EE 6.
BalusC is right (+1), with Java EE 6 you can declare datasource definitions either through annotations or through the use of deployment descriptors in a standard and portable way.
Just in case you'd be also interested by creating other resources than datasources like JMS resources, you can also package a glassfish-resources.xml file as part of your application. See:
Supporting glassfish-resources.xml
4.1.3 Application scoped resources