[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-3210:
-------------------------------------
I think that this issue has become massively confused.
I will explain a couple things about class loading here. First, non-determinism is not synonymous with "bug"; if you do something that is not supported or defined, like introduce a race into server initialization by way of two competing versions of the same classes, you get precisely what you pay for, whether or not you understand it. Class isolation is working 100% of the time; no class loader is "soiled" in this process. Rather you are misunderstanding the consequences of a race condition that is introduced by an erroneous module graph.
This entire thing has been described as an "XY problem", where you have a solution in mind but it does not and can not work, whereas the actual problem is still not clear. Are you simply trying to configure log4j-compatible appenders? Are you trying to configure logging on a per-application basis? Start from the beginning.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet edited comment on WFCORE-3205 at 8/29/17 7:44 AM:
-------------------------------------------------------------------
We're using the same war file for the normal and the embedded setup (in GWT Super Dev Mode to allow GWT debugging), so the workaround of excluding the jboss-logmanager is convoluted. Is there any other workaround?
was (Author: ge0ffrey):
We're using the same war file for the normal and the embedded setup (which in GWT Super Dev Mode), so the workaround of excluding the jboss-logmanager is convoluted. Is there any other workaround?
> Logging does not work in the embedded server
> --------------------------------------------
>
> Key: WFCORE-3205
> URL: https://issues.jboss.org/browse/WFCORE-3205
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on WFCORE-3205:
------------------------------------------
We're using the same war file for the normal and the embedded setup (which in GWT Super Dev Mode), so the workaround of excluding the jboss-logmanager is convoluted. Is there any other workaround?
> Logging does not work in the embedded server
> --------------------------------------------
>
> Key: WFCORE-3205
> URL: https://issues.jboss.org/browse/WFCORE-3205
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2468) Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2468?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski resolved WFCORE-2468.
----------------------------------------
Fix Version/s: 3.0.1.Final
Resolution: Out of Date
> Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2468
> URL: https://issues.jboss.org/browse/WFCORE-2468
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Bartosz Baranowski
> Fix For: 3.0.1.Final
>
>
> Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
> *Steps to reproduce*
> * firefly.keystore which is attached copy to eap_home/standalone/data/cs.
> * /subsystem=elytron/key-store=ff001:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {clear-text=Elytron})
> */subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001)
> And you get this output:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-managers.km002" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-managers.km002: Failed to start service
> Caused by: java.lang.NullPointerException"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-managers.km002"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> There must be some kind of information about missing credential-reference or at least missing (wrong) password to key-store.
> When I add there credential-reference with pass to Key-store then operation passes
> /subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001, credential-reference={clear-text=Elytron})
> *Suggestions to improvement*
> failure-description must not contain Exception or snippet stacktrace.
> Please replace WFLYCTL0080 part to better message.
> e.g. "credential-reference is required", "Missing password to key-store access"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2468) Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2468?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski reassigned WFCORE-2468:
------------------------------------------
Assignee: Bartosz Baranowski
> Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2468
> URL: https://issues.jboss.org/browse/WFCORE-2468
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Bartosz Baranowski
>
> Definition Elytron key-manager with key-store (which needs password) without filled credential-reference causes ugly failure-description with senseless Exception.
> *Steps to reproduce*
> * firefly.keystore which is attached copy to eap_home/standalone/data/cs.
> * /subsystem=elytron/key-store=ff001:add(path=cs/firefly.keystore,relative-to=jboss.server.data.dir,type=JKS,credential-reference= {clear-text=Elytron})
> */subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001)
> And you get this output:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-managers.km002" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-managers.km002: Failed to start service
> Caused by: java.lang.NullPointerException"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-managers.km002"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> There must be some kind of information about missing credential-reference or at least missing (wrong) password to key-store.
> When I add there credential-reference with pass to Key-store then operation passes
> /subsystem=elytron/key-managers=keymanager001:add(algorithm=SunX509, key-store=ff001, credential-reference={clear-text=Elytron})
> *Suggestions to improvement*
> failure-description must not contain Exception or snippet stacktrace.
> Please replace WFLYCTL0080 part to better message.
> e.g. "credential-reference is required", "Missing password to key-store access"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9053) AbstractMethodError with Hibernate 5.2
by Giovanni Lovato (JIRA)
[ https://issues.jboss.org/browse/WFLY-9053?page=com.atlassian.jira.plugin.... ]
Giovanni Lovato commented on WFLY-9053:
---------------------------------------
[~smarlow] So any chance to use ORM 5.2 in WildFly 11? Is this a Hibernate issue?
> AbstractMethodError with Hibernate 5.2
> --------------------------------------
>
> Key: WFLY-9053
> URL: https://issues.jboss.org/browse/WFLY-9053
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Alpha1
> Reporter: Giovanni Lovato
> Assignee: Scott Marlow
>
> I'm deploying an EAR specifying in its {{persistence.xml}} to use Hibernate 5.2 as JPA provider:
> {code:xml}
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2" />
> {code}
> Hibernate 5.2 modules are placed in the {{modules}} directory.
> This configuration works in 10.1.0.Final but in 11.0.0.Alpha1 I get this error at deployment:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "oss-application-ear-1.0.0.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.AbstractMethodError: org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.beanManagerLifeCycle(Ljavax/enterprise/inject/spi/BeanManager;)Ljava/lang/Object;
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.<init>(PhaseOnePersistenceUnitServiceImpl.java:89)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:485)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:279)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-2214) SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2214?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2214:
--------------------------------
Attached {{CertificateCNMatcher}}. This matches the peer certificate's name against a pattern which is defined via {{session_verifier_arg}} in {{SSL_KEY_EXCHANGE}}. The following 2 attributes are added to the config:
{code:xml}
session_verifier_class="org.jgroups.protocols.CertficateCNMatcher"
session_verifier_arg="CN=FR59235"
{code}
> SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
> ------------------------------------------------------------
>
> Key: JGRP-2214
> URL: https://issues.jboss.org/browse/JGRP-2214
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.6
>
> Attachments: CertficateCNMatcher.java
>
>
> In {{SSL_KEY_EXCHANGE}}, when an SSL session has been established, we're sure that the credentials of the server and client are OK.
> However, an additional check might be required, e.g. that the CN in the peer's certificate always matches a given pattern, or that the org always is "IBM" (for example).
> If this is not the case, terminate the SSL connection.
> Todo: add the fully qualified name of a class and an argument (e.g. the pattern). An instance of the class will be created and initialized with the pattern. When an SSL session has been created ({{connect()}} on the client, {{accept()}} on the server), the {{verify()}} method in the instance is called and it needs to throw a {{SecurityException}} if the session cannot be accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-2214) SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2214?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2214 at 8/29/17 3:23 AM:
---------------------------------------------------------
Attached {{CertificateCNMatcher}}. This matches the peer certificate's name against a pattern which is defined via {{session_verifier_arg}} in {{SSL_KEY_EXCHANGE}}. The following 2 attributes are added to the config:
{code:xml}
session_verifier_class="org.jgroups.protocols.CertficateCNMatcher"
session_verifier_arg="CN=FR59235"
{code}
was (Author: belaban):
Attached {{CertificateCNMatcher}}. This matches the peer certificate's name against a pattern which is defined via {{session_verifier_arg}} in {{SSL_KEY_EXCHANGE}}. The following 2 attributes are added to the config:
{code:xml}
session_verifier_class="org.jgroups.protocols.CertficateCNMatcher"
session_verifier_arg="CN=FR59235"
{code}
> SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
> ------------------------------------------------------------
>
> Key: JGRP-2214
> URL: https://issues.jboss.org/browse/JGRP-2214
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.6
>
> Attachments: CertficateCNMatcher.java
>
>
> In {{SSL_KEY_EXCHANGE}}, when an SSL session has been established, we're sure that the credentials of the server and client are OK.
> However, an additional check might be required, e.g. that the CN in the peer's certificate always matches a given pattern, or that the org always is "IBM" (for example).
> If this is not the case, terminate the SSL connection.
> Todo: add the fully qualified name of a class and an argument (e.g. the pattern). An instance of the class will be created and initialized with the pattern. When an SSL session has been created ({{connect()}} on the client, {{accept()}} on the server), the {{verify()}} method in the instance is called and it needs to throw a {{SecurityException}} if the session cannot be accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months