[JBoss JIRA] (ELY-1350) Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1350?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1350:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1350
> URL: https://issues.jboss.org/browse/ELY-1350
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS.
> *How to reproduce:*
> * run powershell and set work directory JBOSS_HOME/bin
> * set env variable for custom credential store implementation jar like this:
> {code}
> $env:ELYTRON_TOOL_ADDONS="C:\custom.jar"
> {code}
> * run this command
> {code}
> PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug
> Exception encountered executing the command:
> java.security.NoSuchAlgorithmException
> at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80)
> at
> org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
> {code}
> *Suggestion to improve:*
> For me works one of these changes in elytron-tool.ps1 script
> # if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value }
> # $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9278) EJB Acces Timeout is ignored on SFSBs when using distributed caches
by Bernhard Hablesreiter (JIRA)
[ https://issues.jboss.org/browse/WFLY-9278?page=com.atlassian.jira.plugin.... ]
Bernhard Hablesreiter commented on WFLY-9278:
---------------------------------------------
Just an update, not directly linked to this issue, but we found out that a change in "org.jboss.as.ejb3.tx.OwnableReentrantLock" caused the different behaviour in accessing SFSBs (see https://github.com/wildfly/wildfly/commit/8403b6b7afbb1d38c6410bde81ece0d...). Maybe this is also related.
> EJB Acces Timeout is ignored on SFSBs when using distributed caches
> -------------------------------------------------------------------
>
> Key: WFLY-9278
> URL: https://issues.jboss.org/browse/WFLY-9278
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Bernhard Hablesreiter
> Attachments: wildfly-request-test.zip
>
>
> When using distributed caches on Stateful Session Beans, the configured access timeout is ignored. However, the caches acquire-timeout is used instead, leading to a "org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after x seconds".
> The configuration:
> {code:xml}
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="2000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> <singleton default-access-timeout="2000"/>
> </session-bean>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple"/>
> <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> </caches>
> ...
> <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
> ...
> <cache-container name="ejb" aliases="sfsb" default-cache="passivation" module="org.wildfly.clustering.ejb.infinispan">
> <local-cache name="passivation">
> <locking isolation="REPEATABLE_READ" acquire-timeout="10000"/>
> <transaction mode="BATCH" />
> <file-store passivation="true" purge="true"/>
> </local-cache>
> </cache-container>
> ...
> </subsystem>
> {code}
> With the above configuration, any access to a @Stateful-component does not timeout after 2 seconds, but the 10 seconds configured on the infinispan-cache.
> I have attached a simple JSF web application as an eclipse project to reproduce the problem. The application calls a method on a sfsb, increments a counter and waits for 300ms. If one sends multiple request at the same time (e.g. by pressing F5 repeatedly), the problem can easily be reproduced after a few seconds.
> If the cache-ref is set to "simple" the configured access timeout works as exptected, however the access to the stateful bean does not appear to be in sync with the requests the client sent. We came around this issue when trying to migrate vom WF9 to WF10 (see also this forum post: https://developer.jboss.org/thread/266303). When the cache-ref is set to "distrubted", the requests are handled correctly/in correct order (in WF9 this was also the case with cache-ref "simple"), but the access timeout is ignored.
--
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 Andrei Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-9053?page=com.atlassian.jira.plugin.... ]
Andrei Ivanov commented on WFLY-9053:
-------------------------------------
But why not have Hibernate 5.2 directly in WildFly 11?
I understood that for 10, but not for 11, especially since HB 5.2 is out for quite a long time now.
> AbstractMethodError with Hibernate 5.2
> --------------------------------------
>
> Key: WFLY-9053
> URL: https://issues.jboss.org/browse/WFLY-9053
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> 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] (ELY-1350) Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1350?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek commented on ELY-1350:
-----------------------------------
Updated in description.
Thanks [~ctomc]
> Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1350
> URL: https://issues.jboss.org/browse/ELY-1350
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
>
> Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS.
> *How to reproduce:*
> * run powershell and set work directory JBOSS_HOME/bin
> * set env variable for custom credential store implementation jar like this:
> {code}
> $env:ELYTRON_TOOL_ADDONS="C:\custom.jar"
> {code}
> * run this command
> {code}
> PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug
> Exception encountered executing the command:
> java.security.NoSuchAlgorithmException
> at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80)
> at
> org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
> {code}
> *Suggestion to improve:*
> For me works one of these changes in elytron-tool.ps1 script
> # if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value }
> # $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-1350) Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1350?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1350:
------------------------------
Description:
Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS.
*How to reproduce:*
* run powershell and set work directory JBOSS_HOME/bin
* set env variable for custom credential store implementation jar like this:
{code}
$env:ELYTRON_TOOL_ADDONS="C:\custom.jar"
{code}
* run this command
{code}
PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug
Exception encountered executing the command:
java.security.NoSuchAlgorithmException
at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80)
at
org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188
at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
{code}
*Suggestion to improve:*
For me works one of these changes in elytron-tool.ps1 script
# if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value }
# $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS
was:
Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS.
*How to reproduce:*
* run powershell and set work directory JBOSS_HOME/bin
* set env variable for custom credential store implementation jar like this:
{code}
$env:ELYTRON_TOOL_ADDONS="C:\custom.jar"
Process")
{code}
* run this command
{code}
PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug
Exception encountered executing the command:
java.security.NoSuchAlgorithmException
at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80)
at
org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188
at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
{code}
*Suggestion to improve:*
For me works one of these changes in elytron-tool.ps1 script
# if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value }
# $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS
> Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1350
> URL: https://issues.jboss.org/browse/ELY-1350
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
>
> Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS.
> *How to reproduce:*
> * run powershell and set work directory JBOSS_HOME/bin
> * set env variable for custom credential store implementation jar like this:
> {code}
> $env:ELYTRON_TOOL_ADDONS="C:\custom.jar"
> {code}
> * run this command
> {code}
> PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug
> Exception encountered executing the command:
> java.security.NoSuchAlgorithmException
> at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80)
> at
> org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
> {code}
> *Suggestion to improve:*
> For me works one of these changes in elytron-tool.ps1 script
> # if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value }
> # $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-1350) Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1350?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1350:
------------------------------
Description:
Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS.
*How to reproduce:*
* run powershell and set work directory JBOSS_HOME/bin
* set env variable for custom credential store implementation jar like this:
{code}
$env:ELYTRON_TOOL_ADDONS="C:\custom.jar"
Process")
{code}
* run this command
{code}
PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug
Exception encountered executing the command:
java.security.NoSuchAlgorithmException
at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80)
at
org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188
at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
{code}
*Suggestion to improve:*
For me works one of these changes in elytron-tool.ps1 script
# if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value }
# $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS
was:
Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS.
*How to reproduce:*
* run powershell and set work directory JBOSS_HOME/bin
* set env variable for custom credential store implementation jar like this:
{code}
[Environment]::SetEnvironmentVariable("ELYTRON_TOOL_ADDONS", "C:\custom.jar", "
Process")
{code}
* run this command
{code}
PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug
Exception encountered executing the command:
java.security.NoSuchAlgorithmException
at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80)
at
org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188
at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
{code}
*Suggestion to improve:*
For me works one of these changes in elytron-tool.ps1 script
# if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value }
# $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS
> Wildfly Elytron Tool, Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1350
> URL: https://issues.jboss.org/browse/ELY-1350
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
>
> Powershell script elytron-tool.ps1 doesn't work with custom credential store implementation.
> There is problem with getting value of environment variable ELYTRON_TOOL_ADDONS.
> *How to reproduce:*
> * run powershell and set work directory JBOSS_HOME/bin
> * set env variable for custom credential store implementation jar like this:
> {code}
> $env:ELYTRON_TOOL_ADDONS="C:\custom.jar"
> Process")
> {code}
> * run this command
> {code}
> PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l 001.jceks --type CustomTestCredentialStore --debug
> Exception encountered executing the command:
> java.security.NoSuchAlgorithmException
> at org.wildfly.security.credential.store.CredentialStore.getInstance(CredentialStore.java:80)
> at
> org.wildfly.security.tool.CredentialStoreCommand.execute(CredentialStoreCommand.java:188
> at org.wildfly.security.tool.ElytronTool.main(ElytronTool.java:81)
> {code}
> *Suggestion to improve:*
> For me works one of these changes in elytron-tool.ps1 script
> # if (Test-Path env:ELYTRON_TOOL_ADDONS) { $ELYTRON_TOOL_ADDONS=(Get-ChildItem Env:ELYTRON_TOOL_ADDONS).value }
> # $ELYTRON_TOOL_ADDONS=$env:ELYTRON_TOOL_ADDONS
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on WFCORE-3210 at 8/31/17 5:14 AM:
------------------------------------------------------------------------
Hi James,
I would like to share with you the following google drive reference:
[#https://drive.google.com/drive/folders/0B_dEiNBGUsxqRW1oQkg2LXUyZms?usp=sharing]
In this driver folder you will have two artifacts.
01_wildfly_module_company.zip
02_standalone-WFCORE3210.zip
The first zip file contains a wildfly module, text logs from me switching around starting a wildfly domain via script and via eclipse. And illustrating that when i do the switch between how I startup wildfly the issue with class loading sneaks in. then when I keep starting wildfly with the same apporach either batch file or eclipse the issue stops manifesting.
This module is identical to what you have on a previous entry on this jira.
The difference is that the module stops referring to the Appenders jar file and just holds the pure log4j implementation and the JulToLog4j1 router jar code.
You also have the source code for the router jar in there, in case it may help you.
To install this module, go to you WILDFLY_HOME/modules/ and simply dump the module in there.
You should have in your file system a path of the form:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\modules\company\logginglog4j1\main
The second artifact is a domain.
On this domain you have an additional bin/ folder with scripts that you can use to start the wildfly domain.
Just make sure that when you copy the domain, you do not put it in WILDFLY_HOME.
Instead you need to make a deeper folder hierarchy as illustrated by this path:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210
In the link above, the path part:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final would be a match to your WILDFLY_HOME env var.
That is it!
On my environment:
- Windows 7.
- jdk 8 update144
The phenomena I experience is that normally, when I start the domain for a first time with an approach A.
The starting up has problems with the logging classes.
When I stop the domain and keep using the approach A to start the domain I am fine and the:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210\log
WFCORE3210_rollingFileAppender.log
Is getting pumped up with all the application server events.
Which is the ideal thing.
Then, If I swtich my startup approach form A to B, e.g. from bat to eclpse.
The issue manifests once, and then I am fine again.
Last note.
You will want to fix the file:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210\configuration\log4jwildfly.properties
The rolling file appender configured in there has a destination directory that is ok for my folder structure, but which will not be ok for your folder structure, since I doubt you are either using widows or putting your wildfly home where I put mine.
Many thanks for your help,
I hope this package allows you to reproduce the issue,
Kindest regards.
was (Author: nuno.godinhomatos):
Hi James,
I would like to share with you the following google drive reference:
[#https://drive.google.com/drive/folders/0B_dEiNBGUsxqRW1oQkg2LXUyZms?usp=sharing]
In this driver folder you will have two artifacts.
01_wildfly_module_company.zip
02_standalone-WFCORE3210.zip
The first zip file contains a wildfly module, text logs from me switching around starting a wildfly domain via script and via eclipse. And illustrating that when i do the switch between how I startup wildfly the issue with class loading sneaks in. then when I keep starting wildfly with the same apporach either batch file or eclipse the issue stops manifesting.
This module is identical to what you have on a previous entry on this jira.
The difference is that the module stops referring to the Appenders jar file and just holds the pure log4j implementation and the router module.
You also have the source code for the router module in there.
To install this module, go to you WILDFLY_HOME/modules/ and simply dump the module in there.
You should have in your file system a path of the form:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\modules\company\logginglog4j1\main
The second artifact is a domain.
On this domain you have an additional bin/ folder with scripts that you can use to start the wildfly domain.
Just make sure that when you copy the doman, you do not put it in WILDFLY_HOME.
Instead you need to make a deeper folder hiearchy as illustrated by this path:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210
That is it.
On my environment: Windows 7.
The phenomena I experience is that normally, when I start the domain for a first time with an approach A.
The starting up has problems with the logging classes.
When I stop the domain and keep using the approach A to start the domain I am fine and the:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210\log
WFCORE3210_rollingFileAppender.log
Is getting pumped up with all the application server events.
Which is the ideal thing.
Then, If I swtich my startup approach form A to B, e.g. from bat to eclpse.
The issue manifests once, and then I am fine again.
Last note.
You will want to fix the file:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210\configuration\log4jwildfly.properties
The rolling file appender configured in there has a destination directory that is ok for my folder structure, but which will not be ok for your folder structure, since I doubt you are either using widows or putting your wildfly home where I put mine.
Many thanks for your help,
I hope this package allows you to reproduce the issue,
Kindest regards.
> 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-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
Hi James,
I would like to share with you the following google drive reference:
[#https://drive.google.com/drive/folders/0B_dEiNBGUsxqRW1oQkg2LXUyZms?usp=sharing]
In this driver folder you will have two artifacts.
01_wildfly_module_company.zip
02_standalone-WFCORE3210.zip
The first zip file contains a wildfly module, text logs from me switching around starting a wildfly domain via script and via eclipse. And illustrating that when i do the switch between how I startup wildfly the issue with class loading sneaks in. then when I keep starting wildfly with the same apporach either batch file or eclipse the issue stops manifesting.
This module is identical to what you have on a previous entry on this jira.
The difference is that the module stops referring to the Appenders jar file and just holds the pure log4j implementation and the router module.
You also have the source code for the router module in there.
To install this module, go to you WILDFLY_HOME/modules/ and simply dump the module in there.
You should have in your file system a path of the form:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\modules\company\logginglog4j1\main
The second artifact is a domain.
On this domain you have an additional bin/ folder with scripts that you can use to start the wildfly domain.
Just make sure that when you copy the doman, you do not put it in WILDFLY_HOME.
Instead you need to make a deeper folder hiearchy as illustrated by this path:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210
That is it.
On my environment: Windows 7.
The phenomena I experience is that normally, when I start the domain for a first time with an approach A.
The starting up has problems with the logging classes.
When I stop the domain and keep using the approach A to start the domain I am fine and the:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210\log
WFCORE3210_rollingFileAppender.log
Is getting pumped up with all the application server events.
Which is the ideal thing.
Then, If I swtich my startup approach form A to B, e.g. from bat to eclpse.
The issue manifests once, and then I am fine again.
Last note.
You will want to fix the file:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210\configuration\log4jwildfly.properties
The rolling file appender configured in there has a destination directory that is ok for my folder structure, but which will not be ok for your folder structure, since I doubt you are either using widows or putting your wildfly home where I put mine.
Many thanks for your help,
I hope this package allows you to reproduce the issue,
Kindest regards.
> 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