We Keep Coding

Weblogic 14c - webservice-description-name is not unique within weblogic-webservices

I am exposing my stateless ejb as web service using the annotations as follows:
#WebService(
name = "MyServicePort",
portName = "MyServicePort",
serviceName = "MyService",
)
#SOAPBinding(
style = SOAPBinding.Style.RPC
)
#Stateless(mappedName="MyServiceEJB", name = "MyServiceEJB")
public class MyServiceBean {
To define the context root in weblogic, I've defined the web service in weblogic-webservices.xml deployment descriptor as follows:
<weblogic-webservices
xmlns="http://xmlns.oracle.com/weblogic/weblogic-webservices"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-webservices http://xmlns.oracle.com/weblogic/weblogic-webservices/1.1/weblogic-webservices.xsd">
<webservice-description>
<webservice-description-name>MyService</webservice-description-name>
<port-component>
<port-component-name>MyServicePort</port-component-name>
<service-endpoint-address>
<webservice-contextpath>/mycontext</webservice-contextpath>
<webservice-serviceuri>/myservice</webservice-serviceuri>
</service-endpoint-address>
</port-component>
</webservice-description>
</weblogic-webservices>
However, weblogic is throwing the below error while deploying:
[ERROR] weblogic.wsee.ws.WsException: Error encountered while deploying WebService module 'myservice-ejb.jar'.
In weblogic-webservices.xml, webservice-description-name MyService is not unique within weblogic-webservices
Any clue what I am doing wrong here? This is the only bean/service in my web application and there is no other application deployed in weblogic (local instance).

I am able to resolve the issue by placing the webservices.xml with below contents into META-INF folder (next to weblogic-webservices.xml).
<webservices xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/javaee_web_services_1_4.xsd"
version="1.4">
<display-name>MyService</display-name>
<webservice-description>
<webservice-description-name>MyService</webservice-description-name>
<port-component>
<port-component-name>MyServicePort</port-component-name>
<wsdl-port xmlns:tns="http://schemas.mycompany.com/webservices/MyService">tns:MyServicePort</wsdl-port>
<service-endpoint-interface>mypackage.MyServiceBean</service-endpoint-interface>
<service-impl-bean>
<ejb-link>MyServiceEJB</ejb-link>
</service-impl-bean>
</port-component>
</webservice-description>
</webservices>
Hope it may help someone facing the same challenge.

#Resource annotation doesn't work in Tomact 10.0.10

Recently I tried Tomcat 10.0.10 and when trying to inject the connection pool as a JNDI resource find out that the #Resource annotation doesn't work.
Then I tried obtain it programmatically by creating a InitialContext and it worked. Initially I thought it was only for the java:comp/env/jdbc so I tried with a simple bean like below and tried to inject it with the #Resource annotation it didn't work again. When I try to obtain it programmatically by creating a InitialContext and it works. Then I check whether the #PostConstruct or #PreDestroy annotation works and found out that they also don't work.
package lk.ijse.test.tomcatdbcp;
public class Something {
}
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Resource name="bean/Something" auth="Container"
type="lk.ijse.test.tomcatdbcp.Something"
factory="org.apache.naming.factory.BeanFactory"
/>
</Context>
<?xml version="1.0" encoding="UTF-8"?>
<web-app metadata-complete="false" xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
version="5.0">
<resource-env-ref>
<resource-env-ref-name>bean/Something</resource-env-ref-name>
<resource-env-ref-type>lk.ijse.test.tomcatdbcp.Something</resource-env-ref-type>
</resource-env-ref>
</web-app>
package lk.ijse.test.tomcatdbcp;
import java.io.*;
import jakarta.annotation.PostConstruct;
import jakarta.annotation.Resource;
import jakarta.servlet.http.*;
import jakarta.servlet.annotation.*;
import javax.naming.InitialContext;
import javax.naming.NamingException;
#WebServlet(name = "helloServlet", value = "/hello", loadOnStartup = 1)
public class HelloServlet extends HttpServlet {
private String message;
#Resource(name= "java:comp/env/bean/Something")
private Something something;
#PostConstruct
public void doSomething(){
System.out.println("Does it work?");
}
public void init() {
message = "Hello World!";
try {
InitialContext ctx = new InitialContext();
Something lookup = (Something) ctx.lookup("java:comp/env/bean/Something");
System.out.println(lookup);
System.out.println(something); // null
} catch (NamingException e) {
e.printStackTrace();
}
}
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
response.setContentType("text/html");
// Hello
PrintWriter out = response.getWriter();
out.println("<html><body>");
out.println("<h1>" + message + "</h1>");
out.println("</body></html>");
}
public void destroy() {
}
}
To reproduce the same issue, I created a sample repo here: https://github.com/sura-boy-playground/play-with-tomcat10
(Complete code can be found there)
At first, I had used javax.annotation.Resource annotation, so I thought that was the reason because of the javax.* to jakarta.* namespace change. Then I tried it with jakarta.annotation.Resource but the result was same.
I tried the same application with Tomcat 9.0.41 plus javax.* namespace, it works perfectly.
Is there any extra stuff that I need to do on Tomcat 10.0.10 to enable these annotations? I dug the Tomcat 10 documentation but I wasn't able to find out any thing related to my issue.
I found out that there was a similar case in Tomcat 7 previously, but I don't like that kind of workaround now.
Tomcat #Resource annotations API annotation stops working in Tomcat 7

You should declare the scope of your jakarta.annotation dependency as provided:
<dependency>
<groupId>jakarta.annotation</groupId>
<artifactId>jakarta.annotation-api</artifactId>
<version>2.0.0</version>
<scope>provided</scope>
</dependency>
If you have two copies of jakarta.annotation.Resource (one in the common classloader and one in your application's classloader), the two classes are different. The InstanceManager will look for fields annotated with the common classloader's copy of #Resource, while the something field is annotated with your webapp's copy of #Resource.
Edit: this problem was fixed in Tomcat 10.0.17 (cf. changelog), 9.0.59 and 10.1.0-M11.
Remark: You will have the same problem in Tomcat 9.0 if you use Java 11 or later. Before Java 11 the javax.annotation.* classes where included in the JRE. Servlet containers are required to look in the bootstrap/JRE classloader before looking in the webapp classloader (overriding javax.* classes is a breach of Java's licence), therefore Tomcat would never find the additional copy of the classes.

Context is read only

Helo masters, I have to create a JNDI Datasource dynamically, I tried to do it with a listener called SetupApplicationListener. Here is the beginning of WEB-LIB/web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee">
<display-name>pri-web</display-name>
<!-- Listeners -->
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
<listener>
<listener-class>myapp.SetupApplicationListener</listener-class>
</listener>
The code of the listener:
public class SetupApplicationListener implements ServletContextListener {
public static Log LOG = null;
public void contextInitialized(ServletContextEvent ctx){
try {
createOracleDataSource();
.....
}
}
private void createOracleDataSource() throws SQLException, NamingException {
OracleDataSource ds = new OracleDataSource();
ds.setDriverType(...);
ds.setServerName(...);
ds.setPortNumber(...);
ds.setDatabaseName(...);
ds.setUser(...);
ds.setPassword(...);
new InitialContext().bind("java:comp/env/jdbc/myDS", ds);
}
.....
}
And there is the error:
[ERROR] 29/01/2013 09:44:50,517 (SetupApplicationListener.java:86) -> Error
javax.naming.NamingException: Context is read only
at org.apache.naming.NamingContext.checkWritable(NamingContext.java:903)
at org.apache.naming.NamingContext.bind(NamingContext.java:831)
at org.apache.naming.NamingContext.bind(NamingContext.java:171)
at org.apache.naming.NamingContext.bind(NamingContext.java:187)
at org.apache.naming.SelectorContext.bind(SelectorContext.java:186)
at javax.naming.InitialContext.bind(InitialContext.java:359)
at myapp.SetupApplicationListener.createOracleDataSource(SetupApplicationListener.java:102)
Can I set the read-only properties of the Context to "true"? Thanks! :)
Tomcat 6.0
Oracle 11g
jdk1.5
EDIT: Don't need to be dynamically, i have to define a jndi datasource internally I can't modify the server files because it is a shared server. It must be jndi because other modules use it in that way, thanks.

If you need to create a datasource dynamically is there really any need for a JNDI lookup? JNDI is designed to make the connection external to the application, while in your scenario its tightly coupled to the application due to a legitimate requirement. Why not just use a JDBC connection?

You need to create a ServletContextListener and there you can make the InitialContext writable - it's not the way it should be done, but if you really need it, this is one way you can do it.
This also works with Java Melody!
protected void makeJNDIContextWritable(ServletContextEvent sce) {
try {
Class<?> contextAccessControllerClass = sce.getClass().getClassLoader().loadClass("org.apache.naming.ContextAccessController");
Field readOnlyContextsField = contextAccessControllerClass.getDeclaredField("readOnlyContexts");
readOnlyContextsField.setAccessible(true);
Hashtable readOnlyContexts = (Hashtable) readOnlyContextsField.get(null);
String context = null;
for (Object key : readOnlyContexts.keySet()) {
String keyString = key + "";
if (keyString.endsWith(sce.getServletContext().getContextPath())) {
context = keyString;
}
}
readOnlyContexts.remove(context);
} catch (Exception ex) {
ex.printStackTrace();
}
}

I haven't got this problem before since I usually defined JNDI in application server(tomcat, weblogic and etc). Just like what Kevin said, this is exactly what JNDI was designed for; separating datasource config from your source code and retrieving JNDI resources through lookup and inject;
Back to your question, I think tomcat has every strict rules on modifying JNDI at runtime. In another word, you cannot re-bind or remove jndi from Context. If you go through the tomcat specification you will probably see some thing about jndi lookup but no re-bind.

From section EE.5.3.4 of the EE 6 platform specification (JSR 316):
The container must ensure that the application component instances
have only read access to their naming context. The container must
throw the javax.naming.OperationNotSupportedException from all the
methods of the javax.naming.Context interface that modify the
environment naming context and its subcontexts.
Note that "their naming context" in this section is referring to java:comp.

I solved this problem when found that I was closing environmentContext object
For example:
Context context=new InitialContext();
Context environmentContext=(Context) context.lookup("java:comp/env");
And my code was:
environmentContext.close();
After removing close function from environmentContext problem was solded for me;

I also had this problem, but being new to Tomee, I didn't know that there is a simple solution. When I deployed my web app to the webapps folder, the app worked fine, but when I deployed it to a service folder, I got the same abort. The problem was that the folder name did not match the war name (minus the .war). Once I fixed that, the app worked fine. Make sure the war name, folder name and service name are identical. This problem produces several different errors, including Context is read only and Error merging Java EE JNDI entries.

I solved this issue by setting useNaming="false" in my context.xml.
From the documentation:
useNaming : Set to true (the default) to have Catalina enable a JNDI InitialContext for this web application that is compatible with Java2 Enterprise Edition (J2EE) platform conventions.

How to disable Tomcat JARScanner

How: To disable Tomcat JARScanner?
Why: To stop Tomcat scan every .jar in my LIB folder.
According to documentation it says that it is possible to disable it within context.xml. But it seems to not be working. (May be I am missing something)
I made an exhaustive search in forums and could not find the solution.
This is in context.xml (not working yet):
<JarScanner scanClassPath="false" scanAllFiles="false" scanAllDirectories="false"></JarScanner>
Thanks in advance.

You should add the JarScanner element as a child of the root Context element in the context.xml file.
I have this kind of META-INF/context.xml file in the war file for disabling the JarScanner:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<JarScanner scanClassPath="false" scanAllFiles="false" scanAllDirectories="false"/>
</Context>

you can disable the JarScanner globally for user-definted patterns by opeining the file at
%TOMCAT_HOME%/conf/catalina.properties
and add a filename pattern to tomcat.util.scan.StandardJarScanFilter.jarsToSkip list.
For example, if you want to disable jar scanning completely you could add:
tomcat.util.scan.StandardJarScanFilter.jarsToSkip=\
*.jar,\
NOTE: this may of course lead to issues if you're employing JSTL, as templates won't be found by the scanner

in your java app add this :
#Bean
public TomcatServletWebServerFactory tomcatServletFactory() {
return new TomcatServletWebServerFactory() {
#Override
protected void postProcessContext(final Context context) {
((StandardJarScanner) context.getJarScanner()).setScanManifest(false);
}
};
}

This is what I did for Spring Boot.
Basically, append a new ignored jar file to the existing list of jars to ignore. This way, you don't totally disable the scanner, affecting who knows what else.
#Configuration
public class Config {
#Bean
public ServletWebServerFactory servletContainer() {
return new TomcatServletWebServerFactory() {
#Override
protected void postProcessContext(Context context) {
// db2 puts a ref to pdq.jar in the manifest, and tomcat then tries to find it, but it doesn't exist.
// The jar isn't needed, so we just disable looking for it. You could also remove it from the manifest,
// but that prob needs to be done after the build process.
JarScanFilter jarScanFilter = context.getJarScanner().getJarScanFilter();
if (jarScanFilter instanceof StandardJarScanFilter) {
StandardJarScanFilter filter = (StandardJarScanFilter) jarScanFilter;
String oldTldSkip = filter.getTldSkip();
String newTldSkip = oldTldSkip == null || oldTldSkip.trim().isEmpty() ? "pdq.jar" : oldTldSkip + ",pdq.jar";
filter.setTldSkip(newTldSkip);
} else {
logger.warn("Unable to disable the tomcat jar scanner for pdq.jar. You may see a FileNotFound exception complaining of not finding a db2 pdq.jar file. You can probably ignore the error. Ref: https://stackoverflow.com/questions/11656596/how-to-disable-tomcat-jarscanner");
}
}
};
}
}

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.