[JBoss JIRA] (WFCORE-37) Batching logging profile creation CLI commands can cause errors
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-37?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFCORE-37:
-------------------------------------
The easiest workaround for this is to just add the handler in the {{add}} operation. The issue is how the operations are processed. The model is first updated which because the the {{add-handler}} operation adds the handler to the model. Then the runtime is updated and during the add of the logger, the handler is assigned to the logger because it's in the model. This results in the {{add-handler}} failing as the {{add}} operation for the {{root-logger=ROOT}} resource already added the runtime change for the handler.
> Batching logging profile creation CLI commands can cause errors
> ---------------------------------------------------------------
>
> Key: WFCORE-37
> URL: https://issues.jboss.org/browse/WFCORE-37
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: Kyle Lape
> Assignee: James Perkins
>
> Given these set of commands:
> {noformat}
> /subsystem=logging/logging-profile=myLoggingProfile:add
> /subsystem=logging/logging-profile=myLoggingProfile/file-handler=myHandler:add(level=ALL,file={"relative-to" => "jboss.server.log.dir","path" => "myapp.log"})
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:add-handler(name=myHandler)
> /subsystem=logging/logging-profile=myLoggingProfile/root-logger=ROOT:change-root-log-level(level=INFO)
> {noformat}
> If I run those in a batch, I get an error:
> {noformat}13:32:52,478 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("add-handler") failed - address: ([
> ("subsystem" => "logging"),
> ("logging-profile" => "myLoggingProfile"),
> ("root-logger" => "ROOT")
> ]) - failure description: "JBAS011536: Handler myHandler is already assigned."
> {noformat}
> If I run each one individually, I get no error.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3670) Flag modules to be loaded in a distinct classloader context
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3670?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3670:
-----------------------------------
Oh, well in that case, I'd say you're simply doing it wrong: the shared stuff should not be in a module at all, just in a filesystem JAR. Then, you add the filesystem JAR in to each deployment as a resource root.
> Flag modules to be loaded in a distinct classloader context
> -----------------------------------------------------------
>
> Key: WFLY-3670
> URL: https://issues.jboss.org/browse/WFLY-3670
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
>
> For some use-cases it will be helpful to have a module in a separate classloader (as copy) if it is used from different applications.
> An example is if the module includes classes which follow the singleton pattern but the singleton should be per application instead of instance wide.
> There are two possiblities to flag that
> - within the module.xml
> - within the module reference MAIFEST or jboss-deployment-structure.xml
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (ELY-38) Add additional password algorithms to WildFlyElytronPasswordProvider
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-38:
-----------------------------------
Summary: Add additional password algorithms to WildFlyElytronPasswordProvider
Key: ELY-38
URL: https://issues.jboss.org/browse/ELY-38
Project: WildFly Elytron
Issue Type: Task
Security Level: Public (Everyone can see)
Components: API / SPI, Password Types
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Beta1
A number of algorithms are now supported, update 'WildFlyElytronPasswordProvider' so that these are also registered.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3670) Flag modules to be loaded in a distinct classloader context
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-3670?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink commented on WFLY-3670:
----------------------------------------
I did not meant to have absolute path for resources here.
The issue is that if a module is referenced from different applications the module itself is loaded with a unique classloader.
So all applications which depends on this module are using the same instance of static members.
In case of having a module implementation with such static objects and the application need to have these objects unique for each application the only approach at the moment is to copy the module.
The request is to have a flag like "separateClassLoaderPerDependency"
- at module.xml level to have a copy for all dependency references
- in the application (jboss-deployment-structure or MANIFEST) to have a separate in-memory copy for this application
> Flag modules to be loaded in a distinct classloader context
> -----------------------------------------------------------
>
> Key: WFLY-3670
> URL: https://issues.jboss.org/browse/WFLY-3670
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
>
> For some use-cases it will be helpful to have a module in a separate classloader (as copy) if it is used from different applications.
> An example is if the module includes classes which follow the singleton pattern but the singleton should be per application instead of instance wide.
> There are two possiblities to flag that
> - within the module.xml
> - within the module reference MAIFEST or jboss-deployment-structure.xml
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (WFLY-3700) Optional Module for Camel
by Jeremy Davis (JIRA)
Jeremy Davis created WFLY-3700:
----------------------------------
Summary: Optional Module for Camel
Key: WFLY-3700
URL: https://issues.jboss.org/browse/WFLY-3700
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Class Loading
Environment: Any
Reporter: Jeremy Davis
Assignee: David Lloyd
It would be nice to have an optional module with the necessary jars to run Camel
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months