[JBoss JIRA] Created: (JBAS-8126) CNFE Exceptions due to the wrong classloader being used
by Stelios Koussouris (JIRA)
CNFE Exceptions due to the wrong classloader being used
-------------------------------------------------------
Key: JBAS-8126
URL: https://jira.jboss.org/browse/JBAS-8126
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: JBossAS-5.1.0.GA
Reporter: Stelios Koussouris
Assignee: Alexey Loubyansky
The unified classloader is used loading an interface from another jar archive in the /deploy when that interface is called from within a scoped EAR rather than the interface included in the EAR itself.
Our tests show when an interface is in a jar in the deploy directory and also in the scoped my.ear Once passivate gets called from a class within the EAR, that calls that interface, then it throws a ClassCastException on ClassLocal myEJB = ClassLocal.class.cast(obj);
However it is actually a ClassNotFound, looking in the debugger. We see that instead of using the context of the ejb which would be the EAR classloader, the unified classloader is used instead and hence the resulting exception
--
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
13 years, 10 months
[JBoss JIRA] Created: (JBPORTAL-2479) Character encoding incorrect with CASAuthenticationValve enabled
by Martin Putz (JIRA)
Character encoding incorrect with CASAuthenticationValve enabled
----------------------------------------------------------------
Key: JBPORTAL-2479
URL: https://jira.jboss.org/browse/JBPORTAL-2479
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Identity
Affects Versions: 2.7.2 Final, Identity-1.1
Reporter: Martin Putz
With CASAuthenticationValve enabled, data inserted is returned garbled. In the invoke() method, the parameters are retrieved from the request object. This parses the parameters before any character encoding has been set, but it sets the parameters parsed flag to true. Therefore the encoding will never get set.
To get around this, request.setCharacterEncoding(..) needs to be called before any request parameters are retrieved.
--
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
13 years, 10 months
[JBoss JIRA] Created: (JBEE-50) ScheduleExpression.getTimezone() should return null for default @Schedule
by jaikiran pai (JIRA)
ScheduleExpression.getTimezone() should return null for default @Schedule
-------------------------------------------------------------------------
Key: JBEE-50
URL: https://jira.jboss.org/browse/JBEE-50
Project: JBoss JavaEE APIs
Issue Type: Bug
Components: EJB API
Affects Versions: 1.0.0.Beta2-ejb-3.1-api
Reporter: jaikiran pai
Assignee: jaikiran pai
For a default @Schedule when timezone is *not* explicitly specified, the EJB3.1 spec says:
[97] Note that annotation java.lang.String attributes use the empty string "" as a default, so the expression @Schedule(timezone="", ...) will result in a null value from the corresponding ScheduleExpression.getTimezone() method.
Right now, ScheduleExpression.getTimezone() returns an empty string for a default @Schedule
--
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
13 years, 10 months