We Keep Coding

WebContext is no longer honoured after migration from Jboss7 to WildFly10

I am migrating a statless EJB exposed as a web service from JBoss7 AS to WildFly 10 (granted I am a bit late).
The web service used to be accessible by http://localhost:8080/vmwWS/vmw, moving to WildFly gets me http://localhost:8080//vmwWS/WSVMWBean and I haven't found a way to change this.
Here's the web service class
[...]
#Interceptors(TracingInterceptor.class)
#Stateless
#WebService(endpointInterface = "com.mydomain.WSVMW")
#WebContext(contextRoot="/vmwWS", urlPattern ="/vmw", authMethod="BASIC", secureWSDLAccess = false)
#SecurityDomain("JBossWS")
#RolesAllowed({ "Read", "Write" })
public class WSVMWBean implements WSVMW {
[...]
The Interface:
[...]
#WebService(name = "vmw")
#SOAPBinding(style = Style.DOCUMENT)
#Local
public interface WSVMW {
[...]
And the jboss-webservice.xml:
<?xml version="1.0" encoding="UTF-8"?>
<webservices xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.com/xml/ns/javaee/jbossws-web-services_1_0.xsd"
version="1.1">
<context-root>vmwWS</context-root>
<port-component>
<ejb-name>WSVMWBean</ejb-name>
<port-component-name>WSVMWBean</port-component-name>
<port-component-uri>/vmw</port-component-uri>
<auth-method>BASIC</auth-method>
</port-component>
</webservices>
The logs say:
22:16:59,520 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-8) JBWS024061: Adding service endpoint metadata: id=WSVMWBean
address=http://localhost:8080/<ejb-jar-name>/vmwWS/WSVMWBean
implementor=com.mydomain.WSVMWBean
serviceName={http://vmw.mydomain.com/}/vmwWS
portName={http://vmw.mydomain.com/}WSVMWBeanPort
annotationWsdlLocation=null
wsdlLocationOverride=null
mtomEnabled=false
How do I get the previous behaviour back?

To cut it short this is the diff which fixed it:
-import org.jboss.wsf.spi.annotation.WebContext;
+import org.jboss.ws.api.annotation.WebContext;
From here:
https://developer.jboss.org/wiki/JBossWS4MigrationGuide

How do we provide custom jndi name for EJB3 in Weblogic12

I am trying to deploy an ejb but would like to provide custom jndi name for it.
I created below: weblogic-ejb-jar.xml
`
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.2/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>test</ejb-name>
<jndi-name>ejb/test</jndi-name>
<enable-call-by-reference>true</enable-call-by-reference>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
`
But when I try to look up bean using this jndi name, I get javax.naming.NameNotFoundException.
Is there any configuration that I am missing here?

It is likely that you are not looking up the bean correctly. You could try the following.
Context initialContext = new InitialContext();
test testInstance = (test)
initialContext.lookup("java:comp/env/ejb/test");

#PostConstruct Wrong deploy in GlassFish

My project is based in Spring 4.2.3.RELEASE
Before a use Tomcat, but last migration project has one problem with ClassLoader, then change Tomcat 8 for GlassFish 4.1!
In project has one #Component("i18N")
in my Object call i18N has one method
But i'm to deploy in GlassFish the file site-1.3.0.0.war
Has put a wrong error
In other project has same problem, but i'm dont have time to solve this problem, at now i'm need solved this.
Error occurred during deployment: Exception while deploying the app
[site-1.3.0.0] : The lifecycle method [init] must not throw a checked exception. Related annotation information: annotation
[#javax.annotation.PostConstruct()] on annotated element [public void com.sys.resolver.SysResourceBundleRead.init() throws java.lang.IllegalAccessException,java.lang.InstantiationException,java.io.IOException,org.apache.taglibs.standard.lang.jstl.ELException] of type
[METHOD]. Please see server.log for more details.
add the method class
**
#PostConstruct
public void init() throws Exception{
}
**

As the error message says, a method with #PostConstruct must not throw checked Exceptions.
So remove throws Exception from your method and catch it in the method body:
#PostConstruct
public void init() {
try {
// bla
} catch (Exception x) {
// do something
}
}

Here
I already made work around that worked in my case.
You can solve this issue first by adding a web.xml with metadata-complete="true". Next you will want to make sure your context are in the Web root Directory /WEB-INF/.
With this glassfish can load all #PostConstructSpring dependencies.

I solved by adding the metadata-complete="true" in the web.xml like:
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" metadata-complete="true">

JNDI path Tomcat vs. Jboss

I have DataSource which is configured on Tomcat 6 in context.xml as MyDataSource.
And I'm fetching it the following way:
DataSource dataSource;
try {
dataSource = (DataSource) new InitialContext().lookup("java:comp/env/MyDataSource");
} catch (NamingException e) {
throw new DaoConfigurationException(
"DataSource '" + url + "' is missing in JNDI.", e);
}
Everything works fine. Now I'm exporting this code to Jboss AP 6. and I configured my dataSource and its connection pool as local-tx dataSource under the same name.
When I'm executing the code above, I'm getting NamingException exception. after some investigation I've found that correct way to call my DataSource under Jboss is
dataSource = (DataSource) new InitialContext().lookup("java:/MyDataSource");
Can anybody explain me why should I omit "comp/env" in my JNDI path under Jboss?

The portable approach for defining data sources is to use a resource reference. Resource references enable you to define the JNDI name for your data source, relative to your application naming context (java:comp/env), and then map that logical reference to the physical resource defined in the application server, whose JNDI name is proprietary to the application server vendor. This approach enables your code and assembly to be portable to any compliant application server.
Step 1: Declare and Lookup Resource Reference
Option 1
This can be done by declaring a resource-ref in your web deployment descriptor (WEB-INF/web.xml):
<resource-ref>
<description>My Data Source.</description>
<res-ref-name>jdbc/MyDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
Within your code, you can then lookup this resource using the JNDI name java:comp/env/jdbc/MyDataSource:
dataSource = (DataSource) new InitialContext().lookup("java:comp/env/jdbc/MyDataSource");
This JNDI name will not change regardless of the server where the application is deployed.
Option 2
Alternatively, starting in Java EE 5 (Servlet 2.5), this can be done even easier within your code using the #Resource annotation. This eliminates the need for configuring the resource-ref in your web deployment descriptor (web.xml) and prevents the need to perform an explicit JNDI lookup:
public class MyServlet extends HttpServlet {
#Resource(name = "jdbc/MyDataSource")
private DataSource dataSource;
#Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
// dataSource may be accessed directly here since the container will automatically
// inject an instance of the data source when the servlet is initialized
}
This approach has the same results as the previous option, but cuts down on the boilerplate code and configuration in your assembly.
Step 2: Map Resource Reference to Data Source
Then, you will need to use your application server's proprietary approach for mapping the resource reference to the physical data source that you created on the server, for example, using JBoss's custom deployment descriptors (WEB-INF/jboss-web.xml):
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<resource-ref>
<res-ref-name>jdbc/MyDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<jndi-name>java:/MyDataSource</jndi-name>
</resource-ref>
</jboss-web>
Or, for example, using Tomcat's context.xml:
<Resource name="jdbc/MyDataSource" . . . />

You can add to your data source definition the 'jndi-name' tag:
jndi-name - the JNDI name under which the DataSource should be bound.
You can find data source documentation on JBoss wiki: ConfigDataSources

Weblogic Bea 10.0 M1 and WorkManager

I have to execute long running threads in a WebLogic Bea 10.0 M1 server environment. I tried to use WorkManagers for this. Using an own WorkManager allows me to specify my own thread timeout (MaxThreadStuckTime) instead of adjusting the timeout for the whole business application.
My setup is as follows:
weblogic-ejb-jar.xml:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>TestBean</ejb-name>
<resource-description>
<res-ref-name>myWorkManager</res-ref-name>
<jndi-name>wm/myWorkManager</jndi-name>
</resource-description>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
weblogic-application.xml:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic.xsd">
<work-manager>
<name>myWorkManager</name>
<ignore-stuck-threads>1</ignore-stuck-threads>
</work-manager>
</weblogic>
and the Bean:
import javax.annotation.Resource;
import javax.ejb.Stateful;
import weblogic.work.WorkManager;
#Stateful(mappedName = "TestBean")
public class TestBean implements TestBeanRemote {
#Resource(name = "myWorkManager")
private WorkManager myWorkManager;
public void test() {
myWorkManager.schedule(new Runnable() {
public void run() {
while (true) {
System.out.println("test: +++++++++++++++++++++++++");
try {
Thread.sleep(45000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
});
}
}
When I try to deploy this things, the server gives me the following exceptions:
[EJB:011026]The EJB container failed while creating the java:/comp/env namespace for this EJB deployment.
weblogic.deployment.EnvironmentException: [EJB:010176]The resource-env-ref 'myWorkManager' declared in the ejb-jar.xml descriptor has no JNDI name mapped to it. The resource-ref must be mapped to a JNDI name using the resource-description element of the weblogic-ejb-jar.xml descriptor.
I try to figure out how to access / use WorkMangers for days now, and still get this or that as an exception. Very frustrating!
Thanks in advance!

You need to remove the WorkManager refrence from your weblogic-ejb-jar.xml, this refenece should go to ejb-jar.xml.
Infact I doubt if Weblogic schema definition "weblogic-ejb-jar.xsd" will allow you to add a reference element, you must be getting xsd validation errors.
anyways, get rid of the element
resource-description from weblogic-ejb-jar.xml
<weblogic-enterprise-bean>
<ejb-name>TestBean</ejb-name>
<resource-description>
<res-ref-name>myWorkManager</res-ref-name>
<jndi-name>wm/myWorkManager</jndi-name>
</resource-description>
</weblogic-enterprise-bean>
it will look like this
weblogic-ejb-jar.xml
<weblogic-enterprise-bean>
<ejb-name>TestBean</ejb-name>
</weblogic-enterprise-bean>
your workManager reference will go to ejb-jar.xml like this.
ejb-jar.xml
<enterprise-beans>
<session>
<ejb-name>TestBean</ejb-name>
<ejb-class>com.xxx.TestBean</ejb-class> <!-- your package com.xxx-->
<resource-ref>
<res-ref-name>myWorkManager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</session>
</enterprise-beans>
Now to get WorkManager from JNDI I'm doing
InitialContext ctx = new InitialContext();
this.workManager = (WorkManager) ctx.lookup("java:comp/env/myWorkManager");
but I belive annotation will work equally well.
#Resource(name = "myWorkManager")
my weblogic-application.xml looks same as shared above
<weblogic>
<work-manager>
<name>myWorkManager</name>
<ignore-stuck-threads>1</ignore-stuck-threads>
</work-manager>
This is working for me .. let me know if needed I can share my full code.
you can view your WorkManager and load on it by going to Weblogic Admin Console
Home—>Deployments—>yourApp—>Monitoring(Tab)—>WorkLoad(Tab)”

You need to name your work manager. The way we do it is in our Ear project EarContent/META-INF/weblogic-application.xml
<wls:work-manager>
<wls:name>wmBatch</wls:name>
<wls:ignore-stuck-threads>true</wls:ignore-stuck-threads>
</wls:work-manager>
(which you appear to have done)
and then we use the annotations to set the manager:
#MessageDriven(ejbName =..., dispatchPolicy = "wmBatch")
And then there is no coding around getting the work manager. This might work for you.

BEA (together with IBM) have developed a framework specifically for managing long-running tasks in a Java EE environment. Take a look at CommonJ.
The Spring Framework offers some convenience classes around this framework.