[jira] [Commented] (DELTASPIKE-939) dswid=tempWindowId for every duplicated tab in Chrome/Firefox

2015-07-16 Thread Thomas Andraschko (JIRA) 

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

Thomas Andraschko commented on DELTASPIKE-939:
--

Please add the jsf-module-impl as dependency.
I refactored the jsf-playground to dynamically include per profile 
jsf-module-impl or jsf-module-impl-ee6.

> dswid=tempWindowId for every duplicated tab in Chrome/Firefox
> -
>
> Key: DELTASPIKE-939
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-939
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module
>Affects Versions: 1.4.1
> Environment: Chrome 43.0.2357.125 (64-bit)
> Firefox 38.0.5
> Fedora 22
>Reporter: Sean Flanigan
>Assignee: Thomas Andraschko
> Fix For: 1.4.2
>
>
> I am using ClientWindowRenderMode.CLIENTWINDOW and a JSF page with 
> , and a ViewAccessScoped action bean which prints its identity 
> whenever its corresponding commandButton is clicked.
> If I navigate via that button, or h:link, or , everything works
> as I expect: the dswid is preserved, and the bean has the same identity
> within the same browser tab.  And if I use middle-click to open a new
> tab, each tab gets a new identity (new dswid) and a new instance of the
> bean.
> The problem happens when I use Chrome's "Duplicate Tab" feature, or Firefox's 
> clone tab feature (drag and drop a tab while holding Ctrl).
> Whenever I clone a tab that way, I get (after a redirect) a new tab with
> dswid=tempWindowId, and each of these tabs is sharing the same instance
> of my ViewAccessScoped bean.
> You can see the same problem in the JSF playground, by visiting 
> http://localhost:8080/ds/views/scope/viewaccess/test1.xhtml, cloning the tab 
> twice and observing that dswid=tempWindowId in both clones.
> I think duplicated tabs should get their own identities, instead of
> sharing "tempWindowId".



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

[jira] [Updated] (DELTASPIKE-830) windowhandling doesn't work correctly when onload defined on h:body

2015-07-16 Thread Thomas Andraschko (JIRA) 

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

Thomas Andraschko updated DELTASPIKE-830:
-
Summary: windowhandling doesn't work correctly when onload defined on 
h:body  (was: Now active ViewAccessScoped context during restore view phase)

> windowhandling doesn't work correctly when onload defined on h:body
> ---
>
> Key: DELTASPIKE-830
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-830
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module
>Affects Versions: 1.2.1
> Environment: Glassfish 3.1.2.2 and Weblogic 12.1.2.2
>Reporter: Nuno G. de M
>Assignee: Thomas Andraschko
> Fix For: 1.4.2
>
>
> While testing delta-spike in clientview mode, coming from CODI, we have one 
> view that is giving problems trying to access ViewAccessScoped beans  during 
> the restored view phase.
> Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No 
> active contexts for scope type 
> org.apache.deltaspike.core.api.scope.ViewAccessScoped
> Namely the exception we get in our page is the following:
> Caused By: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No 
> active contexts for scope type 
> org.apache.deltaspike.core.api.scope.ViewAccessScoped
>   at 
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:590)
>   at 
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71)
>   at 
> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
>   at 
> com.corp.whatever.component.ui.web.CR100Bean$Proxy$_$$_WeldClientProxy.getPageIds(CR100Bean$Proxy$_$$_WeldClientProxy.java)
>   at sun.reflect.GeneratedMethodAccessor1663.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at javax.el.BeanELResolver.getValue(BeanELResolver.java:305)
>   at 
> com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
>   at 
> com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
>   at com.sun.el.parser.AstValue.getValue(AstValue.java:138)
>   at com.sun.el.parser.AstValue.getValue(AstValue.java:183)
>   at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224)
>   at 
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
>   at 
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
>   at 
> com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
>   at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:99)
>   at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224)
>   at 
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
>   at 
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
>   at 
> com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
>   at 
> com.sun.faces.facelets.tag.jstl.core.SetHandler.apply(SetHandler.java:163)
>   at 
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
>   at 
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
>   at 
> com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:188)
>   at 
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
>   at 
> com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
>   at 
> com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
>   at 
> com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320)
>   at 
> com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379)
>   at 
> com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:358)
>   at 
> com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
>   at 
> com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155)
>   at 
> com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
>   at 
> com.sun.faces.facelets.compiler

[jira] [Updated] (DELTASPIKE-830) windowhandling doesn't work correctly when onload defined on h:body

2015-07-16 Thread Thomas Andraschko (JIRA) 

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

Thomas Andraschko updated DELTASPIKE-830:
-
Component/s: JSF22-Module

> windowhandling doesn't work correctly when onload defined on h:body
> ---
>
> Key: DELTASPIKE-830
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-830
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module, JSF22-Module
>Affects Versions: 1.2.1
> Environment: Glassfish 3.1.2.2 and Weblogic 12.1.2.2
>Reporter: Nuno G. de M
>Assignee: Thomas Andraschko
> Fix For: 1.4.2
>
>
> While testing delta-spike in clientview mode, coming from CODI, we have one 
> view that is giving problems trying to access ViewAccessScoped beans  during 
> the restored view phase.
> Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No 
> active contexts for scope type 
> org.apache.deltaspike.core.api.scope.ViewAccessScoped
> Namely the exception we get in our page is the following:
> Caused By: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No 
> active contexts for scope type 
> org.apache.deltaspike.core.api.scope.ViewAccessScoped
>   at 
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:590)
>   at 
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71)
>   at 
> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
>   at 
> com.corp.whatever.component.ui.web.CR100Bean$Proxy$_$$_WeldClientProxy.getPageIds(CR100Bean$Proxy$_$$_WeldClientProxy.java)
>   at sun.reflect.GeneratedMethodAccessor1663.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at javax.el.BeanELResolver.getValue(BeanELResolver.java:305)
>   at 
> com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
>   at 
> com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
>   at com.sun.el.parser.AstValue.getValue(AstValue.java:138)
>   at com.sun.el.parser.AstValue.getValue(AstValue.java:183)
>   at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224)
>   at 
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
>   at 
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
>   at 
> com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
>   at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:99)
>   at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:224)
>   at 
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
>   at 
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
>   at 
> com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
>   at 
> com.sun.faces.facelets.tag.jstl.core.SetHandler.apply(SetHandler.java:163)
>   at 
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
>   at 
> com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187)
>   at 
> javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
>   at 
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
>   at 
> com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:188)
>   at 
> javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
>   at 
> com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
>   at 
> com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
>   at 
> com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320)
>   at 
> com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379)
>   at 
> com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:358)
>   at 
> com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
>   at 
> com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155)
>   at 
> com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
>   at 
> com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
>   at 
> com.sun.faces.facelets.impl.DefaultFacelet.inc

[jira] [Reopened] (DELTASPIKE-946) Prevent jfwid rendering

2015-07-16 Thread Thomas Andraschko (JIRA) 

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

Thomas Andraschko reopened DELTASPIKE-946:
--

> Prevent jfwid rendering
> ---
>
> Key: DELTASPIKE-946
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-946
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: JSF22-Module
>Affects Versions: 1.4.1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.4.2
>
>
> We can and should prevent the jfwid on links when we don't run in the 
> DELEGATED mode.



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

[jira] [Created] (DELTASPIKE-959) DS cuts the windowId generated from JSF 2.2

2015-07-16 Thread Thomas Andraschko (JIRA) 
Thomas Andraschko created DELTASPIKE-959:


 Summary: DS cuts the windowId generated from JSF 2.2
 Key: DELTASPIKE-959
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-959
 Project: DeltaSpike
  Issue Type: Bug
  Components: JSF-Module, JSF22-Module
Affects Versions: 1.4.1
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko
 Fix For: 1.4.2






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

[jira] [Resolved] (DELTASPIKE-946) Prevent jfwid rendering

2015-07-16 Thread Thomas Andraschko (JIRA) 

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

Thomas Andraschko resolved DELTASPIKE-946.
--
Resolution: Fixed

> Prevent jfwid rendering
> ---
>
> Key: DELTASPIKE-946
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-946
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: JSF22-Module
>Affects Versions: 1.4.1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.4.2
>
>
> We can and should prevent the jfwid on links when we don't run in the 
> DELEGATED mode.



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

[jira] [Commented] (DELTASPIKE-957) Improve how TransactionStrategies are looked up

2015-07-16 Thread Mark Struberg (JIRA) 

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

Mark Struberg commented on DELTASPIKE-957:
--

if the @Alternative is broken in WildFly 9 then this must be fixed there. It is 
known to work perfectly fine in JBossAS7 and EAP-6.4 for example.
Changing the default strategy would totally break backward compat. And the 
standard for CDI is not JTA but resource local. This will get even more true 
with CDI-2.0 and the slow demise of EJB.

> Improve how TransactionStrategies are looked up
> ---
>
> Key: DELTASPIKE-957
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-957
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module, Documentation, JPA-Module
>Affects Versions: 1.4.1
>Reporter: John D. Ament
>
> Currently transaction strategies are implemented as alternatives.  I created 
> a WAR for WildFly 9, and ran into a lot of issues getting it to work.  My WAR 
> has many JARs in it, all with beans.xml files.  I tried to enable the 
> alternative in various spots, but no luck, even went through all 30 beans.xml 
> files in my project and enabled it.  Still went with the default transaction 
> strategy.
> In order to fix, I had to enable a global alternative with the strategy.  
> This seems to go against our docs, which indicate it should be a regular 
> alternative.  
> I'd recommend a few things to think about.
> - Expect a concrete producer.
> - Use a class look up in apache-deltaspike.properties



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

[jira] [Resolved] (DELTASPIKE-959) DS cuts the windowId generated from JSF 2.2

2015-07-16 Thread Thomas Andraschko (JIRA) 

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

Thomas Andraschko resolved DELTASPIKE-959.
--
Resolution: Fixed

> DS cuts the windowId generated from JSF 2.2
> ---
>
> Key: DELTASPIKE-959
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-959
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module, JSF22-Module
>Affects Versions: 1.4.1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.4.2
>
>




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

[jira] [Assigned] (DELTASPIKE-942) DeltaSpike fails to start with corrupted persistence.xml file.

2015-07-16 Thread Thomas Andraschko (JIRA) 

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

Thomas Andraschko reassigned DELTASPIKE-942:


Assignee: Thomas Andraschko

> DeltaSpike fails to start with corrupted persistence.xml file.
> --
>
> Key: DELTASPIKE-942
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-942
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.4.1
> Environment:  * Java version: 1.8.0_40, vendor: Oracle Corporation
>  * Windows 7 Enterprise
>  * Apache Maven 3.2.3
>Reporter: Grzegorz Demecki
>Assignee: Thomas Andraschko
>  Labels: easyfix
> Attachments: DELTASPIKE-942-bug-showcase.zip
>
>
> h4. Details
> Please see attached sample web application and run it via: 
>  {code} mvn clean compile jetty:run {code}
> At startup we can see huge stack trace that tells literally nothing.
> {code:java}
> 2015-07-01 16:38:50.076:WARN:oeja.ServletContainerInitializersStarter:main:
> org.jboss.weld.exceptions.DefinitionException: Exception List with 1 
> exceptions:|Exception 0 :|java.lang.RuntimeException: Failed initializing 
> mapping files
>  at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.extractMappings(PersistenceUnitReader.java:82)
>  at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.lookupUnits(PersistenceUnitReader.java:54)
>  ...
> {code}
> Whereas the exception should look like:
> {code:java}
>  javax.servlet.ServletException: Caused by:
>  javax.persistence.PersistenceException: [PersistenceUnit: netadminPU] Unable 
> to resolve named mapping-file [META-INF/jpql/named-queries.xml]
> {code}
> _Because corruption is about pointing out to a not-existing mapping file 
> named {{named-queries.xml}}_
> h4. Known workarounds
> # Of course we can fix the corrupted {{persistence.xml}} file, by removing 
> line:
> {{META-INF/jpql/named-queries.xml}}
> # We can also remove dependency to "deltaspike-data" from {{pom.xml}} as it 
> solves the issue 
>   Because then we got perfectly clear and correct message that tells us what 
> is wrong with {{persistene.xml}}.
> For further details, please see file *README.md* inside attached application.
> BTW: Why does the DeltaSpike parse persistence.xml at application startup? 
> Shouldn't this file be parsed with a lazy manner, at first usage of the 
> EntityManagerFactory?



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

[jira] [Commented] (DELTASPIKE-942) DeltaSpike fails to start with corrupted persistence.xml file.

2015-07-16 Thread Thomas Andraschko (JIRA) 

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

Thomas Andraschko commented on DELTASPIKE-942:
--

[~danielsoro] Would you like to check that?

> DeltaSpike fails to start with corrupted persistence.xml file.
> --
>
> Key: DELTASPIKE-942
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-942
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.4.1
> Environment:  * Java version: 1.8.0_40, vendor: Oracle Corporation
>  * Windows 7 Enterprise
>  * Apache Maven 3.2.3
>Reporter: Grzegorz Demecki
>  Labels: easyfix
> Attachments: DELTASPIKE-942-bug-showcase.zip
>
>
> h4. Details
> Please see attached sample web application and run it via: 
>  {code} mvn clean compile jetty:run {code}
> At startup we can see huge stack trace that tells literally nothing.
> {code:java}
> 2015-07-01 16:38:50.076:WARN:oeja.ServletContainerInitializersStarter:main:
> org.jboss.weld.exceptions.DefinitionException: Exception List with 1 
> exceptions:|Exception 0 :|java.lang.RuntimeException: Failed initializing 
> mapping files
>  at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.extractMappings(PersistenceUnitReader.java:82)
>  at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.lookupUnits(PersistenceUnitReader.java:54)
>  ...
> {code}
> Whereas the exception should look like:
> {code:java}
>  javax.servlet.ServletException: Caused by:
>  javax.persistence.PersistenceException: [PersistenceUnit: netadminPU] Unable 
> to resolve named mapping-file [META-INF/jpql/named-queries.xml]
> {code}
> _Because corruption is about pointing out to a not-existing mapping file 
> named {{named-queries.xml}}_
> h4. Known workarounds
> # Of course we can fix the corrupted {{persistence.xml}} file, by removing 
> line:
> {{META-INF/jpql/named-queries.xml}}
> # We can also remove dependency to "deltaspike-data" from {{pom.xml}} as it 
> solves the issue 
>   Because then we got perfectly clear and correct message that tells us what 
> is wrong with {{persistene.xml}}.
> For further details, please see file *README.md* inside attached application.
> BTW: Why does the DeltaSpike parse persistence.xml at application startup? 
> Shouldn't this file be parsed with a lazy manner, at first usage of the 
> EntityManagerFactory?



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

[jira] [Updated] (DELTASPIKE-942) DeltaSpike fails to start with corrupted persistence.xml file.

2015-07-16 Thread Thomas Andraschko (JIRA) 

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

Thomas Andraschko updated DELTASPIKE-942:
-
Assignee: Daniel Cunha (soro)  (was: Thomas Andraschko)

> DeltaSpike fails to start with corrupted persistence.xml file.
> --
>
> Key: DELTASPIKE-942
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-942
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.4.1
> Environment:  * Java version: 1.8.0_40, vendor: Oracle Corporation
>  * Windows 7 Enterprise
>  * Apache Maven 3.2.3
>Reporter: Grzegorz Demecki
>Assignee: Daniel Cunha (soro)
>  Labels: easyfix
> Attachments: DELTASPIKE-942-bug-showcase.zip
>
>
> h4. Details
> Please see attached sample web application and run it via: 
>  {code} mvn clean compile jetty:run {code}
> At startup we can see huge stack trace that tells literally nothing.
> {code:java}
> 2015-07-01 16:38:50.076:WARN:oeja.ServletContainerInitializersStarter:main:
> org.jboss.weld.exceptions.DefinitionException: Exception List with 1 
> exceptions:|Exception 0 :|java.lang.RuntimeException: Failed initializing 
> mapping files
>  at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.extractMappings(PersistenceUnitReader.java:82)
>  at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.lookupUnits(PersistenceUnitReader.java:54)
>  ...
> {code}
> Whereas the exception should look like:
> {code:java}
>  javax.servlet.ServletException: Caused by:
>  javax.persistence.PersistenceException: [PersistenceUnit: netadminPU] Unable 
> to resolve named mapping-file [META-INF/jpql/named-queries.xml]
> {code}
> _Because corruption is about pointing out to a not-existing mapping file 
> named {{named-queries.xml}}_
> h4. Known workarounds
> # Of course we can fix the corrupted {{persistence.xml}} file, by removing 
> line:
> {{META-INF/jpql/named-queries.xml}}
> # We can also remove dependency to "deltaspike-data" from {{pom.xml}} as it 
> solves the issue 
>   Because then we got perfectly clear and correct message that tells us what 
> is wrong with {{persistene.xml}}.
> For further details, please see file *README.md* inside attached application.
> BTW: Why does the DeltaSpike parse persistence.xml at application startup? 
> Shouldn't this file be parsed with a lazy manner, at first usage of the 
> EntityManagerFactory?



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

[jira] [Commented] (DELTASPIKE-942) DeltaSpike fails to start with corrupted persistence.xml file.

2015-07-16 Thread Daniel Cunha (soro) (JIRA) 

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

Daniel Cunha (soro) commented on DELTASPIKE-942:


Ok! I'll check soon. 

> DeltaSpike fails to start with corrupted persistence.xml file.
> --
>
> Key: DELTASPIKE-942
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-942
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.4.1
> Environment:  * Java version: 1.8.0_40, vendor: Oracle Corporation
>  * Windows 7 Enterprise
>  * Apache Maven 3.2.3
>Reporter: Grzegorz Demecki
>Assignee: Daniel Cunha (soro)
>  Labels: easyfix
> Attachments: DELTASPIKE-942-bug-showcase.zip
>
>
> h4. Details
> Please see attached sample web application and run it via: 
>  {code} mvn clean compile jetty:run {code}
> At startup we can see huge stack trace that tells literally nothing.
> {code:java}
> 2015-07-01 16:38:50.076:WARN:oeja.ServletContainerInitializersStarter:main:
> org.jboss.weld.exceptions.DefinitionException: Exception List with 1 
> exceptions:|Exception 0 :|java.lang.RuntimeException: Failed initializing 
> mapping files
>  at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.extractMappings(PersistenceUnitReader.java:82)
>  at 
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.lookupUnits(PersistenceUnitReader.java:54)
>  ...
> {code}
> Whereas the exception should look like:
> {code:java}
>  javax.servlet.ServletException: Caused by:
>  javax.persistence.PersistenceException: [PersistenceUnit: netadminPU] Unable 
> to resolve named mapping-file [META-INF/jpql/named-queries.xml]
> {code}
> _Because corruption is about pointing out to a not-existing mapping file 
> named {{named-queries.xml}}_
> h4. Known workarounds
> # Of course we can fix the corrupted {{persistence.xml}} file, by removing 
> line:
> {{META-INF/jpql/named-queries.xml}}
> # We can also remove dependency to "deltaspike-data" from {{pom.xml}} as it 
> solves the issue 
>   Because then we got perfectly clear and correct message that tells us what 
> is wrong with {{persistene.xml}}.
> For further details, please see file *README.md* inside attached application.
> BTW: Why does the DeltaSpike parse persistence.xml at application startup? 
> Shouldn't this file be parsed with a lazy manner, at first usage of the 
> EntityManagerFactory?



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

Re: Start Request scope manually fro a worker thread(asynchronous thread) in WAS8

2015-07-16 Thread akm 
Mark,

Now we are getting a NullPointer Exception while  trying to enable the CDI
features for the Worker thread (created by the concurrent ExecutorService
)in our MultiCore framework. Earlier It did work fine in our asynchronous 
framework when  the Worker Thread(Actually this worker thread is managed by
the websphere-web container) is created using the CommonJ-API.

WebSphere Platform  : 8.0.0.7 


[7/16/15 17:54:00:639 UTC] 00c5 ManagedBean   E ManagedBean
injectResources An error occured while injecting Java EE Resources for the
bean instance :
[org.apache.deltaspike.cdise.owb.OpenWebBeansContextControl@f23932f9]
[7/16/15 17:54:00:642 UTC] 00c5 TaskExecutor  E
com.ford.it.mccdi.TaskExecutor logTaskNotProcessedException
com.ford.it.mccdi.TaskExecutor@aca78cc4 Exception is 
 java.lang.NullPointerException
at
com.ibm.ws.webbeans.services.ResourceInjectionServiceImpl.injectJavaEEResources(ResourceInjectionServiceImpl.java:532)
at
org.apache.webbeans.component.AbstractInjectionTargetBean.injectResources(AbstractInjectionTargetBean.java:414)
at
org.apache.webbeans.portable.creation.InjectionTargetProducer.inject(InjectionTargetProducer.java:93)
at
org.apache.webbeans.component.InjectionTargetWrapper.inject(InjectionTargetWrapper.java:80)
at
org.apache.webbeans.component.AbstractOwbBean.create(AbstractOwbBean.java:175)
at
org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:69)
at
org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:191)
at
org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:892)
at
org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:137)




--
View this message in context: 
http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Start-Request-scope-manually-fro-a-worker-thread-asynchronous-thread-in-WAS8-tp4661026p4661126.html
Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at 
Nabble.com.

Re: Start Request scope manually fro a worker thread(asynchronous thread) in WAS8

2015-07-16 Thread akm 
CDI-WorkerThread.zip

  

Attached a Sample-EAR project..



--
View this message in context: 
http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Start-Request-scope-manually-fro-a-worker-thread-asynchronous-thread-in-WAS8-tp4661026p4661127.html
Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at 
Nabble.com.

[jira] [Resolved] (DELTASPIKE-957) Improve how TransactionStrategies are looked up

2015-07-16 Thread Gerhard Petracek (JIRA) 

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

Gerhard Petracek resolved DELTASPIKE-957.
-
Resolution: Not A Problem

@john:
if you don't agree with the arguments we provided (for keeping it as it is), 
please start a [discuss]-thread on the mailing-list (before we open this ticket 
again).
if you think that the documentation isn't clear enough about this topic, you 
are very welcome to improve the documentation.

> Improve how TransactionStrategies are looked up
> ---
>
> Key: DELTASPIKE-957
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-957
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Data-Module, Documentation, JPA-Module
>Affects Versions: 1.4.1
>Reporter: John D. Ament
>
> Currently transaction strategies are implemented as alternatives.  I created 
> a WAR for WildFly 9, and ran into a lot of issues getting it to work.  My WAR 
> has many JARs in it, all with beans.xml files.  I tried to enable the 
> alternative in various spots, but no luck, even went through all 30 beans.xml 
> files in my project and enabled it.  Still went with the default transaction 
> strategy.
> In order to fix, I had to enable a global alternative with the strategy.  
> This seems to go against our docs, which indicate it should be a regular 
> alternative.  
> I'd recommend a few things to think about.
> - Expect a concrete producer.
> - Use a class look up in apache-deltaspike.properties



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

Re: Start Request scope manually fro a worker thread(asynchronous thread) in WAS8

2015-07-16 Thread akm 
CDI-WorkerThread.zip

  

Attached a Sample-EAR Project.

TestCdiServlet -Front Controller...



--
View this message in context: 
http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Start-Request-scope-manually-fro-a-worker-thread-asynchronous-thread-in-WAS8-tp4661026p4661129.html
Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at 
Nabble.com.