[JBoss JIRA] (WFLY-13598) Hard coded dependencies from resource adapters to legacy security sercvies.
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13598?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13598:
-----------------------------------------
I have been able to eliminate the error by converting the last CLI operation to:
/subsystem=resource-adapters/resource-adapter=myrar.rar/connection-definitions=connection-definition:add(class-name=org.wildfly.test.MyRar, *elytron-enabled=true, recovery-elytron-enabled=true*)
I am converting to an enhancement for now but maybe this is still borderline bug, I think for a couple of reasons:
# Removal of the legacy security subsystem shouldn't break a resource adapter which has no security configuration of it's own.
# A resource adapter with no security configuration should not require security attributes just to get it to install.
Ideally we would have something that detects if legacy security is installed or not.
The specific dependencies are added at this point:
https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or...
> Hard coded dependencies from resource adapters to legacy security sercvies.
> ---------------------------------------------------------------------------
>
> Key: WFLY-13598
> URL: https://issues.redhat.com/browse/WFLY-13598
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA, Security
> Affects Versions: 20.0.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Labels: legacy_security_removal
> Fix For: 21.0.0.Beta1
>
>
> A resource adapter defined similar to:
>
> {code:xml}
> <resource-adapters>
> <resource-adapter id="myrar.rar">
> <archive>
> myrar.rar
> </archive>
> <connection-definitions>
> <connection-definition class-name="org.wildfly.test.MyRar" pool-name="connection-definition"/>
> </connection-definitions>
> </resource-adapter>
> </resource-adapters>
> {code}
> Leads to an error:
> {code}
> 13:48:11,932 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "resource-adapters"),
> ("resource-adapter" => "myrar.rar"),
> ("connection-definitions" => "connection-definition")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => [
> "jboss.security.subject-factory",
> "jboss.security.simple-security-manager"
> ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.resourceadapters.ra.\"myrar.rar\".connection-definition is missing [jboss.security.simple-security-manager, jboss.security.subject-factory]"]
> }
> {code}
> Resources should not depend on legacy security by default as it may not be there.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13598) Hard coded dependencies from resource adapters to legacy security sercvies.
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13598?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13598:
------------------------------------
Fix Version/s: (was: 21.0.0.Beta1)
> Hard coded dependencies from resource adapters to legacy security sercvies.
> ---------------------------------------------------------------------------
>
> Key: WFLY-13598
> URL: https://issues.redhat.com/browse/WFLY-13598
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA, Security
> Affects Versions: 20.0.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Labels: legacy_security_removal
>
> A resource adapter defined similar to:
>
> {code:xml}
> <resource-adapters>
> <resource-adapter id="myrar.rar">
> <archive>
> myrar.rar
> </archive>
> <connection-definitions>
> <connection-definition class-name="org.wildfly.test.MyRar" pool-name="connection-definition"/>
> </connection-definitions>
> </resource-adapter>
> </resource-adapters>
> {code}
> Leads to an error:
> {code}
> 13:48:11,932 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "resource-adapters"),
> ("resource-adapter" => "myrar.rar"),
> ("connection-definitions" => "connection-definition")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => [
> "jboss.security.subject-factory",
> "jboss.security.simple-security-manager"
> ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.resourceadapters.ra.\"myrar.rar\".connection-definition is missing [jboss.security.simple-security-manager, jboss.security.subject-factory]"]
> }
> {code}
> Resources should not depend on legacy security by default as it may not be there.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13598) Hard coded dependencies from resource adapters to legacy security sercvies.
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13598?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13598:
------------------------------------
Issue Type: Enhancement (was: Bug)
> Hard coded dependencies from resource adapters to legacy security sercvies.
> ---------------------------------------------------------------------------
>
> Key: WFLY-13598
> URL: https://issues.redhat.com/browse/WFLY-13598
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA, Security
> Affects Versions: 20.0.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Labels: legacy_security_removal
> Fix For: 21.0.0.Beta1
>
>
> A resource adapter defined similar to:
>
> {code:xml}
> <resource-adapters>
> <resource-adapter id="myrar.rar">
> <archive>
> myrar.rar
> </archive>
> <connection-definitions>
> <connection-definition class-name="org.wildfly.test.MyRar" pool-name="connection-definition"/>
> </connection-definitions>
> </resource-adapter>
> </resource-adapters>
> {code}
> Leads to an error:
> {code}
> 13:48:11,932 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "resource-adapters"),
> ("resource-adapter" => "myrar.rar"),
> ("connection-definitions" => "connection-definition")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => [
> "jboss.security.subject-factory",
> "jboss.security.simple-security-manager"
> ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.resourceadapters.ra.\"myrar.rar\".connection-definition is missing [jboss.security.simple-security-manager, jboss.security.subject-factory]"]
> }
> {code}
> Resources should not depend on legacy security by default as it may not be there.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13598) Hard coded dependencies from resource adapters to legacy security sercvies.
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13598?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13598:
------------------------------------
Labels: legacy_security_removal (was: )
> Hard coded dependencies from resource adapters to legacy security sercvies.
> ---------------------------------------------------------------------------
>
> Key: WFLY-13598
> URL: https://issues.redhat.com/browse/WFLY-13598
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Security
> Affects Versions: 20.0.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Labels: legacy_security_removal
> Fix For: 21.0.0.Beta1
>
>
> A resource adapter defined similar to:
>
> {code:xml}
> <resource-adapters>
> <resource-adapter id="myrar.rar">
> <archive>
> myrar.rar
> </archive>
> <connection-definitions>
> <connection-definition class-name="org.wildfly.test.MyRar" pool-name="connection-definition"/>
> </connection-definitions>
> </resource-adapter>
> </resource-adapters>
> {code}
> Leads to an error:
> {code}
> 13:48:11,932 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "resource-adapters"),
> ("resource-adapter" => "myrar.rar"),
> ("connection-definitions" => "connection-definition")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => [
> "jboss.security.subject-factory",
> "jboss.security.simple-security-manager"
> ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.resourceadapters.ra.\"myrar.rar\".connection-definition is missing [jboss.security.simple-security-manager, jboss.security.subject-factory]"]
> }
> {code}
> Resources should not depend on legacy security by default as it may not be there.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13600) EJB client over HTTP Fail on Java SE
by Gergely Molnár (Jira)
[ https://issues.redhat.com/browse/WFLY-13600?page=com.atlassian.jira.plugi... ]
Gergely Molnár updated WFLY-13600:
----------------------------------
Description:
Java SE code:
{code:java}
public class Application {
private static final String REMOTE_CALC = "ejb:/remote-ejb/RemoteCalc!" + RemoteCalc.class.getName();
/**
* Lookup remote \{@link RemoteCalc}.
*
* @return a \{@link RemoteCalc} object
* @throws NamingException Something is wrong
*/
public static RemoteCalc getRemoteCalc() throws NamingException {
Hashtable<String, Object> jndiProps = new Hashtable<>();
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
// remote+http connection (work fine)
//jndiProps.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080/remote-ejb");
// http connection (fail)
jndiProps.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/wildfly-services");
Context context = new InitialContext(jndiProps);
return (RemoteCalc) context.lookup(REMOTE_CALC);
}
/**
* Call to run (main).
*
* @param args parameters (not used)
* @throws NamingException Something is wrong
*/
public static void main(String[] args) throws NamingException {
RemoteCalc remoteCalc = getRemoteCalc();
System.out.println("Remote calc 95 + 76: " + remoteCalc.add(95, 76));
}
}
{code}
Exception:
Exception in thread "main" javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "http"
at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.bosch.emea.bpart.remoteejbclient.Application.getRemoteCalc(Application.java:34)
at com.bosch.emea.bpart.remoteejbclient.Application.main(Application.java:47)
Lib:
{code:java}
@Remote
public interface RemoteCalc {
/**
* Add two integer.
*
* @param a an integer
* @param b an integer
* @return a + b
*/
public int add(int a, int b);
}
{code}
Config:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<authentication-client xmlns="urn:elytron:1.0">
<authentication-rules>
<rule use-configuration="default" />
</authentication-rules>
<authentication-configurations>
<configuration name="default">
<sasl-mechanism-selector selector="#ALL" />
<set-mechanism-properties>
<property key="wildfly.sasl.local-user.quiet-auth" value="true" />
</set-mechanism-properties>
<providers>
<use-service-loader/>
</providers>
</configuration>
</authentication-configurations>
</authentication-client>
</configuration>
{code}
Maven dependency:
{code:xml}
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<version>20.0.0.Final</version>
<type>pom</type>
</dependency>
{code}
was:
Java SE code:
{code:java}
public class Application {
private static final String REMOTE_CALC = "ejb:/remote-ejb/RemoteCalc!" + RemoteCalc.class.getName();
/**
* Lookup remote \{@link RemoteCalc}.
*
* @return a \{@link RemoteCalc} object
* @throws NamingException Something is wrong
*/
public static RemoteCalc getRemoteCalc() throws NamingException {
Hashtable<String, Object> jndiProps = new Hashtable<>();
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
// remote+http connection (work fine)
//jndiProps.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080/remote-ejb");
// http connection (fail)
jndiProps.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/wildfly-services");
Context context = new InitialContext(jndiProps);
return (RemoteCalc) context.lookup(REMOTE_CALC);
}
/**
* Call to run (main).
*
* @param args parameters (not used)
* @throws NamingException Something is wrong
*/
public static void main(String[] args) throws NamingException {
RemoteCalc remoteCalc = getRemoteCalc();
System.out.println("Remote calc 95 + 76: " + remoteCalc.add(95, 76));
}
}
{code}
Exception:
Exception in thread "main" javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "http"
at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.bosch.emea.bpart.remoteejbclient.Application.getRemoteCalc(Application.java:34)
at com.bosch.emea.bpart.remoteejbclient.Application.main(Application.java:47)
Lib:
{code:java}
@Remote
public interface RemoteCalc {
/**
* Add two integer.
*
* @param a an integer
* @param b an integer
* @return a + b
*/
public int add(int a, int b);
}
{code}
Config:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<authentication-client xmlns="urn:elytron:1.0">
<authentication-rules>
<rule use-configuration="default" />
</authentication-rules>
<authentication-configurations>
<configuration name="default">
<sasl-mechanism-selector selector="#ALL" />
<set-mechanism-properties>
<property key="wildfly.sasl.local-user.quiet-auth" value="true" />
</set-mechanism-properties>
<providers>
<use-service-loader/>
</providers>
</configuration>
</authentication-configurations>
</authentication-client>
</configuration>
{code}
Maven dependency:
{code:xml}
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<version>18.0.1.Final</version>
<type>pom</type>
</dependency>
{code}
> EJB client over HTTP Fail on Java SE
> ------------------------------------
>
> Key: WFLY-13600
> URL: https://issues.redhat.com/browse/WFLY-13600
> Project: WildFly
> Issue Type: Bug
> Components: Application Client
> Affects Versions: 20.0.0.Final
> Reporter: Gergely Molnár
> Assignee: Brian Stansberry
> Priority: Major
>
> Java SE code:
> {code:java}
> public class Application {
> private static final String REMOTE_CALC = "ejb:/remote-ejb/RemoteCalc!" + RemoteCalc.class.getName();
> /**
> * Lookup remote \{@link RemoteCalc}.
> *
> * @return a \{@link RemoteCalc} object
> * @throws NamingException Something is wrong
> */
> public static RemoteCalc getRemoteCalc() throws NamingException {
> Hashtable<String, Object> jndiProps = new Hashtable<>();
> jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> // remote+http connection (work fine)
> //jndiProps.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080/remote-ejb");
> // http connection (fail)
> jndiProps.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/wildfly-services");
> Context context = new InitialContext(jndiProps);
> return (RemoteCalc) context.lookup(REMOTE_CALC);
> }
> /**
> * Call to run (main).
> *
> * @param args parameters (not used)
> * @throws NamingException Something is wrong
> */
> public static void main(String[] args) throws NamingException {
>
> RemoteCalc remoteCalc = getRemoteCalc();
> System.out.println("Remote calc 95 + 76: " + remoteCalc.add(95, 76));
> }
> }
> {code}
> Exception:
> Exception in thread "main" javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "http"
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> at javax.naming.InitialContext.lookup(Unknown Source)
> at com.bosch.emea.bpart.remoteejbclient.Application.getRemoteCalc(Application.java:34)
> at com.bosch.emea.bpart.remoteejbclient.Application.main(Application.java:47)
> Lib:
> {code:java}
> @Remote
> public interface RemoteCalc {
> /**
> * Add two integer.
> *
> * @param a an integer
> * @param b an integer
> * @return a + b
> */
> public int add(int a, int b);
>
> }
> {code}
> Config:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-rules>
> <rule use-configuration="default" />
> </authentication-rules>
> <authentication-configurations>
> <configuration name="default">
> <sasl-mechanism-selector selector="#ALL" />
> <set-mechanism-properties>
> <property key="wildfly.sasl.local-user.quiet-auth" value="true" />
> </set-mechanism-properties>
> <providers>
> <use-service-loader/>
> </providers>
> </configuration>
> </authentication-configurations>
> </authentication-client>
> </configuration>
> {code}
> Maven dependency:
> {code:xml}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-ejb-client-bom</artifactId>
> <version>20.0.0.Final</version>
> <type>pom</type>
> </dependency>
> {code}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13600) EJB client over HTTP Fail on Java SE
by Gergely Molnár (Jira)
Gergely Molnár created WFLY-13600:
-------------------------------------
Summary: EJB client over HTTP Fail on Java SE
Key: WFLY-13600
URL: https://issues.redhat.com/browse/WFLY-13600
Project: WildFly
Issue Type: Bug
Components: Application Client
Affects Versions: 20.0.0.Final
Reporter: Gergely Molnár
Assignee: Brian Stansberry
Java SE code:
{code:java}
public class Application {
private static final String REMOTE_CALC = "ejb:/remote-ejb/RemoteCalc!" + RemoteCalc.class.getName();
/**
* Lookup remote \{@link RemoteCalc}.
*
* @return a \{@link RemoteCalc} object
* @throws NamingException Something is wrong
*/
public static RemoteCalc getRemoteCalc() throws NamingException {
Hashtable<String, Object> jndiProps = new Hashtable<>();
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
// remote+http connection (work fine)
//jndiProps.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080/remote-ejb");
// http connection (fail)
jndiProps.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/wildfly-services");
Context context = new InitialContext(jndiProps);
return (RemoteCalc) context.lookup(REMOTE_CALC);
}
/**
* Call to run (main).
*
* @param args parameters (not used)
* @throws NamingException Something is wrong
*/
public static void main(String[] args) throws NamingException {
RemoteCalc remoteCalc = getRemoteCalc();
System.out.println("Remote calc 95 + 76: " + remoteCalc.add(95, 76));
}
}
{code}
Exception:
Exception in thread "main" javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "http"
at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.bosch.emea.bpart.remoteejbclient.Application.getRemoteCalc(Application.java:34)
at com.bosch.emea.bpart.remoteejbclient.Application.main(Application.java:47)
Lib:
{code:java}
@Remote
public interface RemoteCalc {
/**
* Add two integer.
*
* @param a an integer
* @param b an integer
* @return a + b
*/
public int add(int a, int b);
}
{code}
Config:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<authentication-client xmlns="urn:elytron:1.0">
<authentication-rules>
<rule use-configuration="default" />
</authentication-rules>
<authentication-configurations>
<configuration name="default">
<sasl-mechanism-selector selector="#ALL" />
<set-mechanism-properties>
<property key="wildfly.sasl.local-user.quiet-auth" value="true" />
</set-mechanism-properties>
<providers>
<use-service-loader/>
</providers>
</configuration>
</authentication-configurations>
</authentication-client>
</configuration>
{code}
Maven dependency:
{code:xml}
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<version>18.0.1.Final</version>
<type>pom</type>
</dependency>
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13588) Messaging should not expose its subsystem module to deployments
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13588?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13588:
--------------------------------
Description:
The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection. This is a very bad idea, as the deployment can then access all of the subsystem internals (including its dependents).
The correct way to do this is to create a separate module containing the CDI extension and its dependents and only expose this module to deployments.
was:
The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection. This is a very bad idea, as the deployment can then access all of the subsystem internals.
The correct way to do this is to create a separate module containing the CDI extension and its dependents and only expose this module to deployments.
> Messaging should not expose its subsystem module to deployments
> ---------------------------------------------------------------
>
> Key: WFLY-13588
> URL: https://issues.redhat.com/browse/WFLY-13588
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 20.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection. This is a very bad idea, as the deployment can then access all of the subsystem internals (including its dependents).
> The correct way to do this is to create a separate module containing the CDI extension and its dependents and only expose this module to deployments.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13588) Messaging should not expose its subsystem module to deployments
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13588?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13588:
--------------------------------
Description:
The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection. This is a very bad idea, as the deployment can then access all of the subsystem internals (including its dependents).
The correct way to do this is to create a separate module containing userspace classes, including the CDI extension and its dependents. Only this module should ever be exposed to deployments.
was:
The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection. This is a very bad idea, as the deployment can then access all of the subsystem internals (including its dependents).
The correct way to do this is to create a separate module containing the CDI extension and its dependents and only expose this module to deployments.
> Messaging should not expose its subsystem module to deployments
> ---------------------------------------------------------------
>
> Key: WFLY-13588
> URL: https://issues.redhat.com/browse/WFLY-13588
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 20.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection. This is a very bad idea, as the deployment can then access all of the subsystem internals (including its dependents).
> The correct way to do this is to create a separate module containing userspace classes, including the CDI extension and its dependents. Only this module should ever be exposed to deployments.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13588) Messaging should not expose its subsystem module to deployments
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13588?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13588:
--------------------------------
Description:
The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection. This is a very bad idea, as the deployment can then access all of the subsystem internals.
The correct way to do this is to create a separate module containing the CDI extension and its dependents and only expose this module to deployments.
was:
The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection.
The correct way to do this is to create a separate module containing the CDI extension and its dependents and only expose this module to deployments.
> Messaging should not expose its subsystem module to deployments
> ---------------------------------------------------------------
>
> Key: WFLY-13588
> URL: https://issues.redhat.com/browse/WFLY-13588
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 20.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection. This is a very bad idea, as the deployment can then access all of the subsystem internals.
> The correct way to do this is to create a separate module containing the CDI extension and its dependents and only expose this module to deployments.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (WFLY-13588) Messaging should not expose its subsystem module to deployments
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13588?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13588:
--------------------------------
Description:
The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection.
The correct way to do this is to create a separate module containing the CDI extension and its dependents and only expose this module to deployments.
was:The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection. However, this is unnecessary, since the subsystem already has a DUP that registers the portable extension via the WeldCapability.
> Messaging should not expose its subsystem module to deployments
> ---------------------------------------------------------------
>
> Key: WFLY-13588
> URL: https://issues.redhat.com/browse/WFLY-13588
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 20.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> The messaging-activemq subsystem exposes its subsystem module to the deployment classloader. According to comments, this was done to allow CDI to load the requisite portable extension to support JMSContext injection.
> The correct way to do this is to create a separate module containing the CDI extension and its dependents and only expose this module to deployments.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months