I’m facing a problem when trying do deploy on TomEE (using OWB).
I’m getting the following exception:
javax.enterprise.inject.UnsatisfiedResolutionException: Api type [org.apache.wicket.cdi.AutoConversation] is not found with the qualifiers
Qualifiers: [#javax.enterprise.inject.Default()]
for injection into Field Injection Point, field name : autoConversation, Bean Owner : [null]
at org.apache.webbeans.util.InjectionExceptionUtil.throwUnsatisfiedResolutionException(InjectionExceptionUtil.java:60)
at org.apache.webbeans.container.InjectionResolver.getInjectionPointBean(InjectionResolver.java:250)
at org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:76)
at org.apache.webbeans.inject.InjectableField.doInjection(InjectableField.java:65)
at org.apache.webbeans.portable.InjectionTargetImpl.injectFields(InjectionTargetImpl.java:372)
at org.apache.webbeans.portable.InjectionTargetImpl.inject(InjectionTargetImpl.java:358)
at org.apache.webbeans.portable.InjectionTargetImpl.inject(InjectionTargetImpl.java:342)
at org.apache.wicket.cdi.NonContextual.postConstruct(NonContextual.java:129)
at org.apache.wicket.cdi.NonContextualManager.postConstruct(NonContextualManager.java:65)
at org.apache.wicket.cdi.ConversationPropagator.(ConversationPropagator.java:122)
at org.apache.wicket.cdi.CdiConfiguration.configure(CdiConfiguration.java:188)
…
I’ve been looking for information online, but there seems to be nothing on it. I have the seam-conversation-spi and seam-conversation-owb jars on my classpath, so that’s not a dependency issue (had some of those, but got over them).
I understand from other people that deploying an EAR with wicket-cdi on other application servers is very easy and straightforward. However, I really like TomEE (the whole "based on TomCat" concept), and wouldn't want to have to switch.
I'm at a loss here, does anyone have a clue on what's going on ?
Edit 1:
This is the contents of my application class init method:
public void init() {
super.init();
BeanManager manager = (BeanManager)new InitialContext().lookup(“java:comp/BeanManager”);
new CdiConfiguration(manager).configure(this);
}
There's really nothing more in the class.
Edit 2:
Here's the code of my application.xml file used to create the EAR file I deploy:
<application 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/application_6.xsd"
version="6">
<initialize-in-order>true</initialize-in-order>
<module>
<ejb>integration.jar</ejb>
</module>
<module>
<ejb>application.jar</ejb>
</module>
<module>
<web>
<web-uri>presentation.war</web-uri>
<context-root>app</context-root>
</web>
</module>
</application>
Edit 3:
From what I read in the code of wicket-cdi and openwebbeans, I think it has to be one of these scenarios:
OWB doesn't find the AutoConversation class (i.e. the wicket-cdi JAR) - I bundle the class inside the WAR in the lib directory using Ant's standard task, so that seems strange
OWB doesn't recognize that the wicket-cdi JAR is a beans JAR - That sounds almost impossible, especially since there's a beans.xml and MANIFEST.MF in the JAR under META-INF as request by the cdi spec
Still at a loss, any help would be appreciated.
Edit 4:
Here's the list of JARs I have in the WAR file, in case it helps:
seam-conversation-spi-3.0.0.Final.jar
velocity-1.7-dep.jar
velocity-1.7.jar
wicket-auth-roles-6.15.0.jar
wicket-bean-validation-6.15.0.jar
wicket-bootstrap-0.17.jar
wicket-cdi-6.15.0.jar
wicket-core-6.15.0.jar
wicket-datetime-6.15.0.jar
wicket-devutils-6.15.0.jar
wicket-extensions-6.15.0.jar
wicket-guice-6.15.0.jar
wicket-ioc-6.15.0.jar
wicket-jmx-6.15.0.jar
wicket-request-6.15.0.jar
wicket-spring-6.15.0.jar
wicket-util-6.15.0.jar
wicket-velocity-6.15.0.jar
Wicket expects AutoConversion bean to inject into ConversationPropagator.
See the fragment of the source of org.apache.wicket.cdi.ConversationPropagator:
#Inject
Conversation conversation_;
#Inject
AutoConversation autoConversation;
Solutions:
Add a bean of type org.apache.wicket.cdi.AutoConversation to your bean definitions.
Disable ConversationPropagator
See your modified code, how to disable ConversationPropagator
new CdiConfiguration(manager).setPropagation(ConversationPropagation.NONE).configure(this);
Related
I'm trying to implement a simple login using Spring Security (I'm a newbie in Spring Security). I've started with Spring Security reference that contains a simple "Hello world" example (link). I've prepared a web project in Eclipse (with EAR project), file structure looks like this:
SecurityConfig and SecurityWebApplicationInitializer classes are identical to those in a link above ("Hello world" example). I've also added Log4j 2 configuration file and home page (login.xhtml) that (for now) just prints "test". Later it will be used as a custom login page.
web.xml contains only a welcome-file element:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
<display-name>SpringSecurity</display-name>
<welcome-file-list>
<welcome-file>pages/login.xhtml</welcome-file>
</welcome-file-list>
</web-app>
EAR's deployment assembly looks like this:
When I deploy my EAR on a JBoss AS 7.1.1, there's no error, but when I access http://localhost:8080/SpringSecurity, my home page is displayed normally.
I'm guessing that the configuration above should generate a default login page. When I access my home page, that login page should appear, right? It looks like that Spring Security is not even loaded and there's no protection when accesing my home page.
I don't really understand why is this simple example not working. Any help?
I do not have JBoss on my machine currently. But I was able to deploy this example on tomcat.
The issue certainly is that the war classloader is not able to see the spring jars at runtime.
There can be two possible solutions to resolve this.
If the spring jars are only required by war module (not by any other module in the ear), then you can shift these spring jars from ear's lib directory to war's WEB-INF/lib directory.
If the spring jars are also required by the other modules than you can to explicitly set the Class-Path entry in the MANIFEST.MF file of the war and the other modules that require these jars in a portable way.
e.g.
Manifest-Version: 1.0
Class-Path: lib/spring-beans-4.3.9.RELEASE.jar lib/spring-context-4.3.9.RELEASE.jar
Add all the required jars in this way separated by sapce (' ').
Note:- I used following jars to make this example run.
spring-aop-5.0.2.RELEASE.jar
spring-beans-5.0.2.RELEASE.jar
spring-context-5.0.2.RELEASE.jar
spring-core-5.0.2.RELEASE.jar
spring-expression-5.0.2.RELEASE.jar
spring-jcl-5.0.2.RELEASE.jar
spring-security-config-5.0.0.RELEASE.jar
spring-security-core-5.0.0.RELEASE.jar
spring-security-crypto-5.0.0.RELEASE.jar
spring-security-web-5.0.0.RELEASE.jar
spring-web-5.0.2.RELEASE.jar
And with this version of spring and spring-security you may have to make a small change in your code.
User.withDefaultPasswordEncoder().username("user").password("user").roles("USER").build();
or
User.withUsername("user").password("{noop}user").roles("USER").build();
Refer - Spring Boot PasswordEncoder Error for more details about the code change required.
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
My SFSB Seam component is bound to JNDI on deployment, as evidenced by this log message:
Component: example, scope: CONVERSATION, type: STATEFUL_SESSION_BEAN,
class:com.purecharger.action.ExampleAction, JNDI: purecharger/ExampleAction/local
My interface:
#Local
public interface Example {
public List<String> getExample();
public void destroy();
}
and my implementation:
#Stateful
#Scope(ScopeType.CONVERSATION)
#Name("example")
#Restrict("#{identity.loggedIn}")
public class ExampleAction implements Example, Serializable {
....
}
However, when I access the voting component in an xhtml page like, I get the following error:
javax.el.ELException: /home.xhtml: Could not instantiate Seam component: example
....
Caused by: javax.naming.NameNotFoundException: ExampleAction not bound
If Seam was smart enough to install my component using the JNDI pattern in components.xml (purecharger/#{ejbName}/local), why does it not also apply the pattern when looking up components?
Thank you.
UPDATE:
Looking at the JNDIView in JBoss, the name purecharger/ExampleAction/local is not bound anywhere. So I guess my question now becomes, why is Seam not adding this SFSB to JNDI?
Why is Seam not adding this SFSB to JNDI ?
Well,
As shown in your question, i think you have a ear application, because of its JNDI global address
purecharger/ExampleAction/local
which is mapped according to
<EAR_APPLICATION>/<STATEFUL_BEAN>/local
When you deploy a single EJB module, its JNDI global address in JBoss looks like
<STATEFUL_BEAN>/local
Bacause you have a ear application, each EJB module should be declared in application.xml (The file that describes your ear) as follows
So your ear app looks like
pureCharger.ear
META-INF
application.xml
pureCharger-ejb.jar
pureCharger-war.war
jboss-seam.jar
lib
// libraries shared by your modules goes here
And your application.xml
<?xml version="1.0" encoding="UTF-8"?>
<application version="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/application_5.xsd">
<display-name>pureCharger</display-name>
<module>
<ejb>pureCharger-ejb.jar</ejb>
</module>
<module>
<ejb>jboss-seam.jar</ejb>
</module>
<module>
<web>
<web-uri>pureCharger-war.war</web-uri>
<context-root>pureCharger</context-root>
</web>
</module>
</application>
Notice jboss-seam.jar is a EJB module, so it should also be declared in application.xml file
If possible, use Seam-gen to generate your project. It takes care includes all libraries needed by your project and can be opened without restriction in NetBeans, for instance.
regards,
I'm having problems deploying a simple WebServices app (like "Hello World" simple) to OC4J. The same code works fine under Jetty, but breaks in OC4J, and I'm wondering if anyone else has faced the same issue. I'm using Enterprise Manager to deploy the app, but the deployment fails with this message:
[Jan 23, 2009 8:46:20 AM] Binding TestWs web-module for application TestWs to site default-web-site under context root /TestWs
[Jan 23, 2009 8:46:22 AM] Operation failed with error: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://cxf.apache.org/jaxws]
Offending resource: ServletContext resource [/WEB-INF/beans.xml]
Looking at the beans.xml, the offending code seems to be the XML namespace declarations:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jaxws="http://cxf.apache.org/jaxws"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
<jaxws:endpoint
id="helloService"
implementor="com.test.endpoint.HelloImpl"
address="/HelloWorld" />
</beans>
The stack trace is not terribly illuminating:
09/01/23 08:57:28 oracle.oc4j.admin.internal.DeployerException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://cxf.apache.org/jaxws]
Offending resource: ServletContext resource [/WEB-INF/beans.xml]
09/01/23 08:57:28 at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)
09/01/23 08:57:28 at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
09/01/23 08:57:28 at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:80)
09/01/23 08:57:28 at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:261)
09/01/23 08:57:28 at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1120)
...
Has anyone else run into similar problems? And if so, what's the best way to go about fixing it? My XML skills are middling, and I'm a complete noob with WebServices. But this may be an OC4J issue.
Thanks in advance for your help!
EDIT: This is not, as far as I can tell, a classpath issue, unless OC4J is odd about what jars it want to see where (as I know Tomcat can be). My WEB-INF/lib folder has the CXF jar, the Spring jars (beans, context, core, and web), xml-resolver-1.2.jar, and XmlSchema-1.4.2.jar. If I need to list everything in the WEB-INF/lib folder, I will. But again, the program works in Jetty.
Another Edit: Based on what I'm reading here, this appears to be an issue between Spring and the CXF jar -- there's a NamespaceHandler class in the CXF jar (in org.apache.cxf.frontend.spring to be precise), but there seems to be a configuration issue preventing Spring from seeing it.
Last Edit: Thank you everyone for your help. I never ended up getting CXF working in OC4J, because my client is on version 10.1.3.3.0. It's not J2EE 5 compliant, and I'm pretty sure they're not going to go for unpacking their oc4j.jar in order to change the boot.xml. But without the document Daniel pointed me to, I never would have known that.
So I switched to XFire version 1.2.6, and got my test app working after a few hiccups. Along the way I learned some interesting things about OC4J:
When deploying in Enterprise Manager, make sure you choose to load the local classpath first.
OC4J uses non-standard XML files, so make sure your app is not using any of OC4J's native XML files (in the Deployment Settings, uncheck all the currently selected imports -- that way, you can ensure that the app is using only files you provide in WEB-INF/lib)
If you can, use another app server. :P
Thank you all again!
I hate to ask the obvious, but have you looked at all the stuff for configuring OS4J and CXF together from the CXF web site?
http://cwiki.apache.org/CXF20DOC/appserverguide.html#AppServerGuide-OC4J
Looks like a configuration issue with Spring:
Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://cxf.apache.org/jaxws]
Offending resource: ServletContext resource [/WEB-INF/beans.xml]
Do you have anything in your web.xml to read that when the app starts up? Do you see a NamespaceHandler declared for that namespace anywhere in your code?
I would think its a CLASSPATH issue.
I'm not that familiar with OC4J, but how are you packaging/deploying your web-application?
You need to ensure that the CXF jar is in the WEB-INF/lib directory of your WAR?
Update: A little confused by your comments - if your spring config is in the META-INF directory of your EAR, then this is not the same classpath as that used by your web-app. So, in fact, sticking the CXF jar in WEB-INF/lib isn't going to work. You will either need to stick the JAR in the top-level of your EAR, or in some lib shared by all classloaders of OC4J. I suggest studying the enterprise-app/web-app classloader hierarchy documentation of OC4J to see if this can give more advice?