I have created a EJB, created a jar of it( containing required ejb-jar.xml and weblogic-ejb-jar.xml files).
when i add this jar to weblogic server 12c, using admin console, i get following issue-
Issues were encountered while parsing this deployment to determine module type. Assuming this is a library deployment.
Due to this my ejb is not shown in jndi tree view. So I am not able to do my jndi lookup. Please rectify my error.
ejb-jar.xml-
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar id="ejb-jar_ID">
<display-name>ProductManager</display-name>
<enterprise-beans>
<session>
<ejb-name>Product</ejb-name>
<home>rohit.ProductHome</home>
<remote>rohit.ProductRemote</remote>
<ejb-class>rohit.ProductBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<ejb-client-jar>ProductManagerClient.jar</ejb-client-jar>
</ejb-jar>
weblogic-ejb-jar.xml-
<?xml version=“1.0? encoding=“UTF-8??>
<weblogic-ejb-jar
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-ejb-jar.xsd”>
<welogic-enterprise-bean>
<ejb-name>Product</ejb-name>
<jndi-name>Product</jndi-name>
<stateless-session-descriptor></stateless-session-descriptor>
</welogic-enterprise-bean>
</weblogic-ejb-jar>
Contrary to what you seem to be thinking, the ejb-jar.xml and weblogic-ejb-jar.xml files are not required. As primary deployment descriptors they are ancient artifacts from 2004.
Your ProductHome class should also be removed if you value your sanity. This is an EJB2 artifact that's completely and utterly unnecessary this time of age.
To get started with EJB, all you need is a POJO with an #Stateless annotation:
#Stateless
public class ProductBean {
// ...
}
Jar this up and deploy it. That's all. You don't have to explicitly name your bean (it will get a name) and you certainly don't have to declare its existence in some XML file.
The ejb-jar.xml is mandatory when deploying an application as a jar file. The correct place to put it is in the META-INF in the jar.
Yes, annotations are definitely nice and easier to maintain. Try this by leaving the ejb-jar.xml minimal.
I always package my applications in EAR with the jars inside. In this case an application.xml file is needed.
It sounds like the container does not recognize the jar as an application. Check the position of the ejb-jar.xml or use EAR packaging.
Oracle recommends that even standalone EJBs be packed as an EAR file. The EJB descriptors should be inside the META-INF of the ejb-module.
See this link for the EAR structure for more details.
http://docs.oracle.com/cd/E24329_01/web.1211/e24368/splitcreate.htm#i1103260
Related
There are some libraries in ORACLE_HOME/oracle_common folder which are creating issues with our deployment (EAR). (in particular jps-ee.jar file).
How do I overwrite my weblogic server (not via web.xml) to not use the libs available (particularly jps-ee.jar) for my EAR Deployment.
We need to disable it from the weblogic end so that we can test that , this jps-ee.jar is the root cause of our issue.
So how can we do it from the weblogic end ?
And docs or steps by step guide ?
Found solution to this problem, weblogic is configured to use oralce_common using setDomainEnv.sh (or setDomainEnv.cmd based on OS)
/%ORACLE_HOME%/Middleware/user_projects/domains/%WEBLOGIC_DOMAIN%/bin/setDomainEnv.sh
This file defines the class path to be used for starting up a domain.
This file is called in by startWeblogic script to set up domain related settings.
Which loads the class paths and pass it to JVM when running the weblogic server.
If you want the weblogic server to start looking for some dependency packages from your ear/war file first, then you must use application.xml or weblogic.xml depending on whether your archive is an ear or a war.
Here is an example;
application.xml
<?xml version = '1.0' encoding = 'UTF-8'?>
<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd" xmlns="http://www.bea.com/ns/weblogic/weblogic-application">
<prefer-application-packages>
<package-name>oracle.toplink.*</package-name>
<package-name>oracle.sql.*</package-name>
<package-name>oracle.jdbc.*</package-name>
</prefer-application-packages>
weblogic.xml
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
<weblogic-version>12.1.3.0.0</weblogic-version>
<context-root>sth</context-root>
<container-descriptor>
<prefer-web-inf-classes>false</prefer-web-inf-classes>
<prefer-application-packages>
<package-name>oracle.toplink.*</package-name>
<package-name>oracle.sql.*</package-name>
<package-name>oracle.jdbc.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
</prefer-application-resources>
</container-descriptor>
prefer-application-packages and prefer-application-resources are the two tools you can use for this purpose in weblogic environments. Weblogic first uses these packages in your archive file when looking a class and if not found, then it uses its embedded dependencies.
Good luck!
I am migrating my RESTful web application from GlassFish4.1 to WildFly9.0 for the first time.
Initially, I suffered deployment issues due Jersey dependencies. To overcome that problem, I simply replaced said project dependencies with RESTEasy equivalents inside of the pom.xml file. In doing so, my application became deployable -- and according to (WildFly_base)/standalone/log, and the applications themselves -- are working as expected.
Additionally, I added a jboss-web.xml configuration file to my WEB-INF folder:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-web PUBLIC "http://www.jboss.org/j2ee/dtd" "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">
<jboss-web>
<context-root>myprojectstart</context-root>
</jboss-web>
The hello-world page can be reached # http://ipaddress:8080/myprojectstart.
... however, I cannot view my web services # http://ipaddress:8080/myprojectstart/getData, just like I could when using GlassFish-4.1.
So; what am I missing?
Note: I use #annotations like:
#ApplicationPath("/*")
#Path("/getData")
No seperate .xml business here
I don't think RestEasy supports * in ApplicationPath. If you remove that it should work fine.
I have a WAR file with the following structure:
The JSF managed bean BusinessObjectTypeListController is located in commons-web-1.0.jar in /WEB-INF/lib and referenced in BusinessObjectTypeListView.xhtml. When I run my web application and I call that view, I get the following error:
javax.servlet.ServletException: /view/common/businessObjectTypeListView.xhtml #34,94 listener="#{businessObjectTypeListController.selectData}": Target Unreachable, identifier 'businessObjectTypeListController' resolved to null
Why isn't the controller class found? It should be in the classpath, is it?
You need to have a JSF 2.0 compliant /META-INF/faces-config.xml file in the commons-web-1.0.jar file in order to get JSF to scan the JAR file for classes with JSF annotations like #ManagedBean and auto-register them.
<?xml version="1.0" encoding="UTF-8"?>
<faces-config
xmlns="http://java.sun.com/xml/ns/javaee"
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-facesconfig_2_0.xsd"
version="2.0">
</faces-config>
JSF does namely not scan every class of every single JAR file in the classpath, that would have been too expensive. Only JARs with the above /META-INF/faces-config.xml file will be scanned.
You should also ensure that you do not have the metadata-complete="true" attribute in the <faces-config> declaration of webapp's own /WEB-INF/faces-config.xml file, otherwise JSF will assume that this faces config is complete and therefore won't auto-scan JAR files for annotations.
If none of those conditions are (or can be) met, then you need to manually register the bean as <managed-bean> in webapp's own /WEB-INF/faces-config.xml instead of relying on annotations.
See also chapter 11.4.2 of JSF 2.0 specification (emphasis mine).
11.4.2 Application Startup Behavior
...
This algorithm provides considerable flexibility for developers that are assembling the components of a JSF-based web
application. For example, an application might include one or more custom UIComponent implementations, along with
associated Renderers, so it can declare them in an application resource named “/WEB-INF/faces-config.xml”
with no need to programmatically register them with Application instance. In addition, the application might choose
to include a component library (packaged as a JAR file) that includes a “META-INF/faces-config.xml” resource.
The existence of this resource causes components, renderers, and other JSF implementation classes that are stored in this
library JAR file to be automatically registered, with no action required by the application.
I have same problem with CDI beans in my case.
I have common.jar project where i placed the CDI beans. (without beans.xml)
and
I have webapp.war that contains common.jar in it`s lib and beans.xml.
when i call a cdi bean from jsf, i get it is not reachable exception:/
project structure is created using maven :
- maven-archetype-quickstart for common.jar
- maven-archetype-webapp for webapp.war
I am using eclipse/juno en deploy to Glassfish 3.1.x.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Resolved:
For EJB and JAR packaging you should place the beans.xml in src/main/resources/META-INF/.
For WAR packaging you should place the beans.xml in src/main/webapp/WEB-INF/.
Remember that only .java files should be put in the src/main/java and src/test/java directories. Resources like .xml files should be in src/main/resources.
from topic:
CDI: beans.xml, where do I put you?
In my opinion the class BusinessObjectTypeListController is founded properly but does not instantiated.
How you create the instance of class on a view? If you use a BeanFactory review the config xml files
I have an EJB3 project to be deployed on JBoss 5.1.0 GA. I have Stateless EJBs being injected into other Stateless beans and Servlets.
I'm using the #EJB annotation without any parameters to inject the EJB beans, (i have a test project just to simulate the injection, which works).
When i try deploying i get the error below.
"Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Resolution should not happen via injection container"
I have searched but can't seem to find/pinpoint the cause of the error.
Update: 1
Both the EJB jar and WAR are deployed in the same EAR. I'm using the JEE5 archtype, http://code.google.com/p/javaee5-maven-archetype/ to create both the main project and test. The default code generated by the archtype works, and there is no need to specify the JNDI name in the #EJB injection.
Update: 2
The full deployment stacktrace, http://pastebin.com/CknXie13
Here's an oft overlooked gotcha: Make sure that you use the name of the Local Interface and not the implementation when declaring the class type of the EJB in the servlet or web service. So, the mappedName in JBOSS will point to the jndi binding for the implementation while the class type in the declaration will point to the interface. For example:
#EJB(mappedName="Foo/EmployeeManagerBean/local")
EmployeeManagerLocal manager;
Gotcha #2: Make sure that you are compiling with Java 1.6 or higher. This can be tricky in Eclipse. You have to check three places in Project->Properties to make sure: Project Facets, compiler compliance settings, and the build path.
Use the mappedName attribute of #EJB annotation, while injecting into the servlet
The attribute should contain the jndi name of the ejb.
Please check your web.xml version. Version 2.4 or earlier does not support dependency injection.
Here is the sample excerpt of version="2.5"
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" 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">
Are you putting your servlet in .WAR file? Put your servlet in .WAR file and your bean in .JAR file. Create and ear file and then deploy it
Known Issue;
http://community.jboss.org/message/8196#8196
https://jira.jboss.org/browse/JBAS-6332
I need to create a startup class in Websphere. This class is present in abc.jar. And also abc.jar requires log4j.jar at startup of server.
For above scenario, i have created the startup class with abc.jar in classpath in websphere console and I kept log4j.jar in ext folder of WAS. This works for me.
But problem is that the other profiles share same ext folder of WAS and does not able to start up due to Log4j.jar.
If I keep Log4j.jar in other place and keep that location in classpath. Startup class will not fails.Please help me.
If your application uses EJBs, then you can use a peculiar feature of WAS with the ibm-ejb-jar-ext.xml descriptor, which includes a start-at-app-start element:
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-ext
xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-ext_1_1.xsd"
version="1.1">
<session name="TestBean">
<start-at-app-start value="true"/>
</session>
</ejb-jar-ext>
I'm not very familiar with WebSphere and maybe I do not fully understand your problem - but how about deploying a webapp with a startup servlet defined in web.xml?
Here's what I mean:
create a abc.war with abc.jar and log4j.jar copied to abc.war/WEB-INF/lib
define your startup class in abc.war/WEB-INF/web.xml as follows:
<web-app id="WebApp">
<display-name>abc.war</display-name>
<servlet>
<servlet-name>ABCStartupServlet</servlet-name>
<display-name>ABCStartupServlet</display-name>
<servlet-class>abc.ABCStartupServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
...
That way you have log4j.jar and abc.jar together in one place, you can use the WebSphere classloader settings if another log4j version causes problems and your class is called during the startup of the server.