[JBoss JIRA] Created: (JBAS-8818) CDI injection not working in WebListeners
by Nicklas Karlsson (JIRA)
CDI injection not working in WebListeners
-----------------------------------------
Key: JBAS-8818
URL: https://issues.jboss.org/browse/JBAS-8818
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Weld/CDI
Affects Versions: 6.0.0.Final
Reporter: Nicklas Karlsson
Assignee: Marius Bogoevici
CDI injection is not performed for WebListeners, e.g.
@WebListener
public class BugListener implements HttpSessionListener
{
@Inject
BeanManager beanManager;
...
}
Will have beanManager==null when the methods are hit
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (JBAS-8939) Expose BeanManager in JNDI even for non Java EE module deployments
by Marius Bogoevici (JIRA)
Expose BeanManager in JNDI even for non Java EE module deployments
------------------------------------------------------------------
Key: JBAS-8939
URL: https://issues.jboss.org/browse/JBAS-8939
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Reporter: Marius Bogoevici
Assignee: Marius Bogoevici
Fix For: 6.1.0
Currently the Weld deployer registers the BeanManager in JNDI in the global namespace if the deployment is a WAR or EJB-JAR.
Expose the Weld deployer in the global namespace even if the deployment is not a WAR or EJB-JAR. This is necessary for non-Java EE deployments (e.g. an ESB jar).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (JBAS-8792) No request scope during an EJB timeout method
by Adam Warski (JIRA)
No request scope during an EJB timeout method
---------------------------------------------
Key: JBAS-8792
URL: https://issues.jboss.org/browse/JBAS-8792
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Weld/CDI
Affects Versions: 6.0.0.Final, 6.0.0.CR1
Reporter: Adam Warski
Assignee: Marius Bogoevici
Since AS6 CR1, during an EJB timeout method, when trying to use request-scoped beans, I am getting an exception: "No active contexts for scope type javax.enterprise.context.RequestScoped". According to specs, this should work.
As a temporary workaround, I am registering a request context by hand:
@Inject
BoundRequestContext requestContext;
Map<String, Object> context = new HashMap<String, Object>();
try {
requestContext.associate(context);
requestContext.activate();
// Do the timeout stuff
} finally {
requestContext.invalidate();
requestContext.deactivate();
requestContext.dissociate(context);
}
Btw. I tried doing this with an interceptor, but it seems that neither EJB interceptors or CDI interceptors work with timers ...
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (JBAS-8867) Unable to list root HA-JNDI bindings
by Luca Visconti (JIRA)
Unable to list root HA-JNDI bindings
-------------------------------------
Key: JBAS-8867
URL: https://issues.jboss.org/browse/JBAS-8867
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Naming
Affects Versions: 6.0.0.Final
Environment: Tested on CentOS 5.5 64bit / OpenJdk 64bit and Ubuntu 10.04 LTS 64bit / Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
Reporter: Luca Visconti
Assignee: John Bailey
Listing root HA-JNDI tree cause an exception.
Either using JNDIView list method in jmx-console or an InitialContext.list("") cause a NPE ( Null keys are not supported! ) in Infinispan.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (JBAS-8816) data-source element in application.xml descriptor is not processed correctly
by henk de boer (JIRA)
data-source element in application.xml descriptor is not processed correctly
----------------------------------------------------------------------------
Key: JBAS-8816
URL: https://issues.jboss.org/browse/JBAS-8816
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployers, Java EE APIs
Affects Versions: 6.0.0.Final
Environment: Mac OS X 10.6
Reporter: henk de boer
Assignee: Ales Justin
Defining a datasource in the application.xml descriptor of an EAR using the data-source element, does not cause this datasource to become available in the defined namespace.
For instance the following is supposed to make a datasource available in JNDI at java:app/MyDataSource
<data-source>
<description>Sample DataSource definition</description>
<name>java:app/MyDataSource</name>
<class-name>org.postgresql.ds.PGSimpleDataSource</class-name>
<server-name>myserver.com</server-name>
<port-number>5432</port-number>
<database-name>mydb</database-name>
<user>myuser</user>
<password>mypass</password>
</data-source>
This however does not happen.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (JBAS-8841) Resteasy deployer doesn't support Resteasy client Framework (NoClassDefFoundError: org.apache.commons.httpclient.HttpMethod)
by Antoine Sabot-Durand (JIRA)
Resteasy deployer doesn't support Resteasy client Framework (NoClassDefFoundError: org.apache.commons.httpclient.HttpMethod)
----------------------------------------------------------------------------------------------------------------------------
Key: JBAS-8841
URL: https://issues.jboss.org/browse/JBAS-8841
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 6.0.0.Final
Reporter: Antoine Sabot-Durand
Assignee: Alessio Soldano
Priority: Minor
When deploying a simple Web App using Resteasy client Framework, I get the following exception when the app build the proxy to the Rest server via a @produces cdi annotation :
{{
2011-01-26 16:07:07,384 GRAVE [javax.enterprise.resource.webcontainer.jsf.application] (http-localhost%2F127.0.0.1-8080-1) Error Rendering View[/home.xhtml]: javax.el.ELException: /home.xhtml @19,75 value="#{twitterClient.query}": javax.enterprise.inject.CreationException
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:111) [:2.0.3-]
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:190) [:2.0.3-]
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:178) [:2.0.3-]
at javax.faces.component.UIOutput.getValue(UIOutput.java:164) [:2.0.3-]
at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:201) [:2.0.3-]
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:351) [:2.0.3-]
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:160) [:2.0.3-]
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:879) [:2.0.3-]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1650) [:2.0.3-]
at javax.faces.render.Renderer.encodeChildren(Renderer.java:164) [:2.0.3-]
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:849) [:2.0.3-]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1643) [:2.0.3-]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1646) [:2.0.3-]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1646) [:2.0.3-]
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:389) [:2.0.3-]
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:127) [:2.0.3-]
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:269) [:2.0.3-]
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:117) [:2.0.3-]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97) [:2.0.3-]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:135) [:2.0.3-]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:309) [:2.0.3-]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
at org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:63) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [:6.0.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.0.0.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_22]
Caused by: javax.enterprise.inject.CreationException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [:1.6.0_22]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [:1.6.0_22]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_22]
at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_22]
at java.lang.Class.newInstance0(Class.java:355) [:1.6.0_22]
at java.lang.Class.newInstance(Class.java:308) [:1.6.0_22]
at org.jboss.weld.util.reflection.SecureReflections$16.work(SecureReflections.java:395) [:6.0.0.Final]
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [:6.0.0.Final]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInstantiation(SecureReflectionAccess.java:216) [:6.0.0.Final]
at org.jboss.weld.util.reflection.SecureReflections.newInstance(SecureReflections.java:390) [:6.0.0.Final]
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) [:6.0.0.Final]
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:57) [:6.0.0.Final]
at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:107) [:6.0.0.Final]
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstance(MethodInjectionPoint.java:181) [:6.0.0.Final]
at org.jboss.weld.bean.ProducerMethod$1.produce(ProducerMethod.java:149) [:6.0.0.Final]
at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:361) [:6.0.0.Final]
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:67) [:6.0.0.Final]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:669) [:6.0.0.Final]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:751) [:6.0.0.Final]
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:138) [:6.0.0.Final]
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:872) [:6.0.0.Final]
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:884) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:182) [:6.0.0.Final]
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:54) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:176) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:142) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:170) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:339) [:6.0.0.Final]
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:67) [:6.0.0.Final]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:669) [:6.0.0.Final]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:751) [:6.0.0.Final]
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:138) [:6.0.0.Final]
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:872) [:6.0.0.Final]
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:884) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:182) [:6.0.0.Final]
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:54) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:176) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:142) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:170) [:6.0.0.Final]
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:339) [:6.0.0.Final]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:121) [:6.0.0.Final]
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) [:6.0.0.Final]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:87) [:6.0.0.Final]
at org.jboss.seam.social.example.twitterweb.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Developer$javatools$jboss-6$0$0$Final$server$default$deploy$seam-social-twitter-web-client$war"-ManagedBean-class_org$jboss$seam$social$example$twitterweb$TwitterClient_$$_WeldClientProxy.getQuery(org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Developer$javatools$jboss-6$0$0$Final$server$default$deploy$seam-social-twitter-web-client$war"-ManagedBean-class_org$jboss$seam$social$example$twitterweb$TwitterClient_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_22]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_22]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_22]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_22]
at javax.el.BeanELResolver.getValue(BeanELResolver.java:302) [:1.0.0.Final]
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175) [:1.0.0.Final]
at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:71) [:2.0.3-]
at org.apache.el.parser.AstValue.getValue(AstValue.java:134) [:6.0.0.Final]
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187) [:6.0.0.Final]
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:55) [:6.0.0.Final]
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:55) [:6.0.0.Final]
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:106) [:2.0.3-]
... 45 more
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/httpclient/HttpMethod
at java.lang.Class.getDeclaredConstructors0(Native Method) [:1.6.0_22]
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) [:1.6.0_22]
at java.lang.Class.getConstructor0(Class.java:2699) [:1.6.0_22]
at java.lang.Class.newInstance0(Class.java:326) [:1.6.0_22]
at java.lang.Class.newInstance(Class.java:308) [:1.6.0_22]
at org.jboss.resteasy.client.ClientRequest.createDefaultExecutorInstance(ClientRequest.java:115) [:6.0.0.Final]
at org.jboss.resteasy.client.ClientRequest.getDefaultExecutor(ClientRequest.java:94) [:6.0.0.Final]
at org.jboss.resteasy.client.ProxyFactory.create(ProxyFactory.java:29) [:6.0.0.Final]
at org.jboss.seam.social.twitter.TwitterProxyProducer.getTwitterSearchProxy(TwitterProxyProducer.java:25) [:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_22]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_22]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_22]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_22]
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305) [:6.0.0.Final]
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [:6.0.0.Final]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) [:6.0.0.Final]
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) [:6.0.0.Final]
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188) [:6.0.0.Final]
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstance(MethodInjectionPoint.java:169) [:6.0.0.Final]
... 87 more
Caused by: java.lang.ClassNotFoundException: org.apache.commons.httpclient.HttpMethod from BaseClassLoader@3d6a2c7b{vfs:///Developer/javatools/jboss-6.0.0.Final/server/default/deployers/resteasy.deployer}
at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:480) [jboss-classloader.jar:2.2.0.GA]
at java.lang.ClassLoader.loadClass(ClassLoader.java:248) [:1.6.0_22]
... 106 more
}}
I added *commons-httpclient-3.1.jar* in deployers/resteasy.deployer to correct the exception. Adding the jar to my webapp didn't worked
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (JBAS-9213) module-option principalClass will be ignored
by Michael Feichtegger (JIRA)
module-option principalClass will be ignored
--------------------------------------------
Key: JBAS-9213
URL: https://issues.jboss.org/browse/JBAS-9213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 6.0.0.Final
Environment: Windows XP
JBoss AS 6.0.0.Final
JavaSE 1.6.0_17
Reporter: Michael Feichtegger
Assignee: Anil Saldhana
I wrote a custom login module and configured it at {{login-config.xml}} as follows:
{code}
<application-policy name="MyRealm">
<authentication>
<login-module code="com.example.MyLoginModule" flag="required">
<module-option name="principalClass">com.example.UserPrincipal</module-option>
<module-option name="debug">true</module-option>
</login-module>
</authentication>
</application-policy>
{code}
In a second step I wrote a simple JSF application that performs the login using {{HttpServletRequest.login()}} that works very well.
Finally I used {{HttpServletRequest.getUserPrincipal()}} to retrieve the custom principal created during the login process.
On JBoss I'll just get a JBoss internal {{org.jboss.security.SimplePrincipal}} and I have to use {{PolicyContext.getContext("javax.security.auth.Subject.container")}} to get the desired principal.
The custom login module implements {{javax.security.auth.spi.LoginModule}} and is not derived from {{org.jboss.security.auth.spi.UsernamePasswordLoginModule}} since it should work on any JavaEE Container.
As far as I understood the specification the element {{<module-option name="principalClass">}} should be used to achieve this behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (JBAS-8799) Upgrade MyFaces version to align with RichFaces 4.0
by Jay Balunas (JIRA)
Upgrade MyFaces version to align with RichFaces 4.0
---------------------------------------------------
Key: JBAS-8799
URL: https://issues.jboss.org/browse/JBAS-8799
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: JSF
Reporter: Jay Balunas
Assignee: Nick Belaevski
Fix For: 6.0.1
The RichFaces team will be focusing on MyFaces integration during the 4.0.0.CR1 release. Nick will be leading this effort. As part of that effort we'll identify what version is required, and assign this issue to Stan so that he can adjust the 6.0.x version to the require version.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months