I have a project with a EJB implementing a JWS Webservice, like this:
#Stateless
#Remote(WebServiceTest.class)
#WebService(
serviceName="TestService",
name="TestName"
)
public class WebServiceTestImpl implements WebServiceTest {
#Override
#WebMethod(operationName="hello")
public String hello() {
return "Hello World!";
}
}
I deploy and test this perfectly on WebLogic 10.3 using a simple EAR project. Now I need to use Hibernate on my project, so from previous experiences I know that I have to use Antrl from Hibernate and not from the container, so I create a weblogic-application.xml in the EAR project:
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-application ...>
<wls:prefer-application-packages>
<wls:package-name>antlr.*</wls:package-name>
</wls:prefer-application-packages>
</wls:weblogic-application>
Now when I deploy the EAR I get this error:
Unable to deploy EJB: WebServiceTestImpl from test-1.0.0-SNAPSHOT.jar:
***** ASSERTION FAILED *****
at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:467)
at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:507)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:41)
at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:149)
Truncated. see log file for complete stacktrace
Caused By: java.lang.ClassNotFoundException: test.WebServiceTestImpl_zd33dy_WSOImpl
at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:280)
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:253)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:177)
Truncated. see log file for complete stacktrace
How can I solve this? If I don't put Antlr in wls:prefer-application-packages Hibernate will not work, and if I put it I cannot deploy the webservice...
Weblogic somehow keeps precompiled versions of EJBs even though you do a new/update deployment.
this works for me with wls 10.3.5:
within the server directory of your domain (e.g. in my case /home/myUser/apps/bea/domains/myDomain/servers/AdminServer) there is a subfolder "cache/EJBCompilerCache". Stop your weblogic instance and remove the contents of this subfolder. Restart weblogic and everything will work :-)
I'm not sure if this is the same bug, but there is a known bug in Weblogic 10.3.0-2 that causes a problem when using JaxWS with an EJB v 2.x. But I'm getting a near identical error when I put the #WebService annotation on an EJB v 3.0 on Weblogic 10.3.1. The error is loading what looks like the supposedly generated local stubs that Weblogic creates, and its happening on Weblogic 10.3.0, 10.3.1, 10.3.2, and 10.3.3. (yes, I really have them all deployed ;)
I had this problem deploying session bean and then trying to convert it to web service. WebLogic seems to cache session beans somehow.
There are several solution to this:
- Rename slsb.
- Comment #Stateless and #Remote annotations, deploy application, uncomment annotations, redeploy again.
- Bounce WebLogic.
Related
I saw this and other similar questions before and their solution didn't solve my problem because Glassfish 5 had a lot of changes.
I'm running a soap web service and getting this error:
java.lang.IllegalStateException: The lifecycle method [finalizeConfig] must not throw a checked exception. Related annotation information: annotation [#javax.annotation.PostConstruct()] on annotated element [public void org.apache.cxf.transport.http_jetty.spring.JettyHTTPServerEngineBeanDefinitionParser$SpringJettyHTTPServerEngine.finalizeConfig() throws java.security.GeneralSecurityException,java.io.IOException] of type [METHOD]
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:503)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:423)
at org.glassfish.web.deployment.archivist.WebArchivist.postAnnotationProcess(WebArchivist.java:317)
at org.glassfish.web.deployment.archivist.WebArchivist.postAnnotationProcess(WebArchivist.java:68)
at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:397)
at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:372)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:247)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:256)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:217)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:137)
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:183)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:207)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:73)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:857)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:797)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:354)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:195)
...
I'm using Glassfish 5.1.0 and using Apache cxf 3.3.5 and my IDE is Eclipse EE Version: 2019-12 (4.14.0)
I downloaded Apache CXF binary distribution and added in to eclipse CXF runtime.
This is my web service class:
package com.web.service;
import javax.jws.WebMethod;
import javax.jws.WebService;
#WebService(targetNamespace = "localhost:8080")
public class Service {
#WebMethod public String greet(String name) {
return "Hi," + name;
}
}
The org.apache.cxf.transport.http_jetty.spring package causes problems when deployed to Glassfish. You need to remove that from the CXF binary distribution.
Please try the following steps:
First remove the original binary distribution from your project in Eclipse.
Then you need to open the binary distribution with some archive tool (maybe the operating system you are using contains something already) and navigate to the lib folder in the archive. Delete the file cxf-rt-transports-http-jetty-*.jar.
Then add the changed binary distribution to your project like you did before with the original binary distribution.
Maybe this will already be sufficient. If not, there is another step you can try.
It is more or less the same solution that you linked already. However, I am not sure if Glassfish 5.1 will still accept the sun-web.xml file. It should be named glassfish-web.xml nowadays.
So create the file glassfish-web.xml with following content:
(if you already have that file, only add the <class-loader delegate="true"/> line to it)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<class-loader delegate="true"/>
</glassfish-web-app>
Put the file into the WEB-INF folder of your WAR file.
I use GlassFish 4 web profile and I have the following interface and class.
#Local
public interface SomeService {
...
}
#Singleton
public class SomeServiceBean implements SomeService {
...
}
When I put interface and class in .war archive (that is in domain1/autodeplay) everything works fine. However, when I put interface and class in separate .jar archive (that is in domain1/lib) then deploying war application I get:
java.lang.RuntimeException: Cannot resolve reference Local ejb-ref name=com.temp.MyServlet/someService,Local 3.x interface =com.temp.SomeService,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session
at com.sun.enterprise.deployment.util.ComponentValidator.accept(ComponentValidator.java:374) ~[dol.jar:na]
at com.sun.enterprise.deployment.util.DefaultDOLVisitor.accept(DefaultDOLVisitor.java:78) ~[dol.jar:na]
at com.sun.enterprise.deployment.util.ComponentValidator.accept(ComponentValidator.java:123) ~[dol.jar:na]
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:152) ~[dol.jar:n
...
I don't use any xml descriptors. So, is it possible to have EJBs in domain1/lib and if yes, how to make EJB container find them? P.S. I tried in GF 4 full - result is the same.
EJBs cannot be added as a library to GlassFish, libraries are just added to the classpath and any annotations on them are ignored and they do not go through the EJB container. If you do want your EJBs as a seperate JAR, they can be deployed just like a WAR or EAR file.
In the Glassfish reference manual for the add-library command it says that it "adds the library to the class loader directory", while for the deploy command it says that "Applications can be...EJB modules".
Also by looking at the source code for Glassfish it can be worked out that all libraries are simply added to the Classloader either at launch (See here and here) or if in applibs then when the application is deployed (See here).
I have very old aplication (10 years - sick) that I need to deploy on weblogic server 10.3.6. I have one ear file with few subdeployed jar's with EJB classes (they contain both weblogic-ejb-jar.xml + ejb-jar.xml). It deploys normally on sever and I can use "lookup" function in weblogic.
The problem is that there is another jar (much older) without ejb-jar.xml that is needed to run this aplication. It have for example ObjectHome.class which is called with "lookup" function in weblogic. For now I've added it in CLASSPATH in weblogic but I still need to somehow deploy it on server so it can be retrived by "lookup" function.
Any ideas how to achive that?
javax.naming.NameNotFoundException: While trying to lookup 'pl.com.project.ejb.IdentyficatorHome' didn't find subcontext 'IdentyficatorHome'. Resolved 'pl.com.project'; remaining name 'ejb/IdentyficatorHome'
at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1139)
at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:247)
at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.java:182)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:206)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:412)
at javax.naming.InitialContext.lookup(Unknown Source)
How was the old JAR assembled and how was it used before in the old container? I would think, if it is a J2EE 1.x EJB, there must be a deployment descriptor for it somewhere?
If not, your only options are either creating a deployment descriptor according to your current weblogic server or - if possible - migrate the old code to a newer EE version.
I'm having an issue with JSF rendering. Here's my setup:
CentOS
TomEE Plus 1.5.2
Icefaces
Spring Security 3
And my app is set up like this:
/opt/tomee/lib/[all the normal TomEE jars]
/opt/tomee/lib/[all the Spring Security jars]
/opt/tomee/lib/icefaces.jar
/opt/tomee/lib/icefaces-compat.jar
/opt/tomee/lib/icepush.jar
/opt/tomee/webapps/UI/index.xhtml
/opt/tomee/webapps/UI/WEB-INF/lib/icefaces-ace.jar
/opt/tomee/webapps/UI/[normal jsf 2 configuration]
There isn't anything obvious in the logs but when the JSF attempts to render I get the following error:
com/sun/crypto/provider/HmacCore
viewId=/index.xhtml
location=/opt/tomee/webapps/UI/index.xhtml
phaseId=RENDER_RESPONSE(6)
Caused by:
java.lang.LinkageError - com/sun/crypto/provider/HmacCore
at com.sun.crypto.provider.HmacSHA1.(DashA13*..)
The stack trace on the error page is massive, so I'm not going to dump a novel here, but here are the calls of note.
java.lang.LinkageError: com/sun/crypto/provider/HmacCore
at com.sun.crypto.provider.HmacSHA1.(DashA13*..)
{...}
at java.security.Provider$Service.newInstance(Provider.java:1221)
{...}
at org.apache.myfaces.shared.util.StateUtils.encrypt(StateUtils.java:328)
{...}
at org.icefaces.impl.renderkit.RenderWrapper.encodeEnd(RenderWrapper.java:53)
{...}
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:311)
I dumped the contents of all the jars in tomee/lib but com.sun.crypto isn't anywhere that I can find in the web server. Apps that don't use Spring Security work just fine.
Any thoughts?
OK. I got it to work so I'm going to be 'that guy' and answer my own question. I hope that it helps save someone else from the migraine it gave me. The problem went away after I did the following:
delete my war
let tomcat clean up the webapps dir
stop tomcat
delete the related directories from work
add the spring security taglibs jar to my app
remove the encoder declaration from my applicationSecurity.xml
rebuild the app
start tomcat
redeploy
drink heavily
profit
Step 10 wasn't actually a part of debugging process but I wouldn't have complained if it was. Share and enjoy.
I have a weird (?) problem with an EJB I want to deploy to my Glassfish 3.1 application server.
I have this bean, which should be executed continuously in Glassfish using the #Schedule annotation. This worked fine for me until I added some code to the EJB accessing a database.
#Stateless
public class MyBean implements MyBeanLocal {
#Schedule(second = "*", minute = "*", hour = "*")
public void initiateProcess() {
MyCoordinator mc = new MyCoordinatorImpl();
List<Entity> entities = mc.methodAccessingDB();
}
}
This is my EJB, which is executed every second. How I said above, I can deploy this EJB and it executed successfully, if I don't call ac.methodAccessingDB().
This means, that I can't even deploy it to Glassfish. Glassfish tells me
Invalid ejb jar [...]: it contains zero ejb. Note: 1. A valid ejb jar
requires at least one session, entity (1.x/2.x style), or
message-driven bean. 2. EJB3+ entity beans (#Entity) are POJOs and
please package them as library jar. 3. If the jar file contains valid
EJBs which are annotated with EJB component level annotations
(#Stateless, #Stateful, #MessageDriven, #Singleton), please check
server.log to see whether the annotations were processed properly..
Please see server.log for more details.
If I just write List<Entity> entities = null; instead of List<Entity> entities = ac.methodAccessingDB(); I can deploy it and it runs fine.
OK, now I have found the solution for this problem. The EJB couldn't find the classes on the deployed version. The solution was to pack everything into an ear project. I am using maven, so I created in the end 3 projects.
one for the EJB <packaging>ejb</packaging>
one for the EAR <packaging>ear</packaging>
and a third parent project, which integrates the both other projects as <module>.
I then deployed the packed ear to Glassfish and the timer started and everything was there.