I've ported an application from JEE6 to JEE7 (glassfish 3.1.2.2 to 4.1),
I've upgraded the META-INF/validation.xml with latest version (as stated here): http://antoniogoncalves.org/2013/06/04/java-ee-7-deployment-descriptors/):
<validation-config
xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration validation-configuration-1.1.xsd"
version="1.1">
<message-interpolator>com.infomaxgroup.adaecommerce.validation.DatabaseMessageInterpolator</message-interpolator>
</validation-config>
The custom messageinterpolator is never called, so I've tried to set a name of a non existent class:
<message-interpolator>foo.foo.foo.Bar</message-interpolator>
and tried to insert an error (xxx after the opening tag):
<message-interpolatorxxx>foo.foo.foo.Bar</message-interpolator>
I've no exception into log, seems like that validation.xml (that my JEE6 application processes good) is not loaded at all into my ported JEE7 application...
Any idea on how to solve the issue ?
Many thanks in advance...
Solved from myself,
the problem was that validation.xml must be placed into META-INF/validation.xml folder of the "ejb module", into my JEE6 application I had that file into WEB-INF folder of the "web module" (strangely the JEE6 application works good...), now my JEE7 application correctly load validation.xml configuration and works using the message interpolator, very good !
Related
Hi everyone!
I am developing Spring Boot 1.5 app with Hibernate Search 5.5. As standalone app it is running as I expected, but I have a problem with deploying it on Wildfly 10. During deployment it is throwing an exception: java.util.ServiceConfigurationError: org.hibernate.integrator.spi.Integrator: Provider org.hibernate.search.hcore.impl.HibernateSearchIntegrator not a subtype
I want to disable Wildfly Hibernate Search implementation and provide my own prepackaged with my app.
I have found that I have to provide wildfly.jpa.hibernate.search.module = none property in in persistence.xml file. My question is how to do this without rewriting whole Spring Boot datasource autoconfiguration?
Finally I have found solution to force Wildfly not to load provided Hibernate Search module. I have read in Wildfly 10 documentation in chapter Class Loading in Wildfly, about providing jboss-deployment-structure.xml file. During building WAR file with my app I am adding this file in META-INF directory with following content:
<?xml version="1.0"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="org.hibernate.search.orm"/>
</exclusions>
</deployment>
</jboss-deployment-structure>
This configuration solved my problem and Wildfly is loading Hibernate Search packaged with my app.
Try adding this to your application.yaml:
spring.jpa.properties:
wildfly.jpa.hibernate.search.module: none
See an example of a Spring Boot application with Hibernate Search here.
It does not use WildFly, though.
When injecting a simple CDI managed bean into a servlet (starting from the generated code sample "SimpleServlet"), when accessing the servlet, Bluemix Liberty logs this error :
"SimpleServlet cannot be injected as class
wasdev.sample.servlet.SimpleServlet is not in a bean archive."
This is so even when a beans.xml file with discovery "all" is used.The target looks like this
Reason for Error :
The error is due to not having a beans.xml in the built application war i.e. JavaHelloWorldApp.war
Currently, for performance reasons, the beans.xml file is always required in order to use CDI on Bluemix.
Solution :
Copied the bean.xml inside the /src/main/webapp/WEB-INF/beans.xml then built the code.
This made sure that the bean.xml is packaged into the war file i.e. JavaHelloWorldApp.war and the error is resolved.
To verify bean.xml is deployed correctly to Bluemix, select the java application on Bluemix console, click and open the java application dashboard. Select Runtime, select Files tab, browse and verify that the bean.xml is deployed correctly inside WEB-INF as shown in the snapshot below.
We are integrating an internal framework into our weblogic application and we are running into deployment problems.
Technologies Used
Weblogic 10.3.6 application
Spring 3.0
Maven 2
Eclipse J2EE
The Problem
On startup of the weblogic application, we receive the following NoSuchMethodError while initializing one of the beans. This error is occuring when calling classes in the org.joda.time (2.0) jar.
Caused By: java.lang.NoSuchMethodError: org.joda.time.DateTimeZone.convertLocalToUTC(JZ)J
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:715)
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:690)
. . . excluded . . .
Things We Have Tried
After Googling "NoSuchMethodError spring", many of the problems seem to be incompatible Spring versions. After printing the dependency tree, the only Spring version in use is 3.0.
Googling "NoSuchMethodError" usually gave JAR hell solutions.
Multiple versions of the same dependency. After doing some maven dependency management, the only joda-time jar in use is 2.0. Additionally, the local repository was purged of any unnecessary jars.
.war / runtime may not have the correct jars included in the lib directory. After looking into the WEB_INF/lib directory, the only joda-time jar is version 2.0, which contains all of the appropriate class files
One mysterious thing is that the DateTimeZone.convertLocalToUTC(JZ)J has been a part of the org.joda.time project since 1.0, so even if we have incompatible versions, the method should still be found, especially if the class and package are able to be found.
Finally there are no other DateTimeZone classes in the project (ctrl+shift+T search in eclipse) so I'm confused as to which class is being loaded if the org.joda.DateTimeZone class is not being loaded.
Questions:
Can anyone explain why the method could not be found?
Are there more places to check for existing or conflicting jars?
Is there a way to check the DateTimeZone class that the LocalDate class is using during runtime via Eclipse debug?
Here's some interesting reading:
prefer-web-inf-classes Element
The weblogic.xml Web application deployment descriptor contains a
element (a sub-element of the
element). By default, this element is set to
False. Setting this element to True subverts the classloader
delegation model so that class definitions from the Web application
are loaded in preference to class definitions in higher-level
classloaders. This allows a Web application to use its own version of
a third-party class, which might also be part of WebLogic Server. See
“weblogic.xml Deployment Descriptor Elements.”
taken from: http://docs.oracle.com/cd/E15051_01/wls/docs103/programming/classloading.html
Other troubleshooting tips:
You can try: -verbose:class and check your managed server's logs to check if the class is being loaded properly.
An efficient way to confirm which intrusive jar might be getting loaded is by running a whereis.jsp within the same webcontext (i.e., JVM instance) of this app.
--whereis.jsp --
<%# page import="java.security.*" %>
<%# page import="java.net.URL" %>
<%
Class cls = org.joda.time.DateTimeZone.class;
ProtectionDomain pDomain = cls.getProtectionDomain();
CodeSource cSource = pDomain.getCodeSource();
URL loc = cSource.getLocation();
out.println(loc);
// it should print something like "c:/jars/MyJar.jar"
%>
You can also try jarscan on your $WEBLOGIC_HOME folder to see if you can find the jar that contains this class: https://java.net/projects/jarscan/pages/Tutorial
A NoSuchMethodError is almost always due to conflicting library versions. In this case I'm guessing there are multiple versions of joda libraries in the two projects.
Weblogic is pulling the org.joda jar.
Tryu adding this in your weblogic.xml to exclude the jar that weblogic is pulling, and instead use your appllication jar.
The below is from my application, you can have a look what all we have to removed for our application.
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>antlr.*</wls:package-name>
<wls:package-name>org.slf4j.*</wls:package-name>
<wls:package-name>org.slf4j.helpers.*</wls:package-name>
<wls:package-name>org.slf4j.impl.*</wls:package-name>
<wls:package-name>org.slf4j.spi.*</wls:package-name>
<wls:package-name>org.hibernate.*</wls:package-name>
<wls:package-name>org.springframework.*</wls:package-name>
<wls:package-name>javax.persistence.*</wls:package-name>
<wls:package-name>org.apache.commons.*</wls:package-name>
<wls:package-name>org.apache.xmlbeans.*</wls:package-name>
<wls:package-name>javassist.*</wls:package-name>
<wls:package-name>org.joda.*</wls:package-name>
<wls:package-name>javax.xml.bind.*</wls:package-name>
<wls:package-name>com.sun.xml.bind.*</wls:package-name>
<wls:package-name>org.eclipse.persistence.*</wls:package-name>
</wls:prefer-application-packages>
<wls:show-archived-real-path-enabled>true</wls:show-archived-real-path-enabled>
</wls:container-descriptor>
I am learning "how to create portal application", went through some documents and tutorials. I found we need one application server, one portal container and one IDE.
please help me to understand it.
I want to create a portlet and deploy it on weblogic server. so what the things i required.
means: any plugin in eclipse
portlet container
application server
etc.....
Thanks
I've just got the pluto portlet container up and running. The tutorials for pluto are a bit sketchy and most contain errors that can throw you off course. As such, I've made this as thorough as I can.
I've since managed to get pluto running under WebLogic, albeit not perfectly (discussed later). So, I think your aims are:
Install a portlet container: e.g. pluto
Create a HelloWorld portlet, deploy it and publish it
Perhaps, deploy the portlet so that it runs under WebLogic? Not sure if this is what you intend.
Portlet communication
Build more heavyweight portlets that do what you want
Upgrade portal implementation (e.g. JetSpeed)
So, here goes:
1. Install a portlet container: e.g. pluto
I recommend you start with the pluto portlet as this is the reference implementation and adheres to version 2 of the spec (JSR-286). Download the binary distribution from:
http://portals.apache.org/pluto/v20/getting-started.html
This comes housed within a tomcat 6 webserver. So, to run a basic portlet, you just need to configure and start tomcat. The pluto web application can be found in the webapps directory.
To understand more about tomcat, see here:
http://www.puschitz.com/InstallingTomcat.html#InstallingTomcatSoftware
Note that this is slightly complicated (for good reason) as it recommends creating separate instances of tomcat. This tutorial really only takes an hour though so I'd recommend it in advance of your portlet work so that you have a good foundation.
In simple terms though, to start up pluto (well, tomcat), you just need to set your ${CATALINA_HOME} to be your tomcat installation directoy (pluto-2.0.2) and execute {pluto_install_dir}/bin/startup.sh. You can access the pluto portal from a browser with:
http://localhost:8080/pluto/portal
2. Create a HelloWorld portlet, deploy it and publish it
Happily, the pluto tutorial is nearly good enough to get you going. Unbelievably, all the tutorials I found had flaws or errors. With a little help, you should get this going though. It is at the same place:
http://portals.apache.org/pluto/v20/deploying.html
The directory structure shown under "Portlet Assembly" is slightly wrong. The webapp folder should be at the same level as the java folder, under main.
Here is a sample HelloWorld portlet that presents using direct output in the response (like a servlet):
package com.mycompany.portlet;
//imports omitted...
public class HelloWorldPortlet extends GenericPortlet{
protected void doView(RenderRequest request,RenderResponse response)
throws PortletException, IOException {
response.setContentType("text/html");
response.getWriter().println("Hello World");
}
}
Here's an example WEB-INF/portlet.xml:
<?xml version="1.0" encoding="UTF-8"?>
<portlet-app
xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd
http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">
<portlet>
<description>HelloWorld Description</description>
<portlet-name>HelloWorldPortlet</portlet-name>
<display-name>Hello World Display Name</display-name>
<portlet-class>com.mycompany.portlet.HelloWorldPortlet</portlet-class>
<expiration-cache>-1</expiration-cache>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>VIEW</portlet-mode>
</supports>
<supported-locale>en</supported-locale>
<portlet-info>
<title>Hello World</title>
<short-title>Hello World</short-title>
<keywords>Hello,pluto</keywords>
</portlet-info>
</portlet>
</portlet-app>
Here's an example WEB-INF/web.xml:
<web-app id="WebApp_ID">
<display-name>Hello World Portlet</display-name>
<taglib>
<taglib-uri>http://java.sun.com/portlet</taglib-uri>
<taglib-location>tld/portlet.tld</taglib-location>
</taglib>
</web-app>
Put portlet.tld (the prtlet 2.0 version) in your tld directory. Note we aren't using JSPs so this will be empty. For a good (but broken) JSP based tutorial, see here:
http://www.ibm.com/developerworks/java/library/j-pluto/
Build using the mvn build script supplied in:
http://portals.apache.org/pluto/v20/deploying.html
If you don't add the automatic deployment section of the build script the move the build war to your pluto (tomcat) webapps.
Within your browser, you must publish your new HelloWorld webapp from the admin page within the pluto portal (add page -> add portlet). A new tab should be added containing your portlet.
3. Deploy the portlet under WebLogic
Add the pluto libraries to your WebLogic lib. I put these in your domain library directory (which contains a readme indicating this is for adding jars to be dynamically loaded on 10.2.3). This is ${MYDOMAIN}/lib. The jars to locate there are as follows:
http://portals.apache.org/pluto/v20/embedding.html
Add the pluto web application and any referenced (published) webapps into your WLS upload directory. This means including testsuite which is provided with pluto and your new helloworld webapp.
Configure WLS to be able to access your portlets:
The pluto webapps are security configured for users pluto and tomcat. So, you have to add a new "pluto" user to your WLS security realm [Security Realms -> myRealm]
Configure webapp security to map the security role to the WLS user. This means creating ${MYUPLOAD}/pluto/WEB-INF/weblogic.xml. Here add a "security-role-assignment" entry for principal pluto (your new WebLogic user).
Note that the testsuite/WEB-INF/web.xml is only authorised for user tomcat. Change this to pluto.
Add portlet_2_0.tld to ${UPLOAD}/testsuite/WEB-INF/tld (make tld dir). This is available at: http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/trunk/jetspeed-portal-resources/src/main/resources/tld/portlet_2_0.tld
Several of the testsuites will still fail under WLS. There are outstanding issues between apache and the community. They see it as a WLS issue (on the apache pluto jira at https://issues.apache.org/jira/browse/PLUTO-571).
There is an issue where by the portlet is actually presented outside the portlet frame (div) when using JSP rendering. Not got to the bottom of this yet.
4. Portlet Communication
Have two portlets interoperating. Refer to:
http://publib.boulder.ibm.com/infocenter/wpexpdoc/v6r1/index.jsp?topic=/com.ibm.wp.exp.doc_v6101/dev/pltcom_pubrndrprm.html
5. Build more heavyweight portlets
Refer to more complex webapp tutorial using JSPs at:
http://www.ibm.com/developerworks/java/library/j-pluto/
//Warning: portlet 1.0 (JSR-168) and contains errors
Then try your own...
6. Upgrade portal implementation
Try out JetSpeed for example. Refer to:
http://portals.apache.org/jetspeed-2/
I am getting the following error when deploying an application on JBoss 4.2.1
7:05:59,673 ERROR [Application Name]StandardWrapper.Throwable
java.lang.IllegalStateException: Application was not properly initialized at
startup, could not find Factory: javax.faces.context.FacesContextFactory
I browsed the net and I found many posts which suggested to add an entry in web.xml but that entry was already there. And all the required libraries are there in web-inf.
So any solutions anybody ?
Ensure that your classpath is clean (i.e. no duplicate different versioned classes/JAR files, keep in mind that JBoss ships with builtin JSF libraries!) and that your web.xml is declared as at least Servlet 2.3.