[
https://jira.jboss.org/browse/WELD-615?page=com.atlassian.jira.plugin.sys...
]
David Allen commented on WELD-615:
----------------------------------
OK, so if package scoped members must be supported, then there really is no choice other
than to use the CL of that class or interface, and not the TCCL.
This does lead to strange deployment behaviors in most application servers, since
application proxy classes will remain in a server even when the application is undeployed;
however, there should be no other references to those classes.
Change proxy CL to TCCL in default ProxyServices implementation
---------------------------------------------------------------
Key: WELD-615
URL:
https://jira.jboss.org/browse/WELD-615
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.BETA1
Reporter: David Allen
Assignee: David Allen
Fix For: 1.1.0.BETA2
There is still a problem with many applications and servers by not using the TCCL for
proxy classes. GAE for instance was using the TCCL by initializing the static member of
Javassist's ProxyFactory, and GlassFish needs to do the same.
The only reason not to use TCCL is based on how the TCK and other tests are written for
Weld: they make use of package protected classes and members. Since this approach to
writing application classes is not common in practice (usually private, protected or
public scope specified), I would recommend changing the default ProxyServices
implementation to support the common practice and not our tests. The test frameworks or
test sets can probably be changed to provide a different ProxyServices implementation.
Off hand I don't know exactly how that can happen yet, but I think it's worth
investigating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira