[JBoss JIRA] Commented: (WELD-56) Supporting proxies with no no-arg constructors
by Nicklas Karlsson (JIRA)
[ https://jira.jboss.org/jira/browse/WELD-56?page=com.atlassian.jira.plugin... ]
Nicklas Karlsson commented on WELD-56:
--------------------------------------
Because you weren't available for consultation ;-P
> Supporting proxies with no no-arg constructors
> ----------------------------------------------
>
> Key: WELD-56
> URL: https://jira.jboss.org/jira/browse/WELD-56
> Project: Weld
> Issue Type: Feature Request
> Components: Scopes & Contexts
> Reporter: Pete Muir
> Assignee: Nicklas Karlsson
> Fix For: 1.1.0.BETA1
>
>
> On Tue, May 12, 2009 at 1:11 AM, Jason T. Greene
> <jason.greene(a)redhat.com> wrote:
> Hi Everyone,
> As a non-standard extension, I was thinking that we could support generation
> proxies of classes not containing no-arg constructors by using various
> techniques that are supported by most JDKs.
> This would involve generating a proxy with a constructor call passing bogus
> parameters. Then a JDK specific approach would be used to instantiate the
> proxy class:
> Sun, IcedTea, Mac: Unsafe.allocateInstance() - The most efficient
> Above + IBM, JRockit: ReflectionFactory.newConstructorForSerialization()
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Commented: (WELD-56) Supporting proxies with no no-arg constructors
by Pete Muir (JIRA)
[ https://jira.jboss.org/jira/browse/WELD-56?page=com.atlassian.jira.plugin... ]
Pete Muir commented on WELD-56:
-------------------------------
Why did you choose system property name? It doesn't seem to reflect the purpose to me.
> Supporting proxies with no no-arg constructors
> ----------------------------------------------
>
> Key: WELD-56
> URL: https://jira.jboss.org/jira/browse/WELD-56
> Project: Weld
> Issue Type: Feature Request
> Components: Scopes & Contexts
> Reporter: Pete Muir
> Assignee: Nicklas Karlsson
> Fix For: 1.1.0.BETA1
>
>
> On Tue, May 12, 2009 at 1:11 AM, Jason T. Greene
> <jason.greene(a)redhat.com> wrote:
> Hi Everyone,
> As a non-standard extension, I was thinking that we could support generation
> proxies of classes not containing no-arg constructors by using various
> techniques that are supported by most JDKs.
> This would involve generating a proxy with a constructor call passing bogus
> parameters. Then a JDK specific approach would be used to instantiate the
> proxy class:
> Sun, IcedTea, Mac: Unsafe.allocateInstance() - The most efficient
> Above + IBM, JRockit: ReflectionFactory.newConstructorForSerialization()
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (WELD-461) WeldPhaseListener should only cleanup response once
by Dan Allen (JIRA)
WeldPhaseListener should only cleanup response once
---------------------------------------------------
Key: WELD-461
URL: https://jira.jboss.org/jira/browse/WELD-461
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.0.1.Final
Reporter: Dan Allen
Priority: Minor
FacesContext#getResponseCompete() may be true on more than one invocation of WeldPhaseListener#afterPhase(). Since the phase listener does not check to see if the request has already been cleaned up, Weld fails on the second cleanup attempt.
How does this scenario happen? One case is when the application calls ExternalContext#dispatch() to forward to another view. When the dispatch happens, the current lifecycle is marked FacesContext#responseComplete(). Control turns over to the lifecycle of the dispatched request. When the response is complete in that request, the WeldPhaseListener#afterPhase() will be called with FacesContext#getResponseComplete() equal to true. Control returns to the original request lifecycle, WeldPhaseListener#afterPhase() will again be called with FacesContext#getResponseComplete() equal to true.
The WeldPhaseListener should check to see if cleanup has already occurred, skipping cleanup if it has.
Applications should not expect contexts to be active in the original request lifecycle after ExternalContext#dispatch() has been called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years