I have a Liferay job written using this guide. I am running liferay-ce-portal-tomcat-7.0-ga3. The job uses DLAppServiceUtil to work with document library.
The job starts exactly as scheduled. But the problem is this exception:
Exception in thread "liferay/scheduler_dispatch-407" java.lang.NoClassDefFoundError: com/liferay/portlet/documentlibrary/service/DLAppServiceUtil
What's wrong?
My pom.xml is:
<!-- ... -->
<dependency>
<groupId>com.liferay.portal</groupId>
<artifactId>portal-service</artifactId>
<version>7.0.0-nightly</version>
<scope>provided</scope>
</dependency>
<!-- ... -->
My job class is:
public class MyJob implements MessageListener {
#Override
public void receive(Message message) throws MessageListenerException {
// DLAppServiceUtil usage...
}
}
How can I fix it?
In Liferay 7, do not use the serviceUtil classes any more (provided you write an OSGi bundle).
Instead add
#Reference
DLAppService dlAppService;
to your component class. Look up how to make the listener a proper OSGi component. Liferay's blade-samples on github might have a template. I am on my phone which makes it hard to look up&explain everything in more detail.
If this doesn't work (as you indicate in your comment), you'll have to check your build process: Make sure that the plugin's Manifest declares the dependencies that it has on the required service. From this you can see that I'm recommending to build OSGi plugins - I'm assuming that you're not doing this, because OSGi would not start your plugin until the dependencies are resolved.
You can do so by utilizing bnd. Check the numerous Maven examples within the blade-samples for more detail.
The classes are no longer part of portal-service, com.liferay.portal.kernel is the correct artifact.
Weird that IDE doesn't complain...
Related
How can we do when use onmifaces in the case of spring boot apps?, where the error pages declaration is made at EmbeddedServletContainerCustomizer class?
#Override
public void customize(ConfigurableEmbeddedServletContainer container) {
MimeMappings mappings = new MimeMappings(MimeMappings.DEFAULT);
mappings.add("eot", "application/vnd.ms-fontobject");
mappings.add("ttf", "application/x-font-ttf");
mappings.add("woff", "application/x-font-woff");
mappings.add("woff2", "application/x-font-woff2");
container.setMimeMappings(mappings);
container.addErrorPages(new ErrorPage(HttpStatus.NOT_FOUND, "/error.xhtml"));
container.addErrorPages(new ErrorPage(FaceletException.class, "/error.xhtml"));
container.addErrorPages(new ErrorPage(Throwable.class, "/error.xhtml"));
}
I have analized findErrorPageLocation and it uses WebXml that parses web.xml files.
The Servlet API in its current version does not support programmatically defining and obtaining error pages. That's why OmniFaces had to manually parse web.xml.
OmniFaces does not and will not support Spring specific APIs. I recommend to just keep using web.xml for error page configuration so that non-Spring libraries will be able to share them.
I am facing the problem with loading J2K image files (jp2, jp2000) in my java application. What is strange is the fact, that the application runs correctly (the file is successfully read from disk) when it runs as standalone java application (or in tests).
After deployment on Tomcat application server the ImageIO.read(..) method returns null every time.
Any help is appriciated.
Shimon
Update: After reviewing comment from #haraldK - the solution is well described on page https://github.com/haraldk/TwelveMonkeys (section Deploying the plugins in a web app).
You need to define listener in your web.xml:
<web-app ...>
...
<listener>
<display-name>ImageIO service provider loader/unloader</display-name>
<listener-class>com.twelvemonkeys.servlet.image.IIOProviderContextListener</listener-class>
</listener>
...
</web-app>
You also need to add this Maven dependency to your project:
<dependency>
<groupId>com.twelvemonkeys.servlet</groupId>
<artifactId>servlet</artifactId>
<version>3.0.2</version>
</dependency>
Other, less prefered solution is (this was my first solution mentioned here):
After doing some googling I have found this page - https://blog.idrsolutions.com/2013/03/getting-jai-jpeg2000-to-run-on-glassfish-server-without-a-npe/ which discribes problem of resolution of J2K imageio service provider, when using application server such as glassfish or tomcat.
According to this article, the solution is simple. Just use the reader directly:
public BufferedImage getJPEG2000Image(byte[] data){
ImageInputStream iis = null;
BufferedImage image=null;
try {
iis = ImageIO.createImageInputStream(new ByteArrayInputStream(data));
com.sun.media.imageioimpl.plugins.jpeg2000.J2KImageReaderSpi j2kImageReaderSpi = new com.sun.media.imageioimpl.plugins.jpeg2000.J2KImageReaderSpi();
com.sun.media.imageioimpl.plugins.jpeg2000.J2KImageReader j2kReader = new com.sun.media.imageioimpl.plugins.jpeg2000.J2KImageReader(j2kImageReaderSpi);
j2kReader.setInput(iis, true);
image = j2kReader.read(0, new com.sun.media.imageio.plugins.jpeg2000.J2KImageReadParam());
}
catch (Exception e){
e.printStackTrace();
}
return image;
}
This Maven dependency is needed as well:
<dependency>
<groupId>com.sun.media</groupId>
<artifactId>jai_imageio</artifactId>
<version>1.1</version>
</dependency>
I'm running an EAR with EJB + EJB + WAR deployment in JBoss WildFly 8.2.0.Final with JSF 2.2 and RichFaces 4.5.2.Final. My problem is, that all RichFaces resources fail to load properly in the client. The generated URL don't resolve and return with HTTP 404.
The deployment is build upon Maven und results in the following structure:
The reason for using <scope>compile</scope> in the EJB module and not the WAR is that I need to extend RichFaces classes from within my EJB module. We've build a dynamic form generator based on some of the components.
As soon as I add JARs to EAR/lib/ and WAR/WEB-INF/lib/ by using <scope>compile</scope> instead of <scope>provided</scope> in the WAR module I get the following stacktrace while starting the application server:
Caused by: java.lang.IllegalArgumentException: Multiple entries with same key: interface javax.validation.constraints.Min=org.richfaces.javascript.LibraryFunctionImplementation#c77af4e and interface javax.validation.constraints.Min=org.richfaces.javascript.LibraryFunctionImplementation#5a903150
at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:150)
at com.google.common.collect.RegularImmutableMap.checkNoConflictInBucket(RegularImmutableMap.java:104)
at com.google.common.collect.RegularImmutableMap.<init>(RegularImmutableMap.java:70)
at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:254)
at org.richfaces.javascript.ClientServiceConfigParser.parseConfig(ClientServiceConfigParser.java:75)
at org.richfaces.application.ValidatorModule.createClientScriptService(ValidatorModule.java:65)
at org.richfaces.application.ValidatorModule.configure(ValidatorModule.java:60)
at org.richfaces.application.ServicesFactoryImpl.init(ServicesFactoryImpl.java:60)
at org.richfaces.application.InitializationListener.createFactory(InitializationListener.java:110)
at org.richfaces.application.InitializationListener.onStart(InitializationListener.java:69)
at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:167)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2190)
at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303)
at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294)
at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:692)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:260)
... 9 more
How can I solve this problem?
Frontend artifacts don't belong in EAR's /lib. They belong in WAR's /WEB-INF/lib. It would otherwise make the backend (the EJB) totally unreusable on other frontends (other WARs), such as Spring MVC, JAX-RS RESTful, "Plain vanilla" JSP/Servlet, etc..etc.. Using/importing JSF FacesContext and friends such as Servlet's HttpServletRequest in an EJB class is already a seriously big red alert. You should not be doing that.
Move that code to WAR. Or, if you intend to make it reusable across various WARs, make it a web fragment project instead which can then end up as another JAR in /WEB-INF/lib.
See also:
JSF Service Layer
I am using the WebSphere Liberty Profile server, version 8.5.5.3. I have an ear containing multiple wars. I deploy them all exploded (ear and the war's of the modules inside it as well).
When deploying it I get the following class cast exception:
java.lang.RuntimeException: javax.xml.bind.JAXBException:
ClassCastException: attempting to cast bundleresource://67.fwk-1166858817/javax/xml/bind/JAXBContext.class
to jar:file:/C:/ws/IBM/java_1.7_64/jre/lib/rt.jar!/javax/xml/bind/JAXBContext.class.
Please make sure that you are specifying the proper ClassLoader.
I figured that the problem is that my bundled jax-api and jaxb-impl jars are not loaded, so I added to the server.xml the parentLast class loading option:
<enterpriseApplication id="ear-app" location="C:/ws/ear/exploded/ear-app.ear" name="ear-app" >
<classloader delegation="parentLast" commonLibraryRef="provided-jars" privateLibraryRef="shared-libs"/>
</enterpriseApplication>
I added my jax-api and jax-impl jars to this folder
<library id="shared-libs">
<fileset dir="${server.config.dir}/lib/global" include="*.jar"/>
</library>
However I still have the ClassCastException, it looks like it is still using the parentFirst classloading?
I found other jaxb ClassCastException threads, but not when using the Liberty profile..
Maybe it is a typo, but in your post you have delegation="parentFirst" instead of parentLast.
Did you check to just change delegation for application like this:
<enterpriseApplication id="ear-app" location="C:/ws/ear/exploded/ear-app.ear" name="ear-app" >
<classloader delegation="parentLast"/>
</enterpriseApplication>
For more details see Overriding a provided API with an alternative version
I worked aroud the problem by not using the parentLast. Thanks for the help.
I am using JSF 2.0 and Liferay 6.1
On any kind of request to any Java class my init() is getting called. Even in case of PrimeFaces component calls for its related PrimeFaces Java method. This method should be called only once when my portlet will initialize.
#ManagedBean
#ViewScoped
public class MyMangedBean {
public void init() {
System.out.println("Init method called");
}
}
Please help me to find out possible solution.
EDIT
I found the component behind this cause
In my xhtml file I have
<bridge:inputFile id="MyFileUpload" size="50"
binding="#{myBean.toBeUploadFile}" onchange="{fileSelected(this);}" style="position: absolute;height: 29px;width:107px;opacity:0;filter: alpha(opacity=0);z-index:100;"/>
Whenever I remove its binding attribute. My project works fine. It will not call init() multiple times. But I need this attribute to get my file uploaded.
I have kept xml namespace as
xmlns:bridge="http://portletfaces.org/bridge"
I have also kept dependency for commons-io(version 1.3) and commons-filedownload(1.2.1) in pom.xml
I dont know what else I am missing for this component or what is actual cause behind this.
You should consider using the bridge:inputFile tag that comes with the latest release of Liferay Faces instead of the older obsolete tags that come from portletfaces.org.
There is a nice demo here that uses the bridge:inputFile that you can try on a Liferay tomcat portal instance, and then follow the same pattern that it uses for file upload.
That demo has been tested, it works great, and it is supported by Liferay.
There are many more demos that are tested and working well on Liferay Portal 6.1. You can download the source for them and build them for yourself as shown here. And follow the version scheme here to make sure that you align the correct versions of the Portal, Mojarra, and the Liferay Faces Bridge.
Hope that helps.