Develop Reference

JNDI DataSource: migrating from Weblogic to Jboss 7

I migrate my Weblogic application to JBoss 7 and I need that my migration code could be runnable on these both servers. JNDI name of WebLogic datasource is :
jdbc/powds
JNDI name of Jboss datasource is :
java:/powds
I've already known that JNDI syntax in JBOSS 7 is another and starts with the prefix "java:". In WebLogic application I use JNDI name in different files like web.xml and persistance.xml.
In code I use :
static final String dataSourceName = "jdbc/powds";
I read this article JNDI path Tomcat vs. Jboss and trying to configure my xmls descriptors files.
So finnaly I have error Required services that are not installed:" => ["jboss.naming.context.java.jdbc.powds"].
How I can avoid this error? How I can configure persistance.xml file to use different JNDI names depends on running the application server.
my web.xml file is:
<resource-ref>
<res-ref-name>jdbc/powds</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
my jboss-web.xml file is:
<resource-ref>
<res-ref-name>jdbc/powds</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<jndi-name>java:/powds</jndi-name>
</resource-ref>
my weblogic.xml file is:
<resource-description>
<res-ref-name>jdbc/powds</res-ref-name>
<jndi-name>jdbc/powds</jndi-name>
</resource-description>
my weblogic.xml file is:
<resource-description>
<res-ref-name>jdbc/powds</res-ref-name>
<jndi-name>jdbc/powds</jndi-name>
</resource-description>
my persistance.xml file is:
<persistence-unit name="powpu" transaction-type="JTA" >
<jta-data-source>jdbc/powds</jta-data-source>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
</persistence-unit>

jboss-all.xml JBoss EAP 6.4 not taken in consideration (not working)

I have a JBoss EAP 6 instance, which has a couple of deployments (An EAR and a few WARs):
The thing is that on shutdown, I need myWar1.war to be undeployed after myEar.ear, but the actual result is that myEar.ear is being undeployed last, causing errors in the logs on shutdown due to the dependency.
I've already tried declaring dependencies of that war to the ear through jboss-deployment-structure.xml, and myWar1.war/WEB-INF/jboss-all.xml. Here are the examples:
myWar1.war/WEB-INF/jboss-deployment-structure.xml
<dependencies>
<module name="deployment.myEar.ear">
<imports>
<exclude path="***" />
</imports>
</module>
<module name="javax.annotation.api" />
</dependencies>
myWar1.war/WEB-INF/jboss-all.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss umlns="urn:jboss:1.0">
<jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
<dependency name="myEar.ear" />
</jboss-deployment-dependencies>
</jboss>
None of these solutions seem to work. Although, it looks like jboss-all.xml is being read and parsed by JBoss, but it makes no effect on the order of undeployment of the dependant WAR on the EAR. (I guess it's not the expected behaviour, as states HERE.)
All the WARs are being deployed through JBoss CLI (then the server is restarted), but the myEar.ear is being exploded inside the server /deployments, and it's also added as a deployment through the CLI. Here are the entries for that in standalone-full.xml.
Also, the WAR is a SpringBoot application, built and packaged by Maven.
standalone-full.xml
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-enabled="false" scan-interval="5000"/>
</subsystem>
<deployments>
. . .
<deployment name="myWar1.war" runtime-name="myWar1.war">
<content sha1="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"/>
</deployment>
<deployment name="myEar" runtime-name="myEar.ear">
<fs-exploded path="$JBOSS_HOME/standalone/deployments/myEar.ear"/>
</deployment>
. . .
</deployments>
Is there another way I can alter the undeployment sequence when shutting down JBoss? Is there a way to make jboss-all.xml be recognized properly by JBoss, or I am missing some configuration?

The deployment dependencies tag in jboss-all.xml is usually referenced only for ensuring applications deploy after dependencies are established (As in your example myear has to be deployed before mywar1 deploys) but not for shutdown.
Commonly JBoss' command line commands (look up JBoss CLI) are used to handle startup, deployments and shutdowns, but the CLI is not meant to be invoked from within your program's code. There is a parallel api called the Management API, for the management interface, which has shutdown/startup functionality, and which is meant to be called from within your code.
The AS7 Management API is applicable to the JBoss EAP 6.x, as should the newest Wildfly version of the API. Only the wildfly api is supposed to be the most updated page for the API and it lists the startup/shutdown procedures though YMMV. Here is the wildfly API and the 6.x/AS7 api in case you run into issues using the wildfly reference. Here is how to use the Management Interface API programmatically.

Glassfish 4.1: war inside ear does not expose webservices

I am currently working on upgrading an application from Java7 running on Glassfish 3.1.2.2, to Java8 running on Glassfish 4.1. The application is packaged as an ear-file, containing an ejb-jar, and a war. The war in turn contains some webservices.
In Glassfish 3.1.2.2, deploying the ear will lead to the war exposing a number of webservices. But, when I deploy the ear in Glassfish 4.1, no webservice are exposed. When listing the components for the ear in Glassfish, the war does not list webservices (only web) in 4.1 (but does in 3.1.2.2).
I have tried deploying the war-file as a standalone application, and when doing this the webservices becomes available.
Does anyone know if there is a known bug with regards to deploying webservices through an ear-file with Glassfish 4.1?
When it comes to changes, I have upgraded some dependencies, but as far as I know there is nothing that should affect this.
My application.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC
"-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
"http://java.sun.com/dtd/application_1_3.dtd">
<application>
<display-name>myApplication-ear</display-name>
<description>myApplication</description>
<module>
<ejb>myApplication-ejb-5.2-SNAPSHOT.jar</ejb>
</module>
<module>
<web>
<web-uri>myApplication-war-5.2-SNAPSHOT.war</web-uri>
<context-root>/myApplication-war</context-root>
</web>
</module>
</application>

The problem was an old dependency:
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-rt</artifactId>
<version>2.2.7</version>
</dependency>
I removed it because it is already included in rt.jar in the java installation.
Somehow Glassfish didn't handle this at all, the webservices simply didn't work and no traces of error in the server.log

Can this be your scenario (?): EJB module deployment may fail when an EJB that is exposed as a web service, and which has a handler, is initialized before an EJB on which it has dependencies. This is caused by the way the EJB container initializes and loads EJB web services, the workaround is to rename the EJBs so that the EJB exposed as a web service is initialized after the EJB on which it has dependencies.

Multiple JBoss Web Application Deployment Descriptor with same resources

I have an ear including several war deployed on jboss as 7.1.1.
Each war have a custom JBoss Web Application Deployment Descriptor (jboss-web.xml) declaring the context-root and several jndi datasources all shared between the different web-apps.
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>${app.name}</context-root>
<resource-ref>
<res-ref-name>${datasource}</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<jndi-name>java:/TenantDS</jndi-name>
</resource-ref>
<resource-ref>
<res-ref-name>${shared.datasource}</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<jndi-name>java:/CustomerDS</jndi-name>
</resource-ref>
[...]
</jboss-web>
If I add another war with a jboss-web.xml file declaring only the first datasource (because it's the only one used by this war) then none of remaining war is able to reach the missing datasource anymore.
How a webapp specific deployment descriptor can have such a behavior ? And so, what is wrong in this config ? where should the datasource be declared ?

Do you have declared datasource in web.xml? You have to have it in jboss-web.xml and web.xml in each war application.

How to set tomcat work at debug mode?

I deploy a application to tomcat with context xml. I want the tomcat work at debug mode, I means if I change something inside a function, like change
String a="123";
to
String a="456";
tomcat should get the change without reload the application.
The web01.xml under %CATALINA_HOME%/conf/Catalina/localhost
<?xml version='1.0' encoding='utf-8'?>
<Context docBase="d:/document/workspace3.6/web01/WebContent" path="/web01" reloadable="false" debug="1" ></Context>
but now tomcat didn't worked as I expected, if I replace the old class file with new version, I must restart tomcat to get the change.
Why tomcat didn't reload the class,How should I do to let it work as debug mode?
I am not use Eclipse now. and I don't want to set reloadable="true", this will reload the entire application if class changed.
I used tomcat5.5.23

You're actually confusing the notions of "debugging" and hot deploy. You can configure Tomcat for debug mode, and then remotely debug your application running inside tomcat such that when you add a break point in your code, the debugger will jump to that breakpoint and halt execution.
What you actually need there is having the possibility to hotdeploy an application. With tomcat, if you modify the .java files and then copy them to the working directory of tomcat, you'll get exactly what you want, namely the ability to change something in a class and have the running tomcat-deployed application take it into account without redeploying the whole application. You can automatize this by configuring your tomcat application context (either in the tomcat server.xml file or in a project specific context.xml file) for your application to have as working directory the directory where your project code gets compiled.
here's an actual example:
Let's say you have a maven project in the directory c:\myProject. You'd have source files in the c:\myProject\src, and then when compiling it you'd get the war file and an exploded directory of the war file content in the c:\myProject\target\myProject.war and respectively c:\myProject\target\myProject. Now, if you configure your tomcat such that for the myProject tomcat context, youd have the working directory configured as c:\myProject\target\myProject, then each time you modify a .java file, the .class corresponding file will be updated in the target (and now also working) dir, and tomcat will take it into account.
I've actually used such a setup to develop with tomcat, but it's not the best. First off tomcat will hotdeploy only certain modifications, such as when you modify something in the body of an existing method. Other modifications will not be taken into account, such as adding a new method - for this you have to do a full redeploy to have it taken into account.
A far better solution is to use maven with the maven jetty plugin. This thing really works as you want: any modification you do to a class of jsp file will me immediately taken into account, and visible in the running app inside jetty.

Ok, here's an actual example:
I have the cnas-war maven project. Once I build it with Maven, I get the following directory:
c:/_andrei/work/cnas/cnas-war/target\cnas-war-0.0.1-SNAPSHOT
In here I have all the stuff that normally would get packaged in the .war file, like .class files, .jsp files, .jar files etc. Effectively it's the .war file exploded.
I also have a Tomcat 5.5 specifically tailored for the deployment of this war, cleverly placed in the tomcat_cnas folder. In the Tomcat config file (conf\server.xml) I have the following:
<?xml version="1.0" encoding="utf-8"?>
<!-- Example Server Configuration File -->
<!-- Note that component elements are nested corresponding to their
parent-child relationships with each other -->
<!-- A "Server" is a singleton element that represents the entire JVM,
which may contain one or more "Service" instances. The Server
listens for a shutdown command on the indicated port.
Note: A "Server" is not itself a "Container", so you may not
define subcomponents such as "Valves" or "Loggers" at this level.
-->
<Server port="8125" shutdown="SHUTDOWN">
<!-- Comment these entries out to disable JMX MBeans support used for the
administration web application
<Listener className="org.apache.catalina.core.AprLifecycleListener" />
<Listener className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener"/> -->
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<!-- Global JNDI resources -->
<GlobalNamingResources>
<!-- Test entry for demonstration purposes -->
<Environment name="simpleValue" type="java.lang.Integer"
value="30" />
<Resource auth="Container"
configurationDirectory="c:/cnas-content"
factory="com.genia.toolbox.web.jndi_config.StringContainerFactory"
name="string/activitymanagerConfigurationContainer"
type="com.genia.toolbox.web.jndi_config.StringContainer" />
<Resource name="string/activitymanagerConfigurationContainer"
auth="Container"
type="com.genia.toolbox.web.jndi_config.StringContainer"
factory="com.genia.toolbox.web.jndi_config.StringContainerFactory"
configurationDirectory="c:/cnas-content" />
</GlobalNamingResources>
<!-- Define the Tomcat Stand-Alone Service -->
<Service name="Catalina">
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<Connector acceptCount="100" connectionTimeout="20000"
disableUploadTimeout="true" enableLookups="false"
maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150"
minSpareThreads="25" port="8081" redirectPort="8443" />
<!-- Define the top level container in our container hierarchy -->
<Engine defaultHost="localhost" name="Catalina">
<!-- for activitymanager -->
<Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="true" xmlValidation="false"
xmlNamespaceAware="false">
<Context path="/cnas"
docBase="c:/_andrei/work/cnas/cnas-war/target/cnas-war-0.0.1-SNAPSHOT/"
workDir="c:/_andrei/work/cnas/cnas-war/target/work-cnas/">
<ResourceLink name="string/configurationContainer"
global="string/activitymanagerConfigurationContainer"
type="com.genia.toolbox.web.jndi_config.StringContainer" />
<Resource name="bean/cnasConfig" auth="Container"
type="com.genia.toolbox.projects.cnas.war.config.CnasConfig"
factory="org.apache.naming.factory.BeanFactory"
classpath="false" fileSystem="true"
applicationFileLocation="c:/cnas-content/application.properties" />
<Resource name="bean/cnasApplicationData"
auth="Container"
type="com.genia.toolbox.projects.cnas.war.config.CnasConfig"
factory="org.apache.naming.factory.BeanFactory"
classpath="false" fileSystem="true"
applicationFileLocation="c:/cnas-content/cnas_application_data.xml" />
</Context>
<!--Context docBase="C:/travail/workspace/cnas/cnas-ws-proxy/target/webapp" path="/proxy">
<Resource name="bean/params"
auth="Container"
type="fr.genia.cnas.config.Parameters"
factory="org.apache.naming.factory.BeanFactory"
log4jFile=""
serviceUrl=""
debugMode="true" >
</Resource>
</Context-->
</Host>
</Engine>
</Service>
</Server>
As you can see, in the "context" tag I have a docBase property pointing to the snapshot directory (the one where the war is exploded after maven builds it). Now, with this setup, and having this project imported into Eclipse, if I do a maven build, and then start this Tomcat, the war will be deployed and running. At this point, if I modify the content of a method in a .java file inside Eclipse (and save), then that code will be automatically taken into account by Tomcat and the application will behave differently, without any extra re-deployment. Hope this helps

How to configure Tomcat 5.5 for debug mode?

To do what you are trying to do, You would need some thing like java rebel or some thing similar I know there are some open source alternatives to do the same.