[JBoss JIRA] (DROOLS-1252) java.lang.ClassCastException: event cannot be cast to org.drools.core.common.InternalFactHandle
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1252?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1252:
-------------------------------------
It's impossible for me to verify this issue without a proper reproducer. However I believe that the fix for https://issues.jboss.org/browse/DROOLS-1185 should also solve this problem. Can you please verify if this commit https://github.com/droolsjbpm/drools/commit/8c67d1604a4fbac9a3cfa2b560f6a... also works for you? If not I need a complete reproducer to further investigate this.
> java.lang.ClassCastException: event cannot be cast to org.drools.core.common.InternalFactHandle
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-1252
> URL: https://issues.jboss.org/browse/DROOLS-1252
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Environment: Drools 6.4.Final
> Fusion (CEP)
> Reporter: Michael Neifeld
> Assignee: Mario Fusco
> Priority: Blocker
> Attachments: RULES_ERRORS.log, Rule_Emergency_Network_Start_No_Active_Call_Rule523993873.java
>
>
> It seems to be similar to another bug DROOLS-1185, but without any Modify.
> this is the rule:
> {code:java}
> declare EmergencyNetworkComplexEvent
> @role(event)
> @timestamp(timestamp)
> @expires(1h)
> end
> ...
> global Logger dlogger;
> .....
> rule "Emergency Network Start No Active Call Rule" //EMERGENCY
> salience 90
> // no-loop true
> when
> //conditions
> $event : EmergencyNetworkComplexEvent( transition == Transition.START)
> $predecessor : CallComplexEvent( radioID == $event.radioID )
> not ( EmergencyActiveCallComplexEvent( getTransition() == Transition.START, getCallID() == $event.callID )
> or EmergencyActiveCallComplexEvent( getTransition() == Transition.START, getRadioID() == $event.radioID ))
> then
> if (dlogger.isTraceEnabled()) dlogger.trace("Emergency Network Start No Active Call Rule: receiving {}, {}",$event, $predecessor);
> // action: create container, add the event to the container
> EmergencyActiveCallComplexEvent container = new EmergencyActiveCallComplexEvent($event);
> insert(container);
> delete($event); // ???
> if (dlogger.isTraceEnabled()) dlogger.trace("Emergency Network Start No Active Call Rule: after delete {}",$event);
> //actions: register new active call, new emergency call
> new ActiveCallSnapshot().addCall($event);
> final EmergencyEventSnapshot snapshot = new EmergencyEventSnapshot();
> snapshot.addEmergencyCall($event);
> //actions: get preceding event and add it to trail
> snapshot.add2Trail($predecessor);
> if (dlogger.isTraceEnabled()) dlogger.trace("Emergency Network Start No Active Call Rule: exiting {}",container);
> end
> {code}
> and this is the classdump of this rule:
> {code:java}
> package com.mot.ssol.cep;
> import com.mot.ssol.cep.model.ComplexEventImpl;import com.mot.nsa.monitor.client.NetworkEvent;import com.mot.ssol.cep.model.PseudoActiveCallComplexEvent;import java.util.Date;import com.mot.nsa.monitor.client.CallEvent.ChannelStatus;import com.mot.ssol.cep.model.ControlCallComplexEvent;import com.mot.nsa.monitor.client.GaugeValue;import org.apache.commons.lang3.StringUtils;import com.mot.ssol.cep.TDMAResolver;import com.mot.ssol.cep.model.CEPEvent;import com.mot.ssol.cep.*;import com.mot.ssol.cep.model.InactiveCallComplexEvent;import org.kie.api.runtime.rule.QueryResults;import com.mot.ssol.cep.EventBuilder;import com.mot.nsa.monitor.client.CallEvent;import com.mot.ssol.cep.model.EmergencyNetworkComplexEvent;import com.mot.nsa.monitor.analyzer.AnalyzedEvent;import com.mot.ssol.cep.TrapSnapshot;import com.mot.nsa.monitor.cepm.mapper.RadioAliasMapper;import com.mot.nsa.monitor.MutableTimestampAware;import com.mot.ssol.cep.model.NetworkComplexEvent;import com.mot.ssol.cep.model.CallComplexEvent;import com.mot.ssol.cep.model.ControlNetworkComplexEvent;import java.util.concurrent.BlockingQueue;import com.mot.nsa.monitor.cepm.model.CallCepmEvent;import java.util.concurrent.LinkedBlockingQueue;import com.mot.ssol.cep.model.GroupRegistrationComplexEvent;import com.mot.nsa.monitor.cepm.mapper.GroupAliasMapper;import com.mot.ssol.cep.model.BusyComplexEventDecorator;import java.util.List;import com.mot.ssol.cep.model.ComplexEvent.Type;import com.mot.ssol.cep.EmergencyEventSnapshot;import com.mot.nsa.monitor.cepm.mapper.ZoneMapper;import com.mot.ssol.cep.model.NetworkComplexEventImpl;import com.mot.ssol.cep.model.ChannelHandle;import com.mot.nsa.monitor.cepm.StatisticModule;import com.mot.nsa.monitor.client.ClientEvent;import com.mot.nsa.monitor.client.RadioEvent;import com.mot.ssol.cep.model.CallComplexEventImpl;import com.mot.ssol.cep.model.ChannelCallComplexEvent;import org.kie.api.runtime.rule.QueryResultsRow;import com.mot.nsa.monitor.MutableTransitionAware;import com.mot.ssol.cep.model.RadioHandle;import com.mot.ssol.cep.ActiveCallSnapshot;import com.mot.nsa.monitor.TransitionAware.Transition;import org.drools.core.spi.KnowledgeHelper;import com.mot.ssol.cep.model.PseudoRadioRegistrationComplexEvent;import com.mot.ssol.cep.model.EmergencyActiveCallComplexEvent;import com.mot.nsa.monitor.cepm.model.NonCallEvent;import org.slf4j.Logger;import com.mot.ssol.cep.model.EmergencyComplexEventDecorator;import org.apache.commons.lang3.time.DateUtils;import com.mot.nsa.monitor.client.NetworkEventImpl;import com.mot.ssol.cep.CallEventSnapshot;import com.mot.ssol.cep.model.PendingComplexEvent;import com.mot.ssol.cep.model.RadioRegistrationComplexEvent;import com.mot.ssol.cep.model.ComplexEvent;import com.mot.nsa.monitor.client.CallEventImpl;import com.mot.ssol.cep.model.ActiveCallComplexEvent;import com.mot.nsa.monitor.cepm.model.CallCepmEventImpl;import com.mot.ssol.cep.model.PseudoCallComplexEvent;import org.drools.core.spi.KnowledgeHelper;import static com.mot.ssol.cep.ClearAll.clearAll;import static com.mot.ssol.cep.EndZoneCall.endZoneCall;import static com.mot.ssol.cep.Busies2End.busies2End;import static com.mot.ssol.cep.EndCallEvents.endCallEvents;import static com.mot.ssol.cep.Events2busy.events2busy;import static com.mot.ssol.cep.EndCall.endCall;import static com.mot.ssol.cep.Emergency2end.emergency2end;
> public class Rule_Emergency_Network_Start_No_Active_Call_Rule523993873 {
> private static final long serialVersionUID = 510l;
> public static void defaultConsequence(KnowledgeHelper drools, com.mot.ssol.cep.model.EmergencyNetworkComplexEvent $event, org.kie.api.runtime.rule.FactHandle $event__Handle__ , com.mot.ssol.cep.model.CallComplexEvent $predecessor, org.kie.api.runtime.rule.FactHandle $predecessor__Handle__ , org.slf4j.Logger dlogger ) throws java.lang.Exception { org.kie.api.runtime.rule.RuleContext kcontext = drools;
> if (dlogger.isTraceEnabled()) dlogger.trace("Emergency Network Start No Active Call Rule: receiving {}, {}",$event, $predecessor);
> // action: create container, add the event to the container
> EmergencyActiveCallComplexEvent container = new EmergencyActiveCallComplexEvent($event);
> drools.insert(container);
> { drools.delete( $event__Handle__ ); }; // ???
> if (dlogger.isTraceEnabled()) dlogger.trace("Emergency Network Start No Active Call Rule: after delete {}",$event);
> //actions: register new active call, new emergency call
> new ActiveCallSnapshot().addCall($event);
> final EmergencyEventSnapshot snapshot = new EmergencyEventSnapshot();
> snapshot.addEmergencyCall($event);
> //actions: get preceding event and add it to trail
> snapshot.add2Trail($predecessor);
> if (dlogger.isTraceEnabled()) dlogger.trace("Emergency Network Start No Active Call Rule: exiting {}",container);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1710) WFCORE-1106 work ignores fact that HostCapabilityScope exists
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1710:
----------------------------------------
Summary: WFCORE-1106 work ignores fact that HostCapabilityScope exists
Key: WFCORE-1710
URL: https://issues.jboss.org/browse/WFCORE-1710
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.0.Alpha4
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Alpha5
The WFCORE-1106 work for checking the runtime status of a capability assumes that only CapabilityScope.GLOBAL should be relevant when the check is performed. But this omits HostCapabilityScope which comes into play when host controller subsystems are used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBLOGGING-123) Support for tinylog
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-123?page=com.atlassian.jira.plu... ]
James Perkins commented on JBLOGGING-123:
-----------------------------------------
The {{org.jboss.logging.LoggerProvider}} is exposed as a service. This could be implemented in tinylog itself. The benefit of keeping the provider implementation with the log manager is if there is an API change to the log manager it will not require a change and release of JBoss Logging. I'd prefer to keep provider implementations out of JBoss Logging.
> Support for tinylog
> -------------------
>
> Key: JBLOGGING-123
> URL: https://issues.jboss.org/browse/JBLOGGING-123
> Project: JBoss Logging
> Issue Type: Feature Request
> Reporter: Martin Winandy
> Assignee: James Perkins
>
> tinylog is a lightweight logging framework for Java with a static logger class. For supporting tinylog in JBoss Logging, a logger provider has to be implemented and added to the LoggerProviders class.
> Link to tinylog website: http://www.tinylog.org/
> Example implementation for JBoss Logging: https://github.com/pmwmedia/jboss-logging/
> The tinylog implementation for JBoss Logging is out-dated, but I could adapt to the newest version.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6882:
------------------------------------
[~wdfink] "Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list."
>From where does this expectation come? The client will only be aware of nodes on which the given bean is deployed. If the application is a singleton, the topology size will only ever be 1. Thus for a client to be able to connect to a bean deployed as part of a singleton deployment, the client will have to be preconfigured with all possible servers.
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6943) javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-6943:
-----------------------------------
The current impl of ImportHandler probably works fine in non modular environments.
but in case of WildFly the EL api / impl classes are loaded from their own module and as such get module classloader that is limited to that module.
I think we could just fix or version of the ImportHandler to work with TCCL
> javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
> -------------------------------------------------------------------------
>
> Key: WFLY-6943
> URL: https://issues.jboss.org/browse/WFLY-6943
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 10.0.0.Final, 10.1.0.CR1
> Reporter: jaikiran pai
> Assignee: Jason Greene
>
> The EL 3.0 spec, section 1.22.2 states:
> {quote}
> Either a class or a package can be explicitly imported into the EL evaluation
> environment. Importing a package imports all the classes in the package. The classes
> that can be imported are restricted to the classes that can be loaded by the *current class loader*.
> The imports of packages, classes, and static fields are handled by the
> *ImportHandler* in the ELContext.
> {quote}
> It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported.
> The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method doesn't return the application specific Class instance back and instead returns null.
> This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/sr...
> {code}
> try {
> return Class.forName(className, false, getClass().getClassLoader());
> } catch (ClassNotFoundException ex) {
> notAClass.add(className);
> }
> {code}
> The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix to the API published by Oracle (as well as WildFly team's own copies).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6943) javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-6943:
-------------------------------
Description:
The EL 3.0 spec, section 1.22.2 states:
{quote}
Either a class or a package can be explicitly imported into the EL evaluation
environment. Importing a package imports all the classes in the package. The classes
that can be imported are restricted to the classes that can be loaded by the *current class loader*.
The imports of packages, classes, and static fields are handled by the
*ImportHandler* in the ELContext.
{quote}
It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported.
The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method doesn't return the application specific Class instance back and instead returns null.
This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/sr...
{code}
try {
return Class.forName(className, false, getClass().getClassLoader());
} catch (ClassNotFoundException ex) {
notAClass.add(className);
}
{code}
The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix to the API published by Oracle (as well as WildFly team's own copies).
was:
The EL 3.0 spec, section 1.22.2 states:
{quote}
Either a class or a package can be explicitly imported into the EL evaluation
environment. Importing a package imports all the classes in the package. The classes
that can be imported are restricted to the classes that can be loaded by the *current class loader*.
The imports of packages, classes, and static fields are handled by the
*ImportHandler* in the ELContext.
{quote}
It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported.
The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method doesn't return the application specific Class instance back and instead returns null.
This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/sr...
{code}
try {
return Class.forName(className, false, getClass().getClassLoader());
} catch (ClassNotFoundException ex) {
notAClass.add(className);
}
{code}
The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix the API published by Oracle (as well as WildFly team's own copies).
> javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
> -------------------------------------------------------------------------
>
> Key: WFLY-6943
> URL: https://issues.jboss.org/browse/WFLY-6943
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 10.0.0.Final, 10.1.0.CR1
> Reporter: jaikiran pai
> Assignee: Jason Greene
>
> The EL 3.0 spec, section 1.22.2 states:
> {quote}
> Either a class or a package can be explicitly imported into the EL evaluation
> environment. Importing a package imports all the classes in the package. The classes
> that can be imported are restricted to the classes that can be loaded by the *current class loader*.
> The imports of packages, classes, and static fields are handled by the
> *ImportHandler* in the ELContext.
> {quote}
> It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported.
> The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method doesn't return the application specific Class instance back and instead returns null.
> This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/sr...
> {code}
> try {
> return Class.forName(className, false, getClass().getClassLoader());
> } catch (ClassNotFoundException ex) {
> notAClass.add(className);
> }
> {code}
> The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix to the API published by Oracle (as well as WildFly team's own copies).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6943) javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-6943:
-------------------------------
Description:
The EL 3.0 spec, section 1.22.2 states:
{quote}
Either a class or a package can be explicitly imported into the EL evaluation
environment. Importing a package imports all the classes in the package. The classes
that can be imported are restricted to the classes that can be loaded by the *current class loader*.
The imports of packages, classes, and static fields are handled by the
*ImportHandler* in the ELContext.
{quote}
It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported.
The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method doesn't return the application specific Class instance back and instead returns null.
This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/sr...
{code}
try {
return Class.forName(className, false, getClass().getClassLoader());
} catch (ClassNotFoundException ex) {
notAClass.add(className);
}
{code}
The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix the API published by Oracle (as well as WildFly team's own copies).
was:
The EL 3.0 spec, section 1.22.2 states:
{quote}
Either a class or a package can be explicitly imported into the EL evaluation
environment. Importing a package imports all the classes in the package. The classes
that can be imported are restricted to the classes that can be loaded by the *current class loader*.
The imports of packages, classes, and static fields are handled by the
*ImportHandler* in the ELContext.
{quote}
It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported.
The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method doesn't return the application specific Class instance back and instead returns null.
This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/sr...
{code}
try {
return Class.forName(className, false, getClass().getClassLoader());
} catch (ClassNotFoundException ex) {
notAClass.add(className);
}
{code}
The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix the API published by Oracle (as well as our own copies).
> javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
> -------------------------------------------------------------------------
>
> Key: WFLY-6943
> URL: https://issues.jboss.org/browse/WFLY-6943
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 10.0.0.Final, 10.1.0.CR1
> Reporter: jaikiran pai
> Assignee: Jason Greene
>
> The EL 3.0 spec, section 1.22.2 states:
> {quote}
> Either a class or a package can be explicitly imported into the EL evaluation
> environment. Importing a package imports all the classes in the package. The classes
> that can be imported are restricted to the classes that can be loaded by the *current class loader*.
> The imports of packages, classes, and static fields are handled by the
> *ImportHandler* in the ELContext.
> {quote}
> It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported.
> The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method doesn't return the application specific Class instance back and instead returns null.
> This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/sr...
> {code}
> try {
> return Class.forName(className, false, getClass().getClassLoader());
> } catch (ClassNotFoundException ex) {
> notAClass.add(className);
> }
> {code}
> The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix the API published by Oracle (as well as WildFly team's own copies).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6943) javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
by Jive JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.... ]
Jive JIRA Integration updated WFLY-6943:
----------------------------------------
Forum Reference: https://developer.jboss.org/message/961282#961282
> javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
> -------------------------------------------------------------------------
>
> Key: WFLY-6943
> URL: https://issues.jboss.org/browse/WFLY-6943
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 10.0.0.Final, 10.1.0.CR1
> Reporter: jaikiran pai
> Assignee: Jason Greene
>
> The EL 3.0 spec, section 1.22.2 states:
> {quote}
> Either a class or a package can be explicitly imported into the EL evaluation
> environment. Importing a package imports all the classes in the package. The classes
> that can be imported are restricted to the classes that can be loaded by the *current class loader*.
> The imports of packages, classes, and static fields are handled by the
> *ImportHandler* in the ELContext.
> {quote}
> It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported.
> The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method doesn't return the application specific Class instance back and instead returns null.
> This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/sr...
> {code}
> try {
> return Class.forName(className, false, getClass().getClassLoader());
> } catch (ClassNotFoundException ex) {
> notAClass.add(className);
> }
> {code}
> The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix the API published by Oracle (as well as our own copies).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6943) javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-6943?page=com.atlassian.jira.plugin.... ]
jaikiran pai reassigned WFLY-6943:
----------------------------------
Assignee: Jason Greene
Assigning to Jason since he might know more about the spec.
This can be reproduced by uncommenting this line https://github.com/wildfly/wildfly/pull/9114/files#diff-63f7ae381250a1ccb... in the testcase included in that PR.
> javax.el.ImportHandler#resolveClass API doesn't use "current" classloader
> -------------------------------------------------------------------------
>
> Key: WFLY-6943
> URL: https://issues.jboss.org/browse/WFLY-6943
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 10.0.0.Final, 10.1.0.CR1
> Reporter: jaikiran pai
> Assignee: Jason Greene
>
> The EL 3.0 spec, section 1.22.2 states:
> {quote}
> Either a class or a package can be explicitly imported into the EL evaluation
> environment. Importing a package imports all the classes in the package. The classes
> that can be imported are restricted to the classes that can be loaded by the *current class loader*.
> The imports of packages, classes, and static fields are handled by the
> *ImportHandler* in the ELContext.
> {quote}
> It states that the "current" class loader is used to load those classes. Although it doesn't specifically state it as context classloader of the current thread, I suspect that's what it means since it makes sense to obviously allow application specific classes to be imported.
> The `javax.el.ImportHandler` class which is noted above as the one which handles resolution of these classes, is thus responsible for using the "current" class loader. However, the current implementation of the `javax.el.ImportHandler` instead uses the class loader which loaded the ImportHandler class itself, which of course leads to issues like the application specific class not being visible to it and thus the `resolveClass` method doesn't return the application specific Class instance back and instead returns null.
> This is what the current implementation looks like https://github.com/jboss/jboss-el-api_spec/blob/jboss-el-api_3.0-1.0.x/sr...
> {code}
> try {
> return Class.forName(className, false, getClass().getClassLoader());
> } catch (ClassNotFoundException ex) {
> notAClass.add(className);
> }
> {code}
> The fix would involve using the TCCL during the resolution, but I think this needs a clarification from the EL spec team and also a fix the API published by Oracle (as well as our own copies).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months