[JBoss JIRA] (WFCORE-4206) Elytron extension module has un-used optional dependency
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-4206?page=com.atlassian.jira.plugi... ]
Yeray Borges edited comment on WFCORE-4206 at 11/23/18 9:13 AM:
----------------------------------------------------------------
I was going to create the PR, but some loadClass methods in the Elytron subsystem make me a bit reluctant.
CustomComponentDefinition, JaspiDefinition and CustomPolicyDefinition could load classes using org.wildfly.extension.elytron module, so I'm not sure if a class visible to this module is subcetible of contain code that works procesing annotations included in javax.annotation.api.
I found this module was added [here|https://github.com/wildfly-security/elytron-subsystem/commit/251f159...] and removed [here|https://github.com/wildfly-security/elytron-subsystem/commit/f882557...], it is the old branch used for elytron integration so probably we can safely remove it. I don't know why the removal was not mirrored in wildfly-core.
[~dlofthouse], based on the above, could you confirm if we can remove javax.annotation.api from org.wildfly.extension.elytron?
was (Author: yersan):
I was going to create the PR, but some loadClass methods in the Elytron subsystem make me a bit reluctant.
CustomComponentDefinition, JaspiDefinition and CustomPolicyDefinition could load classes using org.wildfly.extension.elytron module, so I'm not sure if a class visible to this module is subcetible of contain code that works procesing annotations included in javax.annotation.api.
I found this module was added [here|https://github.com/wildfly-security/elytron-subsystem/commit/251f159...] and removed [here|https://github.com/wildfly-security/elytron-subsystem/commit/f882557...], it is the old branch used for elytron integration so probable we can safely remove it.I don't know whay the removal was not mirrored in wildfly-core.
[~dlofthouse], based on the above, could you confirm if we can remove javax.annotation.api from org.wildfly.extension.elytron?
> Elytron extension module has un-used optional dependency
> --------------------------------------------------------
>
> Key: WFCORE-4206
> URL: https://issues.jboss.org/browse/WFCORE-4206
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean-Francois Denise
> Assignee: Yeray Borges
> Priority: Minor
>
> javax.annotation.api doesn't seem use by the module. Optional dep could be removed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (JBJCA-1386) TCCL is not set to datasource module
by Bartosz Spyrko-Śmietanko (Jira)
[ https://issues.jboss.org/browse/JBJCA-1386?page=com.atlassian.jira.plugin... ]
Bartosz Spyrko-Śmietanko moved WFLY-11407 to JBJCA-1386:
--------------------------------------------------------
Project: IronJacamar (was: WildFly)
Key: JBJCA-1386 (was: WFLY-11407)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Component/s: (was: JCA)
Affects Version/s: WildFly/IronJacamar 1.4.2.Final
(was: 13.0.0.Final)
> TCCL is not set to datasource module
> ------------------------------------
>
> Key: JBJCA-1386
> URL: https://issues.jboss.org/browse/JBJCA-1386
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: WildFly/IronJacamar 1.4.2.Final
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
> Priority: Major
>
> TCCL is not set to datasource module
> User has a datasource that uses ORB classes and is getting a ClassNotFound.
> If a 3rd party JDBC driver implementation is using e. g. CORBA, the class loader is not set and thus the CORBA classes got loaded from the 'org.jboss.as.connector' modules class loader.
> So the root cause is the Thread Context ClassLoader (TCCL) is not set to the classloader/module of the datasource driver module. The particular datasource driver is making using of ORB.init which is a JDK class that looks on the TCCL and other places to load the class specified in ORB.init, but JCA when running has not set the TCCL thus the classes cannot be found.
> Having the TCCL set to the application is how JEE handles related situations to load application classes, so it would make sense that when JCA is running the datasource that it would have the TCCL set to the module of the datasource or a delegate class loader that sees both the datasource module and any other class loader that JCA might need, JBossWS does something similar.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11407) TCCL is not set to datasource module
by Bartosz Spyrko-Śmietanko (Jira)
Bartosz Spyrko-Śmietanko created WFLY-11407:
-----------------------------------------------
Summary: TCCL is not set to datasource module
Key: WFLY-11407
URL: https://issues.jboss.org/browse/WFLY-11407
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 13.0.0.Final
Reporter: Bartosz Spyrko-Śmietanko
Assignee: Stefano Maestri
TCCL is not set to datasource module
User has a datasource that uses ORB classes and is getting a ClassNotFound.
If a 3rd party JDBC driver implementation is using e. g. CORBA, the class loader is not set and thus the CORBA classes got loaded from the 'org.jboss.as.connector' modules class loader.
So the root cause is the Thread Context ClassLoader (TCCL) is not set to the classloader/module of the datasource driver module. The particular datasource driver is making using of ORB.init which is a JDK class that looks on the TCCL and other places to load the class specified in ORB.init, but JCA when running has not set the TCCL thus the classes cannot be found.
Having the TCCL set to the application is how JEE handles related situations to load application classes, so it would make sense that when JCA is running the datasource that it would have the TCCL set to the module of the datasource or a delegate class loader that sees both the datasource module and any other class loader that JCA might need, JBossWS does something similar.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months