[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated WFLY-3197:
-------------------------------------
Description:
WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found.
Steps to reproduce:
1. define isolated module IM ( with classloader IM_CL )
2. create external-context-factory with module set to IM
3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies
4. lookup and invoke proxy
Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing.
Case 1: application and custom context dont do CCL magic
- invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found )
Case 2: application or custom context switch CCL to IM_CL for lookup
- CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably
Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL.
Workaround:
yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation.
Possible fix:
1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic
2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes
was:
WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found.
Steps to reproduce:
1. define isolated module IM ( with classloader IM_CL )
2. create external-context-factory with module set to IM
3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies
4. lookup and invoke proxy
Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing.
Case 1: application and custom context dont do CCL magic
- invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found )
Case 2: application or custom context switch CCL to IM_CL for lookup
- CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably
Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL.
Workaround:
yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation.
Possible fix:
1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic
2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes
> ExternalContextFactory cuts context from deployment context/requires dependency on module
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3197
> URL: https://issues.jboss.org/browse/WFLY-3197
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Final, 8.0.1.Final
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Fix For: 8.0.1.Final
>
>
> WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found.
> Steps to reproduce:
> 1. define isolated module IM ( with classloader IM_CL )
> 2. create external-context-factory with module set to IM
> 3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies
> 4. lookup and invoke proxy
> Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing.
> Case 1: application and custom context dont do CCL magic
> - invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found )
> Case 2: application or custom context switch CCL to IM_CL for lookup
> - CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably
> Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL.
> Workaround:
> yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation.
> Possible fix:
> 1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic
> 2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated WFLY-3197:
-------------------------------------
Fix Version/s: 8.0.1.Final
Affects Version/s: 8.0.0.Final
8.0.1.Final
> ExternalContextFactory cuts context from deployment context/requires dependency on module
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3197
> URL: https://issues.jboss.org/browse/WFLY-3197
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Final, 8.0.1.Final
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Fix For: 8.0.1.Final
>
>
> WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found.
> Steps to reproduce:
> 1. define isolated module IM ( with classloader IM_CL )
> 2. create external-context-factory with module set to IM
> 3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies
> 4. lookup and invoke proxy
> Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing.
> Case 1: application and custom context dont do CCL magic
> - invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found )
> Case 2: application or custom context switch CCL to IM_CL for lookup
> - CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably
> Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL.
> Workaround:
> yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation.
> Possible fix:
> 1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic
> 2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3197?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski commented on WFLY-3197:
------------------------------------------
[~dmlloyd] ^^
> ExternalContextFactory cuts context from deployment context/requires dependency on module
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3197
> URL: https://issues.jboss.org/browse/WFLY-3197
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Final, 8.0.1.Final
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Fix For: 8.0.1.Final
>
>
> WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found.
> Steps to reproduce:
> 1. define isolated module IM ( with classloader IM_CL )
> 2. create external-context-factory with module set to IM
> 3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies
> 4. lookup and invoke proxy
> Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing.
> Case 1: application and custom context dont do CCL magic
> - invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found )
> Case 2: application or custom context switch CCL to IM_CL for lookup
> - CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably
> Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL.
> Workaround:
> yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation.
> Possible fix:
> 1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic
> 2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-3197) ExternalContextFactory cuts context from deployment context/requires dependency on module
by Bartosz Baranowski (JIRA)
Bartosz Baranowski created WFLY-3197:
----------------------------------------
Summary: ExternalContextFactory cuts context from deployment context/requires dependency on module
Key: WFLY-3197
URL: https://issues.jboss.org/browse/WFLY-3197
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Naming
Reporter: Bartosz Baranowski
Assignee: Bartosz Baranowski
WFLY-2777 changed CCL for context creation(if module is set in external context factory). This essentially cuts context from deployment classes during creation time. This can cause problems when external-context-factory.module classes (ObjectFactories, etc) require deployment classes to be visible from classloader which created context( external-context.module ) and are not found.
Steps to reproduce:
1. define isolated module IM ( with classloader IM_CL )
2. create external-context-factory with module set to IM
3. create some deployment with interface, for which proxies should be looked up via external-context ( with classloader D_CL ) - deployment has no dependency on IM, since it may contain legacy classes or unwanted dependencies
4. lookup and invoke proxy
Now what will happen is during deployment external-context will be spawned just fine. However, the runtime outcome wont be pleasing.
Case 1: application and custom context dont do CCL magic
- invocation happen in deployment CCL, hence IM_CL classes are not visible and no classes required for deserialization can be loaded, this will fail ( return javax.naming.Reference instance, since ObjectFactory from IM_CL cant be found )
Case 2: application or custom context switch CCL to IM_CL for lookup
- CCL is set to IM_CL, ObjectFactory can be found, but D_CL classes cant, hence some naming error probably
Neither of above will work, unless IM_CL and D_CL have some sort of dependency on each other, which just makes module CL configured in external-context-factory irrelevant, since D_CL will require dependency on IM_CL.
Workaround:
yes, store IM_CL in context wrapper and upon first invocation obtain CCL( hopefuly D_CL), create agregating CL and set it as CCL for each context invocation.
Possible fix:
1. pass D_CL and IM_CL as part of env to factory, to allow context/context-wrapper to do some magic
2. alter ExternalContextFactory and create agregating/delegating CL, which will just iterate over IM_CL and D_CL if present to load proper classes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (DROOLS-459) 5.6.x: update version to 5.6.1-SNAPSHOT as 5.6.0.Final is already out
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-459?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer edited comment on DROOLS-459 at 4/1/14 5:17 AM:
-----------------------------------------------------------------------
done!
drools, guvnor 5.6.x branches have now 5.6.1-SNAPSHOT and jbpm branches 5.5.x have now 5.5.1-SNAPSHOT
was (Author: mbiarnes):
done!
drools, guvnor 5.6.x branches have now 5.6.1-SNASPHOT and jbpm branches 5.5.x have now 5.5.1-SNAPSHOT
> 5.6.x: update version to 5.6.1-SNAPSHOT as 5.6.0.Final is already out
> ---------------------------------------------------------------------
>
> Key: DROOLS-459
> URL: https://issues.jboss.org/browse/DROOLS-459
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Petr Široký
> Assignee: Michael Biarnes Kiefer
>
> The version in 5.6.x branch is still 5.6.0-SNAPSHOT, even though the 5.6.0.Final has been already released. Please update the version to 5.6.1-SNAPSHOT.
> Similarly with jBPM, the version should be updated to 5.5.1-SNAPSHOT.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months