date:20160428

[jira] [Created] (DELTASPIKE-1138) FutureableTest not compatible with weld v1.x

2016-04-28 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created DELTASPIKE-1138:


 Summary: FutureableTest not compatible with weld v1.x
 Key: DELTASPIKE-1138
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1138
 Project: DeltaSpike
  Issue Type: Bug
  Components: Tests
Affects Versions: 1.6.1
Reporter: Gerhard Petracek
Assignee: Romain Manni-Bucau
 Fix For: 1.6.2






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1091) Weld core BOM update in next 2.3/3.x release

2016-04-28 Thread Matej Novotny (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262059#comment-15262059
 ] 

Matej Novotny commented on DELTASPIKE-1091:
---

[~gpetracek] I created a PR for this - 
https://github.com/apache/deltaspike/pull/47
A more in-depth explanation of my solution can be found in the PR comment.

BTW at first I accidentaly created the PR as "DELTAPIKE-1137", hence your bot 
didnt link it here. I already edited that.

Comments to the PR are welcome :)

> Weld core BOM update in next 2.3/3.x release
> 
>
> Key: DELTASPIKE-1091
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1091
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build
>Reporter: Matej Novotny
>Assignee: Rafael Benevides
>
> The next release of Weld 2.3 (2.3.4.Final) and 3.x (3.0.Alpha16) will also 
> contain a refactored weld-core BOM files.
> This is per request in [WELD-2115|https://issues.jboss.org/browse/WELD-2115].
> BOM will no longer provide direct dependencies, but only 
> {{dependencyManagement}} section. Looking at deltaspike dependencies, this 
> will affect 
> [{{parent/code/pom.xml}}|https://github.com/apache/deltaspike/blob/master/deltaspike/parent/code/pom.xml#L355]
>  and will require changes.
> The PRs for BOM changes are:
> * 2.3 branch -> https://github.com/weld/core/pull/1295
> * master -> https://github.com/weld/core/pull/1296



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

2016-04-28 Thread Matej Novotny (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262054#comment-15262054
 ] 

Matej Novotny commented on DELTASPIKE-1137:
---

Ignore the above PR please, it is for DELTASPIKE-1091, but I typed in wrong 
issue number - already corrected that...

> core/impl test suite freezes in embedded container with Weld 1.x
> 
>
> Key: DELTASPIKE-1137
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1137
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.6.1
> Environment: Embedded container
> Weld 1.x
>Reporter: Matej Novotny
>
> According to DS 
> [documentation|https://deltaspike.apache.org/documentation/build.html], the 
> basic way to build DS with Weld should be by running {{$ mvn clean install 
> -PWeld}}.
> Running this will indeed start the build but will then freeze mid-way through 
> with no response/failure. For me, the last (successfully) executed test was 
> {{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
> and then it just froze, doing nothing untill killed.
> The build always freezes on {{deltaspike/core/impl}} tests. So the fastest 
> way to reproduce it to run the command from there.
> The above written command will, by default, use (an outdated) version 
> 1.1.28.Final of Weld.
> To use more up to date version, one can add something like this - 
> {{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
> still freezes.
> The tests are executed within embedded container.
> NOTE: This only affects Weld 1.x, using Weld 2.x or 3.x works perfectly fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

2016-04-28 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262050#comment-15262050
 ] 

ASF GitHub Bot commented on DELTASPIKE-1137:


GitHub user manovotn opened a pull request:

https://github.com/apache/deltaspike/pull/47

DELTASPIKE-1137, created separate profiles for Weld versions, changed…

… docs accordingly.

I created 3 separate profiles for Weld 1/2/3 respectively.
As all three profiles have part of their build management/dependencies in 
common, I took those out and put them into a separate profile 
(`Weld-common-setup`).

`Weld-common-setup` is automatically triggered when you use 
`-Dweld.version=...` when executing tests (which you do like...all the time? :) 
). I couldn't really come up with other solution which would allow to avoid 
copying this setup into all three profiles. The downside of this is that once 
you run the tests without `-Dweld.version`, it will not work.

Last but not least, I modified docs (`build.adoc` to be more precise) to 
reflect these changes.

Ideas/comments are welcome!

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/manovotn/deltaspike weldProfileRefactoring

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/deltaspike/pull/47.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #47


commit ae16e7a4c6a3303657fe657c059a5a7da7a9ebbf
Author: Matej Novotny 
Date:   2016-04-28T12:15:36Z

DELTASPIKE-1137, created separate profiles for Weld versions, changed docs 
accordingly.




> core/impl test suite freezes in embedded container with Weld 1.x
> 
>
> Key: DELTASPIKE-1137
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1137
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.6.1
> Environment: Embedded container
> Weld 1.x
>Reporter: Matej Novotny
>
> According to DS 
> [documentation|https://deltaspike.apache.org/documentation/build.html], the 
> basic way to build DS with Weld should be by running {{$ mvn clean install 
> -PWeld}}.
> Running this will indeed start the build but will then freeze mid-way through 
> with no response/failure. For me, the last (successfully) executed test was 
> {{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
> and then it just froze, doing nothing untill killed.
> The build always freezes on {{deltaspike/core/impl}} tests. So the fastest 
> way to reproduce it to run the command from there.
> The above written command will, by default, use (an outdated) version 
> 1.1.28.Final of Weld.
> To use more up to date version, one can add something like this - 
> {{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
> still freezes.
> The tests are executed within embedded container.
> NOTE: This only affects Weld 1.x, using Weld 2.x or 3.x works perfectly fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] deltaspike pull request: DELTASPIKE-1137, created separate profile...

2016-04-28 Thread manovotn

GitHub user manovotn opened a pull request:

https://github.com/apache/deltaspike/pull/47

DELTASPIKE-1137, created separate profiles for Weld versions, changedâ¦

â¦ docs accordingly.

I created 3 separate profiles for Weld 1/2/3 respectively.
As all three profiles have part of their build management/dependencies in 
common, I took those out and put them into a separate profile 
(`Weld-common-setup`).

`Weld-common-setup` is automatically triggered when you use 
`-Dweld.version=...` when executing tests (which you do like...all the time? :) 
). I couldn't really come up with other solution which would allow to avoid 
copying this setup into all three profiles. The downside of this is that once 
you run the tests without `-Dweld.version`, it will not work.

Last but not least, I modified docs (`build.adoc` to be more precise) to 
reflect these changes.

Ideas/comments are welcome!

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/manovotn/deltaspike weldProfileRefactoring

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/deltaspike/pull/47.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #47


commit ae16e7a4c6a3303657fe657c059a5a7da7a9ebbf
Author: Matej Novotny 
Date:   2016-04-28T12:15:36Z

DELTASPIKE-1137, created separate profiles for Weld versions, changed docs 
accordingly.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

2016-04-28 Thread Matej Novotny (JIRA)


 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matej Novotny updated DELTASPIKE-1137:
--
Description: 
According to DS 
[documentation|https://deltaspike.apache.org/documentation/build.html], the 
basic way to build DS with Weld should be by running {{$ mvn clean install 
-PWeld}}.

Running this will indeed start the build but will then freeze mid-way through 
with no response/failure. For me, the last (successfully) executed test was 
{{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
and then it just froze, doing nothing untill killed.

The build always freezes on {{deltaspike/core/impl}} tests. So the fastest way 
to reproduce it to run the command from there.

The above written command will, by default, use (an outdated) version 
1.1.28.Final of Weld.
To use more up to date version, one can add something like this - 
{{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
still freezes.

The tests are executed within embedded container.

NOTE: This only affects Weld 1.x, using Weld 2.x or 3.x works perfectly fine.

  was:
According to DS 
[documentation|https://deltaspike.apache.org/documentation/build.html], the 
basic way to build DS with Weld should be by running {{$ mvn clean install 
-PWeld}}.

Running this will indeed start the build but will then freeze mid-way through 
with no response/failure. For me, the last (successfully) executed test was 
{{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
and then it just froze, doing nothing untill killed.

The build always freezes on {{deltaspike/core/impl}} tests. So the fastest way 
to reproduce it to run the command from there.

The above written command will, by default, use (an outdated) version 
1.1.28.Final of Weld.
To use more up to date version, one can add something like this - 
{{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
still freezes.

The tests are executed within embedded container.


> core/impl test suite freezes in embedded container with Weld 1.x
> 
>
> Key: DELTASPIKE-1137
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1137
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.6.1
> Environment: Embedded container
> Weld 1.x
>Reporter: Matej Novotny
>
> According to DS 
> [documentation|https://deltaspike.apache.org/documentation/build.html], the 
> basic way to build DS with Weld should be by running {{$ mvn clean install 
> -PWeld}}.
> Running this will indeed start the build but will then freeze mid-way through 
> with no response/failure. For me, the last (successfully) executed test was 
> {{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
> and then it just froze, doing nothing untill killed.
> The build always freezes on {{deltaspike/core/impl}} tests. So the fastest 
> way to reproduce it to run the command from there.
> The above written command will, by default, use (an outdated) version 
> 1.1.28.Final of Weld.
> To use more up to date version, one can add something like this - 
> {{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
> still freezes.
> The tests are executed within embedded container.
> NOTE: This only affects Weld 1.x, using Weld 2.x or 3.x works perfectly fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

2016-04-28 Thread Matej Novotny (JIRA)

Matej Novotny created DELTASPIKE-1137:
-

 Summary: core/impl test suite freezes in embedded container with 
Weld 1.x
 Key: DELTASPIKE-1137
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1137
 Project: DeltaSpike
  Issue Type: Bug
  Components: Tests
Affects Versions: 1.6.1
 Environment: Embedded container
Weld 1.x
Reporter: Matej Novotny


According to DS 
[documentation|https://deltaspike.apache.org/documentation/build.html], the 
basic way to build DS with Weld should be by running {{$ mvn clean install 
-PWeld}}.

Running this will indeed start the build but will then freeze mid-way through 
with no response/failure. For me, the last (successfully) executed test was 
{{org.apache.deltaspike.test.core.impl.resourceloader.ClasspathResourceTest}} 
and then it just froze, doing nothing untill killed.

The build always freezes on {{deltaspike/core/impl}} tests. So the fastest way 
to reproduce it to run the command from there.

The above written command will, by default, use (an outdated) version 
1.1.28.Final of Weld.
To use more up to date version, one can add something like this - 
{{-Dweld.version=1.1.33.Final}}. Anyway, version makes no difference here, it 
still freezes.

The tests are executed within embedded container.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1135) Cannot use typesafe messages on Application scope initialization observer

2016-04-28 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261756#comment-15261756
 ] 

Gerhard Petracek commented on DELTASPIKE-1135:
--

i've updated the initial comment which shows the workaround (see 
CustomJsfAwareLocaleResolver) + tested it successfully with wf (v8.2.0)

> Cannot use typesafe messages on Application scope initialization observer
> -
>
> Key: DELTASPIKE-1135
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1135
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.6.0
> Environment: Java 1.8.0_77-b03, Wildfly 8.2.0
>Reporter: Juan Pablo Angamarca
>Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.6.2
>
>
> Hi. I'm running into a problem when trying to use DS' typesafe messages in a 
> observer method that runs upon initialization of the application scope.
> Code (relevant methods only):
> @Dependent
> @MessageBundle
> // (Messages.properties is has been set-up correctly)
> public interface Messages {
>   String administrador();
>   
> }
> @Dependent
> public class StartupBean implements Serializable {
>   @Inject
>   private Messages msgs;
>   public void runOnStartup(@Observes 
> @Initialized(ApplicationScoped.class) ServletContext payload) {
>   this.log.info(this.msgs.administrador());
>   }
> }
> When the observer method is executed, I'm being presented with this 
> stacktrace, and deployment of application is aborted:
> 23:56:34,238 SEVERE [faces] (FactoryFinderInstance.java:177) Unable to obtain 
> InjectionProvider from init time FacesContext. Does this container implement 
> the Mojarra Injection SPI?
> 23:56:34,239 SEVERE [faces] (FactoryFinderInstance.java:494) La aplicación no 
> se ha inicializado correctamente durante el inicio, no se encuentra la 
> fábrica: javax.faces.application.ApplicationFactory. Attempting to find 
> backup.
> 23:56:34,239 ERROR [fail] (ServiceControllerImpl.java:1955) MSC01: Failed 
> to start service jboss.undertow.deployment.default-server.default-host./app: 
> org.jboss.msc.service.StartException in service 
> jboss.undertow.deployment.default-server.default-host./hg: Failed to start 
> service
>   at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>  [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_77]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_77]
>   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_77]
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Could 
> not find backup for factory javax.faces.application.ApplicationFactory. 
>   at 
> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:222)
>   at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
>   at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>   at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>  [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>   at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>  [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>   ... 3 more
> Caused by: java.lang.IllegalStateException: Could not find backup for factory 
> javax.faces.application.ApplicationFactory. 
>   at 
> javax.faces.FactoryFinderInstance.getFactory(FactoryFinderInstance.java:500)
>   at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:287)
>   at 
> com.sun.faces.config.InitFacesContext.getApplication(InitFacesContext.java:142)
>   at 
> org.apache.deltaspike.jsf.impl.message.JsfMessageResolver.getMessageSources(JsfMessageResolver.java:45)
>   at 
> org.apache.deltaspike.core.impl.message.DefaultMessageResolver.getMessage(DefaultMessageResolver.java:52)
>   at 
> org.apache.deltaspike.core.impl.message.DefaultMessage.toString(DefaultMessage.java:115)
>   at 
> org.apache.deltaspike.core.impl.message.DefaultMessage.toString(DefaultMessage.java:95)
>   at 
> org.apache.deltaspike.core.impl.message.MessageBundleInvocationHandler.invoke(MessageBundleInvocationHandler.java:123)
>   at com.sun.proxy.$Proxy1079.administrador(Unknown Source)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> [rt.jar:1.8.0_77]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
>

[jira] [Comment Edited] (DELTASPIKE-1135) Cannot use typesafe messages on Application scope initialization observer

2016-04-28 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15259613#comment-15259613
 ] 

Gerhard Petracek edited comment on DELTASPIKE-1135 at 4/28/16 8:32 AM:
---

workaround:
 - use org.apache.deltaspike.core:deltaspike-core-impl as compile-dependency.
 - use org.apache.deltaspike.modules:deltaspike-jsf-module-impl as 
compile-dependency.
 - specialize JsfMessageResolver

example:
{code}
@Specializes
public class CustomJsfMessageResolver extends JsfMessageResolver
{
@Override
protected List getMessageSources(MessageContext messageContext)
{
List result = new ArrayList(new
DefaultMessageResolver() {
@Override
protected List getMessageSources(MessageContext 
messageContext) {
return super.getMessageSources(messageContext);
}
}.getMessageSources(messageContext));

FacesContext facesContext = FacesContext.getCurrentInstance();

if (facesContext == null)
{
return result;
}

try
{
String bundleName = 
facesContext.getApplication().getMessageBundle();

if (bundleName != null)
{
result.add(bundleName);
}
result.add(FacesMessage.FACES_MESSAGES); //default messages from jsf

return result;
}
catch (RuntimeException e)
{
return result;
}
}
}
{code}

 - specialize JsfAwareLocaleResolver

example:
{code}
@Specializes
@ApplicationScoped
public class CustomJsfAwareLocaleResolver extends JsfAwareLocaleResolver
{
@Override
public Locale getLocale()
{
try
{
return super.getLocale();
}
catch (RuntimeException e)
{
return new DefaultLocaleResolver().getLocale();
}
}
}
{code}


was (Author: gpetracek):
workaround:
 - use org.apache.deltaspike.core:deltaspike-core-impl as compile-dependency.
 - use org.apache.deltaspike.modules:deltaspike-jsf-module-impl as 
compile-dependency.
 - specialize JsfMessageResolver

example:
{code}
@Specializes
public class CustomJsfMessageResolver extends JsfMessageResolver
{
@Override
protected List getMessageSources(MessageContext messageContext)
{
List result = new ArrayList(new
DefaultMessageResolver() {
@Override
protected List getMessageSources(MessageContext 
messageContext) {
return super.getMessageSources(messageContext);
}
}.getMessageSources(messageContext));

FacesContext facesContext = FacesContext.getCurrentInstance();

if (facesContext == null)
{
return result;
}

try
{
String bundleName = 
facesContext.getApplication().getMessageBundle();

if (bundleName != null)
{
result.add(bundleName);
}
result.add(FacesMessage.FACES_MESSAGES); //default messages from jsf

return result;
}
catch (RuntimeException e)
{
return result;
}
}
}
{code}

> Cannot use typesafe messages on Application scope initialization observer
> -
>
> Key: DELTASPIKE-1135
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1135
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.6.0
> Environment: Java 1.8.0_77-b03, Wildfly 8.2.0
>Reporter: Juan Pablo Angamarca
>Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.6.2
>
>
> Hi. I'm running into a problem when trying to use DS' typesafe messages in a 
> observer method that runs upon initialization of the application scope.
> Code (relevant methods only):
> @Dependent
> @MessageBundle
> // (Messages.properties is has been set-up correctly)
> public interface Messages {
>   String administrador();
>   
> }
> @Dependent
> public class StartupBean implements Serializable {
>   @Inject
>   private Messages msgs;
>   public void runOnStartup(@Observes 
> @Initialized(ApplicationScoped.class) ServletContext payload) {
>   this.log.info(this.msgs.administrador());
>   }
> }
> When the observer method is executed, I'm being presented with this 
> stacktrace, and deployment of application is aborted:
> 23:56:34,238 SEVERE [faces] (FactoryFinderInstance.java:177) Unable to obtain 
> InjectionProvider from init time FacesContext. Does this container implement 
> the Mojarra Injection SPI?
> 23:56:34,239 SEVERE [faces]

[jira] [Commented] (DELTASPIKE-1135) Cannot use typesafe messages on Application scope initialization observer

2016-04-28 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261664#comment-15261664
 ] 

Gerhard Petracek commented on DELTASPIKE-1135:
--

i tried your use-case with tomee7 and there it isn't an issue at all... -> i've 
to setup an application with wf.
however, it should be the same workaround (this time just with 
JsfAwareLocaleResolver).

> Cannot use typesafe messages on Application scope initialization observer
> -
>
> Key: DELTASPIKE-1135
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1135
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.6.0
> Environment: Java 1.8.0_77-b03, Wildfly 8.2.0
>Reporter: Juan Pablo Angamarca
>Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.6.2
>
>
> Hi. I'm running into a problem when trying to use DS' typesafe messages in a 
> observer method that runs upon initialization of the application scope.
> Code (relevant methods only):
> @Dependent
> @MessageBundle
> // (Messages.properties is has been set-up correctly)
> public interface Messages {
>   String administrador();
>   
> }
> @Dependent
> public class StartupBean implements Serializable {
>   @Inject
>   private Messages msgs;
>   public void runOnStartup(@Observes 
> @Initialized(ApplicationScoped.class) ServletContext payload) {
>   this.log.info(this.msgs.administrador());
>   }
> }
> When the observer method is executed, I'm being presented with this 
> stacktrace, and deployment of application is aborted:
> 23:56:34,238 SEVERE [faces] (FactoryFinderInstance.java:177) Unable to obtain 
> InjectionProvider from init time FacesContext. Does this container implement 
> the Mojarra Injection SPI?
> 23:56:34,239 SEVERE [faces] (FactoryFinderInstance.java:494) La aplicación no 
> se ha inicializado correctamente durante el inicio, no se encuentra la 
> fábrica: javax.faces.application.ApplicationFactory. Attempting to find 
> backup.
> 23:56:34,239 ERROR [fail] (ServiceControllerImpl.java:1955) MSC01: Failed 
> to start service jboss.undertow.deployment.default-server.default-host./app: 
> org.jboss.msc.service.StartException in service 
> jboss.undertow.deployment.default-server.default-host./hg: Failed to start 
> service
>   at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>  [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_77]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_77]
>   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_77]
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Could 
> not find backup for factory javax.faces.application.ApplicationFactory. 
>   at 
> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:222)
>   at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
>   at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>   at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>  [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>   at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>  [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>   ... 3 more
> Caused by: java.lang.IllegalStateException: Could not find backup for factory 
> javax.faces.application.ApplicationFactory. 
>   at 
> javax.faces.FactoryFinderInstance.getFactory(FactoryFinderInstance.java:500)
>   at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:287)
>   at 
> com.sun.faces.config.InitFacesContext.getApplication(InitFacesContext.java:142)
>   at 
> org.apache.deltaspike.jsf.impl.message.JsfMessageResolver.getMessageSources(JsfMessageResolver.java:45)
>   at 
> org.apache.deltaspike.core.impl.message.DefaultMessageResolver.getMessage(DefaultMessageResolver.java:52)
>   at 
> org.apache.deltaspike.core.impl.message.DefaultMessage.toString(DefaultMessage.java:115)
>   at 
> org.apache.deltaspike.core.impl.message.DefaultMessage.toString(DefaultMessage.java:95)
>   at 
> org.apache.deltaspike.core.impl.message.MessageBundleInvocationHandler.invoke(MessageBundleInvocationHandler.java:123)
>   at com.sun.proxy.$Proxy1079.administrador(Unknown Source)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> [rt.jar:1.8.0_77]
>   at 
>

[jira] [Created] (DELTASPIKE-1138) FutureableTest not compatible with weld v1.x

[jira] [Commented] (DELTASPIKE-1091) Weld core BOM update in next 2.3/3.x release

[jira] [Commented] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

[jira] [Commented] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

[GitHub] deltaspike pull request: DELTASPIKE-1137, created separate profile...

[jira] [Updated] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

[jira] [Created] (DELTASPIKE-1137) core/impl test suite freezes in embedded container with Weld 1.x

[jira] [Commented] (DELTASPIKE-1135) Cannot use typesafe messages on Application scope initialization observer

[jira] [Comment Edited] (DELTASPIKE-1135) Cannot use typesafe messages on Application scope initialization observer

[jira] [Commented] (DELTASPIKE-1135) Cannot use typesafe messages on Application scope initialization observer

10 matches

Site Navigation

Mail list logo

Footer information