[JBoss JIRA] (WFLY-2611) Support CDI injection in various JSF artifacts
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Description:
If I understand correctly to the subchapter "5.4.1
JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
So far I tried locally this (will be filling the table during time):
||JSF artifact||CDI Injection||
|javax.el.ELResolver||
|javax.faces.application.ApplicationFactory||
|javax.faces.application.NavigationHandler||
|javax.faces.application.ResourceHandler||
|javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
|javax.faces.component.visit.VisitContextFactory|||
|javax.faces.context.ExceptionHandlerFactory|||
|javax.faces.context.ExternalContextFactory|||
|javax.faces.context.FacesContextFactory|works|
|javax.faces.context.PartialViewContextFactory||
|javax.faces.event.ActionListener|works only when specified also in faces-config|
|javax.faces.event.SystemEventListener|doesn't work|
|javax.faces.lifecycle.ClientWindowFactory||
|javax.faces.lifecycle.LifecycleFactory||
|javax.faces.lifecycle.PhaseListener|works|
|javax.faces.render.RenderKitFactory||
|javax.faces.view.ViewDeclarationFactory||
|javax.faces.view.facelets.FaceletCacheFactory||
|javax.faces.view.facelets.FaceletFactory||
|javax.faces.view.facelets.TagHandlerDelegateFactory||
was:
If I understand correctly to the subchapter "5.4.1
JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
So far I tried locally this (will be filling the table during time):
||JSF artifact||CDI Injection||
|javax.el.ELResolver||
|javax.faces.application.ApplicationFactory||
|javax.faces.application.NavigationHandler||
|javax.faces.application.ResourceHandler||
|javax.faces.application.StateManager|||
|javax.faces.component.visit.VisitContextFactory|||
|javax.faces.context.ExceptionHandlerFactory|||
|javax.faces.context.ExternalContextFactory|||
|javax.faces.context.FacesContextFactory|works|
|javax.faces.context.PartialViewContextFactory||
|javax.faces.event.ActionListener|works only when specified also in faces-config|
|javax.faces.event.SystemEventListener|doesn't work|
|javax.faces.lifecycle.ClientWindowFactory||
|javax.faces.lifecycle.LifecycleFactory||
|javax.faces.lifecycle.PhaseListener|works|
|javax.faces.render.RenderKitFactory||
|javax.faces.view.ViewDeclarationFactory||
|javax.faces.view.facelets.FaceletCacheFactory||
|javax.faces.view.facelets.FaceletFactory||
|javax.faces.view.facelets.TagHandlerDelegateFactory||
> Support CDI injection in various JSF artifacts
> ----------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
>
> If I understand correctly to the subchapter "5.4.1
> JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
> So far I tried locally this (will be filling the table during time):
> ||JSF artifact||CDI Injection||
> |javax.el.ELResolver||
> |javax.faces.application.ApplicationFactory||
> |javax.faces.application.NavigationHandler||
> |javax.faces.application.ResourceHandler||
> |javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
> |javax.faces.component.visit.VisitContextFactory|||
> |javax.faces.context.ExceptionHandlerFactory|||
> |javax.faces.context.ExternalContextFactory|||
> |javax.faces.context.FacesContextFactory|works|
> |javax.faces.context.PartialViewContextFactory||
> |javax.faces.event.ActionListener|works only when specified also in faces-config|
> |javax.faces.event.SystemEventListener|doesn't work|
> |javax.faces.lifecycle.ClientWindowFactory||
> |javax.faces.lifecycle.LifecycleFactory||
> |javax.faces.lifecycle.PhaseListener|works|
> |javax.faces.render.RenderKitFactory||
> |javax.faces.view.ViewDeclarationFactory||
> |javax.faces.view.facelets.FaceletCacheFactory||
> |javax.faces.view.facelets.FaceletFactory||
> |javax.faces.view.facelets.TagHandlerDelegateFactory||
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2364) Uninformative NPE in PoolAnnotationInformationFactory
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/WFLY-2364?page=com.atlassian.jira.plugin.... ]
Andre Dietisheim commented on WFLY-2364:
----------------------------------------
Stuart Douglas merged the patch into wildfly master. Resolving.
> Uninformative NPE in PoolAnnotationInformationFactory
> ------------------------------------------------------
>
> Key: WFLY-2364
> URL: https://issues.jboss.org/browse/WFLY-2364
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Denis Borovikov
> Assignee: David Lloyd
>
> I got NPE on jboss startup:
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.deployment.processors.annotation.PoolAnnotationInformationFactory.fromAnnotation(PoolAnnotationInformationFactory.java:43)
> at org.jboss.as.ejb3.deployment.processors.annotation.PoolAnnotationInformationFactory.fromAnnotation(PoolAnnotationInformationFactory.java:35)
> at org.jboss.as.ee.metadata.ClassAnnotationInformationFactory.createAnnotationInformation(ClassAnnotationInformationFactory.java:127)
> at org.jboss.as.ee.metadata.AbstractEEAnnotationProcessor.deploy(AbstractEEAnnotationProcessor.java:54)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> Root cause is empty value for Pool annotation in my code. I think it would be better to generate more informative exception message in this place.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2611) Support CDI injection in various JSF artifacts
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Description:
If I understand correctly to the subchapter "5.4.1
JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
So far I tried locally this (will be filling the table during time):
||JSF artifact||CDI Injection||
|javax.el.ELResolver||
|javax.faces.application.ApplicationFactory||
|javax.faces.application.NavigationHandler||
|javax.faces.application.ResourceHandler||
|javax.faces.application.StateManager|||
|javax.faces.component.visit.VisitContextFactory|||
|javax.faces.context.ExceptionHandlerFactory|||
|javax.faces.context.ExternalContextFactory|||
|javax.faces.context.FacesContextFactory|works|
|javax.faces.context.PartialViewContextFactory||
|javax.faces.event.ActionListener|works only when specified also in faces-config|
|javax.faces.event.SystemEventListener|doesn't work|
|javax.faces.lifecycle.ClientWindowFactory||
|javax.faces.lifecycle.LifecycleFactory||
|javax.faces.lifecycle.PhaseListener|works|
|javax.faces.render.RenderKitFactory||
|javax.faces.view.ViewDeclarationFactory||
|javax.faces.view.facelets.FaceletCacheFactory||
|javax.faces.view.facelets.FaceletFactory||
|javax.faces.view.facelets.TagHandlerDelegateFactory||
was:
If I understand correctly to the subchapter "5.4.1
JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
So far I tried locally this (will be filling the table during time):
||JSF artifact||CDI Injection||
|javax.el.ELResolver||
|javax.faces.application.ApplicationFactory||
|javax.faces.application.NavigationHandler||
|javax.faces.application.ResourceHandler||
|javax.faces.application.StateManager|||
|javax.faces.component.visit.VisitContextFactory|||
|javax.faces.context.ExceptionHandlerFactory|||
|javax.faces.context.ExternalContextFactory|||
|javax.faces.context.FacesContextFactory|works|
|javax.faces.context.PartialViewContextFactory||
|javax.faces.event.ActionListener|works only when specified also in faces-config|
|javax.faces.event.SystemEventListener|doesn't work|
|javax.faces.lifecycle.ClientWindowFactory||
|javax.faces.lifecycle.LifecycleFactory||
|javax.faces.lifecycle.PhaseListener||
|javax.faces.render.RenderKitFactory||
|javax.faces.view.ViewDeclarationFactory||
|javax.faces.view.facelets.FaceletCacheFactory||
|javax.faces.view.facelets.FaceletFactory||
|javax.faces.view.facelets.TagHandlerDelegateFactory||
> Support CDI injection in various JSF artifacts
> ----------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
>
> If I understand correctly to the subchapter "5.4.1
> JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
> So far I tried locally this (will be filling the table during time):
> ||JSF artifact||CDI Injection||
> |javax.el.ELResolver||
> |javax.faces.application.ApplicationFactory||
> |javax.faces.application.NavigationHandler||
> |javax.faces.application.ResourceHandler||
> |javax.faces.application.StateManager|||
> |javax.faces.component.visit.VisitContextFactory|||
> |javax.faces.context.ExceptionHandlerFactory|||
> |javax.faces.context.ExternalContextFactory|||
> |javax.faces.context.FacesContextFactory|works|
> |javax.faces.context.PartialViewContextFactory||
> |javax.faces.event.ActionListener|works only when specified also in faces-config|
> |javax.faces.event.SystemEventListener|doesn't work|
> |javax.faces.lifecycle.ClientWindowFactory||
> |javax.faces.lifecycle.LifecycleFactory||
> |javax.faces.lifecycle.PhaseListener|works|
> |javax.faces.render.RenderKitFactory||
> |javax.faces.view.ViewDeclarationFactory||
> |javax.faces.view.facelets.FaceletCacheFactory||
> |javax.faces.view.facelets.FaceletFactory||
> |javax.faces.view.facelets.TagHandlerDelegateFactory||
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2612) The CLI should support property substitution for names of elements and not only for parameters
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-2612?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky commented on WFLY-2612:
-----------------------------------------
This is already supported.
> The CLI should support property substitution for names of elements and not only for parameters
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-2612
> URL: https://issues.jboss.org/browse/WFLY-2612
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Beta1
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> My customer is using client side substitution in the CLI
> jboss-cli.xml:
> <resolve-parameter-values>true</resolve-parameter-values>
> This works fine for example with:
> /subsystem=datasources/data-source=oracleDS:add(connection-url=jdbc:oracle:thin:@server:1521:ora1, jndi-name=java:/jboss/${name}, driver-name=oracle)
> The "name" is provided in a property file at the command line for jboss-cli.sh
> This request is to extend this behaviour to allow for example:
> /subsystem=datasources/data-source=${datasourcename}:add(connection-url=jdbc:oracle:thin:@server:1521:ora1, jndi-name=java:/jboss/${name}, driver-name=oracle)
> In other words, have the actual element name be substituted as well based on a property value
> We know the easy workaround is to use bash embedded cli script, so the ${datasourcename} can be provided by a bash variable but it would be nice if the CLI could do that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2612) The CLI should support property substitution for names of elements and not only for parameters
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-2612?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky resolved WFLY-2612.
-------------------------------------
Resolution: Duplicate Issue
> The CLI should support property substitution for names of elements and not only for parameters
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-2612
> URL: https://issues.jboss.org/browse/WFLY-2612
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Beta1
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> My customer is using client side substitution in the CLI
> jboss-cli.xml:
> <resolve-parameter-values>true</resolve-parameter-values>
> This works fine for example with:
> /subsystem=datasources/data-source=oracleDS:add(connection-url=jdbc:oracle:thin:@server:1521:ora1, jndi-name=java:/jboss/${name}, driver-name=oracle)
> The "name" is provided in a property file at the command line for jboss-cli.sh
> This request is to extend this behaviour to allow for example:
> /subsystem=datasources/data-source=${datasourcename}:add(connection-url=jdbc:oracle:thin:@server:1521:ora1, jndi-name=java:/jboss/${name}, driver-name=oracle)
> In other words, have the actual element name be substituted as well based on a property value
> We know the easy workaround is to use bash embedded cli script, so the ${datasourcename} can be provided by a bash variable but it would be nice if the CLI could do that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2612) The CLI should support property substitution for names of elements and not only for parameters
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-2612?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne updated WFLY-2612:
-------------------------------
Priority: Minor (was: Major)
> The CLI should support property substitution for names of elements and not only for parameters
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-2612
> URL: https://issues.jboss.org/browse/WFLY-2612
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Beta1
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> My customer is using client side substitution in the CLI
> jboss-cli.xml:
> <resolve-parameter-values>true</resolve-parameter-values>
> This works fine for example with:
> /subsystem=datasources/data-source=oracleDS:add(connection-url=jdbc:oracle:thin:@server:1521:ora1, jndi-name=java:/jboss/${name}, driver-name=oracle)
> The "name" is provided in a property file at the command line for jboss-cli.sh
> This request is to extend this behaviour to allow for example:
> /subsystem=datasources/data-source=${datasourcename}:add(connection-url=jdbc:oracle:thin:@server:1521:ora1, jndi-name=java:/jboss/${name}, driver-name=oracle)
> In other words, have the actual element name be substituted as well based on a property value
> We know the easy workaround is to use bash embedded cli script, so the ${datasourcename} can be provided by a bash variable but it would be nice if the CLI could do that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months