[jira] [Commented] (DELTASPIKE-905) Missing OSGi headers in Proxy modules

[Gerhard Petracek (JIRA)]

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

Gerhard Petracek commented on DELTASPIKE-905:
-

@harald:
in ds we keep the api as clean as possible and therefore it should only contain 
parts which are important to users.

> Missing OSGi headers in Proxy modules
> -
>
> Key: DELTASPIKE-905
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-905
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: PartialBean
>Affects Versions: 1.4.0
>Reporter: Harald Wellmann
>Assignee: Rafael Benevides
> Fix For: 1.4.1
>
>
> {{deltaspike-partial-bean-module-impl}} imports package 
> {{org.apache.deltaspike.proxy.api}}, but the new proxy modules are missing 
> OSGi manifest headers.
> This breaks Partial Beans and Data modules for OSGi users.



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

[jira] [Commented] (DELTASPIKE-905) Missing OSGi headers in Proxy modules

[Harald Wellmann (JIRA)]

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

Harald Wellmann commented on DELTASPIKE-905:


If you delete {{ProxyClassGeneratorLookup.java}}, you'll also have to adapt 
{{deltaspike/modules/proxy/api/src/main/resources/OSGI-INF/ProxyClassGeneratorLookup.xml}}
 which I don't see in your PR.

By the way, what's the motivation for inlining this class? It shouldn't make 
much of a difference one way or the other, I'm just curious about the point 
you're trying to improve which seems to escape me.

> Missing OSGi headers in Proxy modules
> -
>
> Key: DELTASPIKE-905
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-905
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: PartialBean
>Affects Versions: 1.4.0
>Reporter: Harald Wellmann
>Assignee: Rafael Benevides
> Fix For: 1.4.1
>
>
> {{deltaspike-partial-bean-module-impl}} imports package 
> {{org.apache.deltaspike.proxy.api}}, but the new proxy modules are missing 
> OSGi manifest headers.
> This breaks Partial Beans and Data modules for OSGi users.



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

[jira] [Commented] (DELTASPIKE-905) Missing OSGi headers in Proxy modules

[Rafael Benevides (JIRA)]

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

Rafael Benevides commented on DELTASPIKE-905:
-

[~hwellmann]

Can you test the following changes, please 
https://github.com/apache/deltaspike/pull/36 ?

Thanks

> Missing OSGi headers in Proxy modules
> -
>
> Key: DELTASPIKE-905
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-905
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: PartialBean
>Affects Versions: 1.4.0
>Reporter: Harald Wellmann
>Assignee: Rafael Benevides
> Fix For: 1.4.1
>
>
> {{deltaspike-partial-bean-module-impl}} imports package 
> {{org.apache.deltaspike.proxy.api}}, but the new proxy modules are missing 
> OSGi manifest headers.
> This breaks Partial Beans and Data modules for OSGi users.



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

[GitHub] deltaspike pull request: DELTASPIKE-905 - move the code from Proxy...

[rafabene]

GitHub user rafabene opened a pull request:

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

DELTASPIKE-905 - move the code from ProxyClassGeneratorLookup to Delt…

…aSpikeProxyFactory (1:1)

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

$ git pull https://github.com/rafabene/deltaspike DELTASPIKE-905

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

https://github.com/apache/deltaspike/pull/36.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 #36


commit 9805337380a7cc621c35d5ccc053cf025e9a3c09
Author: Rafael Benevides 
Date:   2015-06-02T19:15:06Z

DELTASPIKE-905 - move the code from ProxyClassGeneratorLookup to 
DeltaSpikeProxyFactory (1:1)




---
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] [Commented] (DELTASPIKE-905) Missing OSGi headers in Proxy modules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DELTASPIKE-905:
---

GitHub user rafabene opened a pull request:

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

DELTASPIKE-905 - move the code from ProxyClassGeneratorLookup to Delt…

…aSpikeProxyFactory (1:1)

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

$ git pull https://github.com/rafabene/deltaspike DELTASPIKE-905

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

https://github.com/apache/deltaspike/pull/36.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 #36


commit 9805337380a7cc621c35d5ccc053cf025e9a3c09
Author: Rafael Benevides 
Date:   2015-06-02T19:15:06Z

DELTASPIKE-905 - move the code from ProxyClassGeneratorLookup to 
DeltaSpikeProxyFactory (1:1)




> Missing OSGi headers in Proxy modules
> -
>
> Key: DELTASPIKE-905
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-905
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: PartialBean
>Affects Versions: 1.4.0
>Reporter: Harald Wellmann
>Assignee: Rafael Benevides
> Fix For: 1.4.1
>
>
> {{deltaspike-partial-bean-module-impl}} imports package 
> {{org.apache.deltaspike.proxy.api}}, but the new proxy modules are missing 
> OSGi manifest headers.
> This breaks Partial Beans and Data modules for OSGi users.



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

[jira] [Reopened] (DELTASPIKE-905) Missing OSGi headers in Proxy modules

[Rafael Benevides (JIRA)]

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

Rafael Benevides reopened DELTASPIKE-905:
-

move the code from ProxyClassGeneratorLookup to DeltaSpikeProxyFactory (1:1) 
and change the class in AsmProxyClassGenerator.xml + ask harald to test the 
change

> Missing OSGi headers in Proxy modules
> -
>
> Key: DELTASPIKE-905
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-905
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: PartialBean
>Affects Versions: 1.4.0
>Reporter: Harald Wellmann
>Assignee: Rafael Benevides
> Fix For: 1.4.1
>
>
> {{deltaspike-partial-bean-module-impl}} imports package 
> {{org.apache.deltaspike.proxy.api}}, but the new proxy modules are missing 
> OSGi manifest headers.
> This breaks Partial Beans and Data modules for OSGi users.



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

[jira] [Resolved] (DELTASPIKE-905) Missing OSGi headers in Proxy modules

[Gerhard Petracek (JIRA)]

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

Gerhard Petracek resolved DELTASPIKE-905.
-
Resolution: Fixed
  Assignee: Rafael Benevides

> Missing OSGi headers in Proxy modules
> -
>
> Key: DELTASPIKE-905
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-905
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: PartialBean
>Affects Versions: 1.4.0
>Reporter: Harald Wellmann
>Assignee: Rafael Benevides
> Fix For: 1.4.1
>
>
> {{deltaspike-partial-bean-module-impl}} imports package 
> {{org.apache.deltaspike.proxy.api}}, but the new proxy modules are missing 
> OSGi manifest headers.
> This breaks Partial Beans and Data modules for OSGi users.



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

[jira] [Commented] (DELTASPIKE-914) Rendering a dynamic p:graphicImage whose StreamConent is in a Deltaspike ViewScoped bean seems not to work

[Thomas Andraschko (JIRA)]

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

Thomas Andraschko commented on DELTASPIKE-914:
--

Yep.
As gerhard said, you can manually activate the WindowContext/ViewAccessContext 
in your bean which creates the StreamedContent in the resource request.

> Rendering a dynamic p:graphicImage whose StreamConent is in a Deltaspike 
> ViewScoped bean seems not to work
> --
>
> Key: DELTASPIKE-914
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-914
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module
>Affects Versions: 1.4.0
> Environment: All containers - tested on Weblogic 12.1.2 but the issue 
> is cross cuting
>Reporter: Nuno G. de M
>Assignee: Thomas Andraschko
>  Labels: graphicImage, primefaces, viewaccesscoped
>
> Hi,
> This issue has to do with incompatibility between primefaces p:graphicImage 
> and deltaSpike ViewAccessScoped beans.
> The prime faces graphic image apperently has two core modes of rendering an 
> html  component. On one mode it will generate a resource to a statically 
> available image. 
> Under this scenario we have no problems even when workign with a 
> ViewAccessScoped bean to provide the img resource path.
> Such as:
>  
> 
> 
> 
>  value="#{resource[viewScopeadBean.imageResource]}"  width="250px" 
> height="250px" rendered="true" />
> 
> However, when rendering dynamic content, ViewAccess scoped beans are not 
> compatible, as the primefaces dynamic content handler tries to evaluate a 
> ValueExpression and the ViewScopedBean context appears not to be active.
> 
> 
> 
> 
>  value="#{viewScopeadBean.streamedContent}"  width="250px" height="250px" 
> rendered="true" />
> 
> 
>  Ok and here we have our bug. 
> The problem we have here seems to be that 
> PrimeResourceHandler and the GraphicImageRenderer work together without 
> problems with deltaspike when dealing with static content. 
> However, when we are dealing with dynaminc content 
> set on page bean
> the Renderer will tune the session context with the 
> expression language of the .xhtml page so when the browser asks for the img 
> src, 
> PrimeResourceHandler will be able to discover what EL 
> was associated to that img resource
> and resolve on the fly the dynamic content asked by 
> the user.
> However, the view access scoped seems not be 
> available for PrimeFaces so he comes out empty handed.
> 
> 
> I have written a small sample application that renders the image of a 
> labrador using both flavors (static resource and dynamic resource).
> https://github.com/99sono/delta-spike-dynamic-content_issue
> https://github.com/99sono/delta-spike-dynamic-content_issue/blob/master/src/main/resources/BugOverview.docx
> I am not sure if a bug should not be opened as well to primefaces, since it 
> looks to me that addressing this issue will most likely require coordination 
> on both teams.
> The only work-around for this seems to be to re-factor code to use request 
> scoped beans or session scoped beans.
> Or if geting view scoped beans to work together with this component is really 
> a must, which in our case it is
> We will have to come-up with a temporary hack to the
> p:graphicImage renderer and to the PrimeResourceHandler to be able to somehow 
> bypass the fact that ViewAccess scope is not available.
> I really do not wish to go down this path  - more than temporarily.
> Thank you for your support,
> Kindest regards,
> Nuno.



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

Re: Build failed in Jenkins: DeltaSpike_TomEE_1.7.2 #279

[Mark Struberg]

Hi folks!

I’ve fixed the broken OWB build. The reason was that TomEE changed the groupId 
for the openejb stuff from org.apache.openejb/openejb-core to 
org.apache.tomee/openejb-core, etc. 

Please note that OWB-1.5.0 is not used in any released OpenEJB/TomEE version 
and thus we cannot really test it. I yesterday released OWB-1.6.0 (VOTE 
ongoing) which is used in TomEE-7.0.0.

So by using

$> mvn clean install -POWB15 -Dowb.version=1.6.0-SNAPSHOT 
-Dopenejb.version=7.0.0-SNAPSHOT -POpenEJB-TomEE

we can compile the project. In 2 days we can drop the snapshot from owb.

Will change our CI build accordingly.

LieGrue,
strub


> Am 28.04.2015 um 16:21 schrieb Apache Jenkins Server 
> :
> 
> See 
> 
> --
> [...truncated 754 lines...]
> Compression is 0.0%
> Took 1.2 sec
> [JENKINS] Archiving 
> 
>  to 
> org.apache.deltaspike.modules/partial-bean-module-project/1.3.1-SNAPSHOT/partial-bean-module-project-1.3.1-SNAPSHOT.pom
> Sending artifact delta relative to DeltaSpike_TomEE_1.7.2 » Apache DeltaSpike 
> Partial-Bean-Module #270
> Archived 1 artifacts
> Archive block size is 32768
> Received 0 blocks and 1742 bytes
> Compression is 0.0%
> Took 0.31 sec
> [JENKINS] Archiving 
> 
>  to 
> org.apache.deltaspike.examples/examples-project/1.3.1-SNAPSHOT/examples-project-1.3.1-SNAPSHOT.pom
> Sending artifact delta relative to DeltaSpike_TomEE_1.7.2 » Apache DeltaSpike 
> Examples #270
> Archived 1 artifacts
> Archive block size is 32768
> Received 0 blocks and 2903 bytes
> Compression is 0.0%
> Took 0.19 sec
> [JENKINS] Archiving 
> 
>  to 
> org.apache.deltaspike.cdictrl/deltaspike-cdictrl-openejb/1.3.1-SNAPSHOT/deltaspike-cdictrl-openejb-1.3.1-SNAPSHOT.pom
> Sending artifact delta relative to DeltaSpike_TomEE_1.7.2 » Apache DeltaSpike 
> CDI OpenEJB-ContainerControl #270
> Archived 1 artifacts
> Archive block size is 32768
> Received 0 blocks and 6256 bytes
> Compression is 0.0%
> Took 0.53 sec
> [JENKINS] Archiving 
> 
>  to 
> org.apache.deltaspike.modules/jsf-module-project/1.3.1-SNAPSHOT/jsf-module-project-1.3.1-SNAPSHOT.pom
> Sending artifact delta relative to DeltaSpike_TomEE_1.7.2 » Apache DeltaSpike 
> JSF-Module #270
> Archived 1 artifacts
> Archive block size is 32768
> Received 0 blocks and 2695 bytes
> Compression is 0.0%
> Took 0.44 sec
> [JENKINS] Archiving 
> 
>  to 
> org.apache.deltaspike.test/deltaspike-cdictrl-tck/1.3.1-SNAPSHOT/deltaspike-cdictrl-tck-1.3.1-SNAPSHOT.pom
> Sending artifact delta relative to DeltaSpike_TomEE_1.7.2 » Apache DeltaSpike 
> CDI ContainerControl TCK #270
> Archived 1 artifacts
> Archive block size is 32768
> Received 0 blocks and 3591 bytes
> Compression is 0.0%
> Took 0.21 sec
> [JENKINS] Archiving 
> 
>  to 
> org.apache.deltaspike.modules/deltaspike-jsf-module-api/1.3.1-SNAPSHOT/deltaspike-jsf-module-api-1.3.1-SNAPSHOT.pom
> Sending artifact delta relative to DeltaSpike_TomEE_1.7.2 » Apache DeltaSpike 
> JSF-Module API #270
> Archived 1 artifacts
> Archive block size is 32768
> Received 0 blocks and 2089 bytes
> Compression is 0.0%
> Took 0.41 sec
> [JENKINS] Archiving 
> 
>  to 
> org.apache.deltaspike.modules/security-module-project/1.3.1-SNAPSHOT/security-module-project-1.3.1-SNAPSHOT.pom
> Sending artifact delta relative to DeltaSpike_TomEE_1.7.2 » Apache DeltaSpike 
> Security-Module #270
> Archived 1 artifacts
> Archive block size is 32768
> Received 0 blocks and 1726 bytes
> Compression is 0.0%
> Took 0.38 sec
> [JENKINS] Archiving 
> 
>  to 
> org.apache.deltaspike.modules/bean-validation-module-project/1.3.1-SNAPSHOT/bean-validation-module-project-1.3.1-SNAPSHOT.pom
> Sending artifact delta relative to DeltaSpike_TomEE_1.7.2 » Apache DeltaSpike 
> BeanValidation-Module #270
> Archived 1 artifacts
> Archive block size is 32768
> Received 0 blocks and 1754 bytes
> Compression is 0.0%
> Took 1.4 sec
> [JENKINS] Archiving 
> 
>  to 
> org.apache.deltaspike.modules/deltaspike-partial-bean-module-impl/1.3.1-SNAPSHOT/deltaspike-partial-bean-module-impl-1.3.1-SNAPSHOT.pom
> Sending artifact delta relative to DeltaSpike_TomEE_1.7.2 » Apache 

[jira] [Commented] (DELTASPIKE-914) Rendering a dynamic p:graphicImage whose StreamConent is in a Deltaspike ViewScoped bean seems not to work

[Nuno G. de M (JIRA)]

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

Nuno G. de M commented on DELTASPIKE-914:
-

Hi Gerhard,

I see that the issue is closed with resolution:
Won't fix.

This means that on delta spike side, there is no intention in the nearby future 
to support Window Context based scopes on ResourHandler requests?

Therefore, from your point of view, the solution for this issue is either a 
work-around - e.g. the advanced graphic image renderer process, or primefaces 
will have to enhanced their graphic image feature to be more reselient to Value 
Expressions of different nature.
Can you please verify that what I am assuming here is correct?


Many thanks.

> Rendering a dynamic p:graphicImage whose StreamConent is in a Deltaspike 
> ViewScoped bean seems not to work
> --
>
> Key: DELTASPIKE-914
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-914
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: JSF-Module
>Affects Versions: 1.4.0
> Environment: All containers - tested on Weblogic 12.1.2 but the issue 
> is cross cuting
>Reporter: Nuno G. de M
>Assignee: Thomas Andraschko
>  Labels: graphicImage, primefaces, viewaccesscoped
>
> Hi,
> This issue has to do with incompatibility between primefaces p:graphicImage 
> and deltaSpike ViewAccessScoped beans.
> The prime faces graphic image apperently has two core modes of rendering an 
> html  component. On one mode it will generate a resource to a statically 
> available image. 
> Under this scenario we have no problems even when workign with a 
> ViewAccessScoped bean to provide the img resource path.
> Such as:
>  
> 
> 
> 
>  value="#{resource[viewScopeadBean.imageResource]}"  width="250px" 
> height="250px" rendered="true" />
> 
> However, when rendering dynamic content, ViewAccess scoped beans are not 
> compatible, as the primefaces dynamic content handler tries to evaluate a 
> ValueExpression and the ViewScopedBean context appears not to be active.
> 
> 
> 
> 
>  value="#{viewScopeadBean.streamedContent}"  width="250px" height="250px" 
> rendered="true" />
> 
> 
>  Ok and here we have our bug. 
> The problem we have here seems to be that 
> PrimeResourceHandler and the GraphicImageRenderer work together without 
> problems with deltaspike when dealing with static content. 
> However, when we are dealing with dynaminc content 
> set on page bean
> the Renderer will tune the session context with the 
> expression language of the .xhtml page so when the browser asks for the img 
> src, 
> PrimeResourceHandler will be able to discover what EL 
> was associated to that img resource
> and resolve on the fly the dynamic content asked by 
> the user.
> However, the view access scoped seems not be 
> available for PrimeFaces so he comes out empty handed.
> 
> 
> I have written a small sample application that renders the image of a 
> labrador using both flavors (static resource and dynamic resource).
> https://github.com/99sono/delta-spike-dynamic-content_issue
> https://github.com/99sono/delta-spike-dynamic-content_issue/blob/master/src/main/resources/BugOverview.docx
> I am not sure if a bug should not be opened as well to primefaces, since it 
> looks to me that addressing this issue will most likely require coordination 
> on both teams.
> The only work-around for this seems to be to re-factor code to use request 
> scoped beans or session scoped beans.
> Or if geting view scoped beans to work together with this component is really 
> a must, which in our case it is
> We will have to come-up with a temporary hack to the
> p:graphicImage renderer and to the PrimeResourceHandler to be able to somehow 
> bypass the fact that ViewAccess scope is not available.
> I really do not wish to go down this path  - more than temporarily.
> Thank you for your support,
> Kindest regards,
> Nuno.



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