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
Related
I found that Hotswapagent works different way in SE and EE application. In SE application I can add a new property to the class (e.g. private Long x;) without any problem, Hotswap can update the code. But I'm not able to do this in my EE application in a JSF ManagedBean, I got "The virtual machine does not support this operation: schema changes not implemented".
My EE application is a Maven Enterprise Application (ejb,web,ear projects) in Netbeans 8.2 with Wildfly 10. I use DCEVM (jdk1.8.0_112) and Hotswapagent 1.1.0.
Simple code changes (e.g. edit method body) are works both in SE and EE applications, but it can't handle new property creation neither in ejb nor in web project. I'd like to know if I made some mistake in settings or this is because the differences between SE and EE environments. Thanks for any ideas.
There's no problem with it. Only when I start application in debug mode.
I would expect the addition of a field to be considered a schema change (in such a case, you would get the exception in both Java SE and Java EE). But Java EE is specific by modification of classes (bytecode) at runtime. I guess that when you inserted a field, it wasn’t just that field what was added, but also some synthetic getter and/or setter was introduced, which was a schema change for sure.
HotswapAgent works on JVM level, there should be no difference between Java SE and Java EE. Most probably your Wildfly server does not use DCEVM, please check your setup.
here there is all you need to know to config any EE app server
Payara + DCEVM config
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.
Environment:
Tomcat 7
JNDI
Spring-MyBatis
No JTA - commons pooling only
Problem: Can't get the connection pooling to work as advertised. I can't find a single example of this that doesn't use a stand-alone Transaction manager or that doesn't put all the settings in the war, which makes JNDI pointless. I'm told that JTA is overkill for this application and that we should stick with commons pooling. That makes sense but I don't see a way to configure pooling, if we do it that way.
So... how do I configure connection pooling without putting the settings in the war file AND without using a stand-alone transaction manager? Can this be done without a full Java EE Application Server? We are just moving to Tomcat from another product which actually is full Java EE, so I am thinking this may be a Container vrs. Application server issue.
The weird part is that we can and have used JNDI but the pooling is definitely wrong.
Here is one example that probably works but why bother with JNDI if the settings are going to be in META-INF/context.xml?:
MyBatis JNDI Example
Even with context.xml, it's still a container level setting. But, it's a convenient way of deploying everything in a singe unit rather than having to create the connection pool before you deploy the WAR file.
JNDI is meant to keep your application configuration generic. If you take your WAR and deploy it in WebSphere, for example, it will ignore the context.xml file. But WebSphere will see that you have a JDNI resource-ref in your web.xml and walk you through creating the data source. Same idea as Tomcat, just a different way of doing it.
If you are 100% sure that this application will only run in Tomcat then you don't have to use JNDI. But, it will save you trouble later if you do move to another container.
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.
pros! Looks like basic question, but I just can't find what I am looking for.
I have Equinox and want to run Spring in it (bootstraped in Servlet).
I can't use dm-server, nor can I use the http-bridge, just plain standalone Equinox.
On the other side, using plugin.xml http registry servlet extension is not good enough, since I need the fully-blown web.xml in order to bootstrap Spring.
Where should I dig?
Thanks!
Baruch.
To support "traditional" (aka legacy) web.xml file for webapp deployment you need an implementation of the OSGi Web Applications spec, part of the OSGi R4.2 Enterprise spec. This will allow you to deploy "Web Application Bundles" (WABs) or even plain old WAR files.
There are implementations of this container in both the Eclipse Gemini and Apache Aries projects. Note that the one found in Eclipse Gemini is also found in Eclipse Virgo (the new name for dm Server). You may find that using Virgo will give you a cleaner out-of-the-box experience rather than having to assemble components yourself. Then again I fully understand if it also provides an awful lot more than you really want!
An alternative to this is to move away from web.xml and to register servlets programmatically with the OSGi HttpService. This should be a lot more lightweight, but I don't know whether it will work for "bootstrapping Spring" — quite a vague requirement.
Or you can use the tomcat OSGi bundle that will make you to be able to load bundles as war files. The problem there is that your web bundle's name must end with ".war" and all that stands before that suffix is the application name. So if your bundle's name is myapp.war you connect to it with http://your.server.cc/myapp (and as far as i know there's no way to change that)