When I try to invoke local EJB I get EJBAccessException running my migrated Glassfish web application on Wildfly 8.2. I found the JBoss documentation all other than strait forward and need help, i.e. no link to JBoss documentation please.
I have no #DeclareRoles notation on my EJB to make it simple for now. I tried with and without using the security realm other adding jboss-web and jboss-ejb3 to tie the bean to a realm. But I still get the same exception.
I've read these tutorials, but can't get it to work. I am using MongoDB and JDBC security realm setup don't help me much. But for now I bypass the user-role authentication.
Migrating a Java EE App from GlassFish to WildFly
Invoke EJB from WildFly safely
And others
How can I run local EJB on Wildfly in my web application?
#Stateless
public class MyBean {
public String sayHello() {
...
jboss-web.xml
<jboss-web>
<security-domain>other</security-domain>
</jboss-web>
jboss-ejb3.xml
<assembly-descriptor>
<s:security>
<!-- Even wildcard * is supported -->
<ejb-name>*</ejb-name>
<!-- Name of the security domain which is configured in the EJB3 subsystem -->
<s:security-domain>other</s:security-domain>
</s:security>
</assembly-descriptor>
In WildFly 8, such methods which have no explicit security configurations, in a secured bean, will be treated similar to a method with #DenyAll configuration.
This behaviour can be controlled via the jboss-ejb3.xml deployment descriptor at a per bean level or a per deployment level as follows:
<?xml version="1.0" encoding="UTF-8"?>
<jboss:jboss
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:s="urn:security:1.1"
version="3.1" impl-version="2.0">
<assembly-descriptor>
<s:security>
<!-- Even wildcard * is supported where * is equivalent to all EJBs in the deployment -->
<ejb-name>FooBean</ejb-name>
<s:missing-method-permissions-deny-access>false</s:missing-method-permissions-deny-access>
</s:security>
</assembly-descriptor>
</jboss:jboss>
Setting missing-method-permissions-deny-access to false allows access to such methods for all users i.e. the behaviour will be switched to be similar to #PermitAll.
Related
Just started doing my first steps with FacesFlow with Glassfish 4.1 (i.e. using Mojarra) and when invoking my flow I get an error named
[SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.application] ... Error Rendering View[/register/register.xhtml]
org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.FlowScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:708)
Several others had that error too as I can see in the web but the solutions that worked for other somehow dont work for me (see below).
I also tried #SessionScoped which works. So it is related to #FlowScoped.
To what I read in a book that I use to get me up to speed I should be ok from coding and config end since according to API #FlowScoped is CDI based and I use the following code at my backing bean/controller.
#Named
#FlowScoped(value="register")
public class RegisterController implements Serializable {
I have a flow named register whose pages are located in a dirctory /register and the first page of the flow is named register.xhtml
Following snippet I tried both as a register/register-flow.xml config file as well as WEB-INF/faces-config.xml without success.
<?xml version="1.0" encoding="UTF-8"?>
<faces-config
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/web-facesconfig_2_2.xsd"
version="2.2">
<flow-definition id="register">
<flow-return id="overview">
<from-outcome>/index</from-outcome>
</flow-return>
</flow-definition>
</faces-config>
What I tried so far:
I found a post suggesting that <Context antiJARLocking="true" path="/PROJEST_NAME"/> would solve the problem but after googling the tag it turns out its an outdated Tomcat tag.
Changing #Named to #ManagedBean didn't really help as suggested on one page. I could open the pages but the data in my controller class would not be available when invoking the next page of the flow anymore. But #ManagedBean shouldn't really work I guess since #FlowScoped is CDI based.
Another post suggested to ensure that javax.faces.CLIENT_WINDOW_MODE is enabled. I tried that via adding the following to my web.xml but without success
<context-param>
<param-name>javax.faces.CLIENT_WINDOW_MODE</param-name>
<param-value>url</param-value>
</context-param>
Another suggested to use Glassfish 4.x which I already do
Any ideas?
With Glassfish 4.1 at least you need to add the cdi-api.jar directory library.
Glassfish includes the weld-osgi-bundle.jar but it also needs cdi-api.jar to work because the CDI bean scopes aren't in the weld-osgi... so make sure you have it if not its here:
[gf_installation_path]/glassfish/modules/cdi-api.jar
This will give you access to the packages used with CDI Beans i.e., javax.enterprise.context.*
If not then probably
this could help
and this
GL!
Edit: The only technologies required to reproduce this issue are JSF 2.2 and Spring Boot 1.2.1 + Its embedded Tomcat 8.0.5 server. Everything else listed in this question is just to give context on the tech I'm using.
Update #2: Following along with BalusC's thoughts, I ported my sample custom component into a barebones Servlet 3.1 + JSF 2.2 application. You can find the code for it on Github here.
This simple case does not exhibit the issue I'm describing here. The #FacesComponent annotation works. This heavily implies that the problem is being caused either by Spring 4.1.2 or Spring Boot itself. It's getting late, so I'll be investigating this further tomorrow.
TL;DR: I want to use #FacesComponent and its attributes to replace foundation-components-html.taglib.xml and the <component> entry in faces-config.xml
I currently have custom components working in my project using XML definitions. I recently learned that JSF 2.2 introduced a feature which removes the need for XML entirely. I would love to use this, but when I purely use annotations, they are ignored by JSF. Raw tags show up in my HTML.
(i.e. <custom:paragraph></custom:paragraph>)
I have demonstrated this issue in a sandbox of mine I keep hosted on Github. If you want to take a crack at that, I'll explain how at the bottom of this post.
All you need to do is delete foundation-components-html.taglib.xml, and comment out the faces-config.xml entry for <component> and run the application to encounter the issue. I left it in the 'functioning' state so that anyone who wishes to help has an easy, verifiably correct starting point. Just hit up http://localhost:8080
Technologies Used:
Spring Boot 1.2.1
JSF 2.2 via Mojarra 2.2.6
Embedded Tomcat 8.0.5
NOTE: Remember, this setup currently works, but it's running on the taglib and faces-config entries! My question is how to remove these dependencies using the latest features in JSF 2.2
Full Project
Custom Component
package foundation.components;
import java.io.IOException;
import javax.faces.component.FacesComponent;
import javax.faces.component.UIComponentBase;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
/**
* The Paragraph Component
* #author Seth Ellison
*/
#FacesComponent(value=UIParagraph.COMPONENT_TYPE, createTag=true, tagName="paragraph", namespace="http://www.blah.com/components/html")
public class UIParagraph extends UIComponentBase {
public static final String COMPONENT_TYPE = "foundation.components.Paragraph";
private String value;
private String styleClass;
#Override
public void encodeBegin(final FacesContext facesContext) throws IOException {
// Encode Implementation Omitted for Brevity.
}
#Override
public String getFamily() {
return "blah.components.family";
}
// Getters/Setters...
}
Taglib Definition
<facelet-taglib version="2.2"
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/web-facelettaglibrary_2_2.xsd">
<namespace>http://www.blah.com/components/html</namespace>
<tag>
<tag-name>paragraph</tag-name>
<component>
<component-type>foundation.components.Paragraph</component-type>
</component>
</tag>
</facelet-taglib>
Faces Config
<faces-config 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/web-facesconfig_2_2.xsd"
version="2.2" metadata-complete="false">
<component>
<component-type>foundation.components.Paragraph</component-type>
<component-class>foundation.components.UIParagraph</component-class>
</component>
</faces-config>
XHTML Template (Stripped down for clarity)
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:jsf="http://xmlns.jcp.org/jsf"
xmlns:custom="http://www.blah.com/components/html">
<head jsf:id="head"></head>
<body jsf:id="body">
<custom:paragraph value="This is a template for a simple marketing or informational website. It includes a large callout called a jumbotron and three supporting pieces of content. Use it as a starting point to create something more unique." />
</body>
</html>
If you'd like to run this, the easiest way would be to download the Spring Tool Suite, grab the code from Github, right click the project, and run it as a Spring Boot App. You'll get a connection error when the JPA configuration fires up, because you (likely) aren't running a local MySQL server. Don't worry about this. It's not at all required to visit the index page and check out the tag status. I frequently run the app both with, and without the DB fired up to no ill effect. Lastly, to get PrettyFaces to play nice with Spring Boot, you have to create either a Symbolic Link or a Hard Link from target/classes into WEB-INF/ -- PrettyFaces is coded to look in WEB-INF/classes or WEB-INF/lib when scanning for annotations.
Snippets for BalusC
This function exists in a class which is marked with #Configuration and implements ServletContextAware
#Bean
public ServletListenerRegistrationBean<ConfigureListener> jsfConfigureListener() {
return new ServletListenerRegistrationBean<ConfigureListener>(
new ConfigureListener());
}
Alright, I figured out what was causing the issue.
This morning I sat down to think about the differences between my working Servlet 3.1 version of the code, and the broken Spring Boot version. The main difference was how the code was being run. Embedded server vs. Standalone.
Spring Boot's embedded Tomcat server was the cause.
When I switched my sandbox around in accordance with this answer, everything turned on normally, and my custom components worked purely off of the #FacesComponent annotation!
I figure this has something to do with the way classes are organized post-startup on the embedded server vs. a discrete deploy to the Pivotal Tomcat server. JSF's annotation scanner seems to simply ignore annotations in that case.
I am trying to deploy JSF 1.2 application on WAS 8.5 server. But it is throwing below error on deployment.
Note: In the WAS admin, Under JSF implementation use console, I have selected the "Sun Reference Implementation 1.2 " option . But still problem persist.
[12/17/14 15:12:41:222 PST] 00000095 webapp E com.ibm.ws.webcontainer.webapp.WebApp notifyServletContextDestroyed SRVE0285E: Exception caught while destroying context: {0}
java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.
A typical config looks like this;
<listener>
<listener- class> org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:196)
at org.apache.myfaces.context.servlet.FacesContextImplBase.getApplication(FacesContextImplBase.java:131)
at org.apache.myfaces.webapp.AbstractFacesInitializer._dispatchApplicationEvent(AbstractFacesInitializer.java:261)
at org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:293)
at org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:153)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextDestroyed(WebApp.java:1748)
You should restart the application server (not just the app). You should also make sure jsf-api.api and jsf-impl.jar are not in WEB-INF/lib of your app.
I am building a web service using seam 2.0.1 and deploying it on jboss 4.2.2 GA. I have my web service class which access another class (updates stuff in data base).
I have standard-jaxws-endpoint-config.xml in META-INF folder.
#Name("pluginHandler")
#Scope(ScopeType.APPLICATION)
#Install(precedence = Install.BUILT_IN)
#Startup(depends = "someclass")
#Stateless
#WebService(name = "Plugin", serviceName = "PluginService")
public class PlugInHandler {
#WebMethod
public int processRequest(Account account)
{
Workbench wb = Component.getInstance("Workbench");
//above line keeps throwing exception "No application context active"
}
}
I have been looking all over different forums, but I cannot find a solution. I tried using Lifecycle.begincall() and Lifecycle.endCall() but nothing worked.
Do I need web.xml as well? If yes what information should web.xml contain?
Any help would be highly appreciated.
I recognize that this is question is rather dated, but to those few poor souls out there that still share your (and, currently my) predicament, here are a few pointers (dragged together from various sources but mainly from https://community.jboss.org/thread/192046):
Java EE WebService
First, using JBoss 4.2.2 likely means using Java EE5. WebServices there (with or without SEAM 2) can only be created on top of Stateless Session Beans. Stateless Session Beans in Java EE 5 need to implement a Service Endpoint Interface annotated with #Local or #Remote. While this has become optional in Java EE6, it is still mandatory here.
So:
#Local
public interface PluginHandlerInterface {
int processRequest(Account account);
}
#WebService
#Stateless
public PluginHandler implements PluginHandlerInterface { }
POJO WebService
If, in seam, you want to use a regular POJO as web-service, your class has to have another special annotation defining a Handler chain:
#WebService
// This here makes all the difference!
#HandlerChain(file = "web-service-handler-chain.xml")
public class PluginHandler {
...
}
This is the handler chain you put in /WEB-INF/classes/web-service-handler-chain.xml:
<?xml version="1.0" encoding="UTF-8"?>
<handler-chains xmlns="http://java.sun.com/xml/ns/javaee">
<handler-chain>
<handler>
<description>seam request handler</description>
<!-- probably not necessary
<handler-name>org.jboss.seam.webservice.SOAPRequestHandler</handler-name>
-->
<handler-class>org.jboss.seam.webservice.SOAPRequestHandler</handler-class>
</handler>
</handler-chain>
</handler-chains>
And you have to announce your service class to the war files web.xml like so:
<listener> <!-- this might already be present in your web.xml -->
<listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
</listener>
<servlet> <!-- Which class is to be used? -->
<servlet-name>PluginHandler</servlet-name>
<servlet-class>your.package.name.PluginHandler</servlet-class>
</servlet>
<servlet-mapping>
<!-- you'll find it under http://localhost:8080/your-war/PluginHandler?wsdl-->
<servlet-name>PluginHandler</servlet-name>
<url-pattern>/PluginHandler</url-pattern>
</servlet-mapping>
So these three steps, creating the handler chain, adding the annotation and announcing your service to the web.xml, should do the trick for you in SEAM: You'll have a web-service and the SEAM Context available right in it.
I'm working on a JSF project on Weblogic 11g, and our initial design is calling for JSF Backing Beans to invoke EJB3.0 beans to perform business logic and data access calls. The #EJB annotation doesn't seem to work in my project when I try to inject the EJB reference to the backing bean. Whenever I hit the class that I am testing, the constructor for my EJB is never called and I end up with a NPE. Is it possible to inject an EJB3.0 bean into a JSF backing bean? Is there another way I should be invoking an EJB through the JSF Backing bean? What is the best practice?
I googled somewhat and this indeed seems to be a known issue with Weblogic. Lot of similar topics are kept unanswered.
I found this blog which confirms that #EJB in Weblogic only works for resources definied by web.xml, not for JSF. The blog describes also in detail a workaround using ServletContextListener which is IMO not much better than using JNDI.
I also found this OTN topic which confirms that #EJB in Weblogic started to work when EJB modules are not included in subdirectories (see the answer posted at the bottom, Feb 15, 2011 5:44 PM).
It turns out that it is a Weblogic specific issue when deploying anything using JSF and EJB. I found this post on the Oracle forums that explains how to get the #EJB injection working in JSF Managed Beans using Weblogic 11g:
EJB3.0 Injection into JSF Managed beans
UPDATE:
After spinning my wheels for too long, I have to give up trying to inject an EJB into a JSF ManagedBean on Weblogic 11g. Seems to work fine in Tomcat. Maybe the EJB3 and JSF implementation will be better in 12G...
To make it work you need to follow two steps:
Deploy jsf-2.0.war as LIBRARY, you can find it /ORACLE_HOME/wlserver_10.3/common/deployable-libraries
In your web project, add the reference to the jsf-2.0.war library in WEB-INF/weblogic.xml
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" 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/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.1/weblogic-web-app.xsd">
<wls:weblogic-version>10.3.3</wls:weblogic-version>
<wls:context-root>your_context_app</wls:context-root>
<wls:library-ref>
<wls:library-name>jsf</wls:library-name>
<wls:specification-version>2.0</wls:specification-version>
<wls:implementation-version>1.0.0.0_2-0-2</wls:implementation-version>
<wls:exact-match>true</wls:exact-match>
</wls:library-ref>
</wls:weblogic-web-app>
I have successfully tested this in weblogic 10.3.3 and 10.3.5. If somehow this does not work, try to deploy the application as part of EAR file.
So here is the beat! There is a simple way to fix this.
Open up jsf-2.0.war under ...wlserver_10.3\common\deployable-libraries
Navigate to WEB-INF/lib and save wls.jsf.di.jar JAR somewhere
Place wls.jsf.di.jar JAR under lib folder of your WAR application.
Deploy
all should work now just by adding #EJB to property in your #ManagedBean.
There is an alternative for the #EJB annotation in order to get your local EJB bean accessible in your JSF ManagedBean web application. Considering that you have your EJB classes and your WAR packaged in the same EAR file, do the following:
configure your ejb-jar.xml to tell the weblogic expose the EJB beans to the external components;
<enterprise-beans>
<session>
<ejb-name>MyEJBBean</ejb-name>
<business-local>com.app.MyEJBBeanLocalInterface</business-local>
<ejb-class>com.app.MyEJBBeanLocalImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<ejb-local-ref>
<ejb-ref-name>ejb/MyEJBBeanLocal</ejb-ref-name>
<local>com.app.MyEJBBeanLocalInterface</local>
</ejb-local-ref>
</session>
<enterprise-beans>
Insert in the web.xml of your web application a reference to the EJB throught the ejb-link name. The ejb-ref-name is name visible for the JSF managed beans.
<ejb-local-ref>
<ejb-ref-name>ejb/MyEJBBeanLocal</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>com.app.MyEJBBeanLocalInterface</local>
<ejb-link>MyEJBBean</ejb-link>
</ejb-local-ref>
In your JSF Managed Bean call the EJB Bean through JNDI lookup as the following:
try {
Context context = new InitialContext();
MyEJBBeanLocalInterface myEJBBean =
context.lookup("java:comp/env/ejb/MyEJBBeanLocal");
} catch (NamingException e) {
e.printStackTrace();
}
In my case I was using the Weblogic 10.3.6 (11g), JSF 2.0 and EJB 3.0 with JPA (Eclipselink)