[JBoss JIRA] (WFLY-4618) JASPIC authentication processed on unsecured ressources
by Ladislav Petera (JIRA)
[ https://issues.jboss.org/browse/WFLY-4618?page=com.atlassian.jira.plugin.... ]
Ladislav Petera commented on WFLY-4618:
---------------------------------------
Hello guys,
I am implementing a JASPI SAM and having trouble following the proposed solution.
Contrary to the JSR-196 (chapter 3.7.4) my SAM receives a "null" requestPolicy in ServerAuthModule.initialize call.
Checking the isMandatory() property on a null does not work for obvious reasons.
This behavior corresponds to what I see in the Pickebox code which is responsible for SAM initialization:
[http://grepcode.com/file/repo1.maven.org/maven2/org.picketbox/picketbox/4...]
I am Using Wildfly 9.0.2 Final. However decompiling the picketbox lib in 10.0 shows the same behaviour.
This bug and all related bugs are marked as RESOLVED, so I would assume that unsecured resources via web.xml should work now.
But from what I see, this cannot work yet.
Am I missing something?
Thanks a lot to anyone taking time to respond.
> JASPIC authentication processed on unsecured ressources
> -------------------------------------------------------
>
> Key: WFLY-4618
> URL: https://issues.jboss.org/browse/WFLY-4618
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Reporter: Gernot Müller
> Assignee: Stuart Douglas
>
> When using JASPIC authentication in web-projects, then serving unsecured resources (like unsecured pages, css/js-resources) ends in calling configured JASPI auth-modules.
> The problem is located in class JASPIAuthenticationMechanism (Undertow extension) where SecurityContext is never asked if the request has to be authenticated.
> So JASPIC can't be used wor web-applications which consist of secured AND unsecured parts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1137) Better granularity for imported BOMs
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1137?page=com.atlassian.jira.plugi... ]
Petr Široký edited comment on DROOLS-1137 at 4/22/16 9:00 AM:
--------------------------------------------------------------
Yes, ultimately {{kie-parent-with-dependencies}} should go. I will keep it around until all the repos are migrated (I would like to do the migration one repo at a time). About `kie-platform-bom`, I am not sure what the value is. Our projects won't use it, but it might be useful for our users in case they want single POM which will import all the versions they need. This initial proposal does not include it, but we may decide to add it back later on.
was (Author: psiroky):
Yes, ultimately `kie-parent-with-dependencies` should go. I will keep it around until all the repos are migrated (I would like to do the migration one repo at a time). About `kie-platform-bom`, I am not sure what the value is. Our projects won't use it, but it might be useful for our users in case they want single POM which will import all the versions they need. This initial proposal does not include it, but we may decide to add it back later on.
> Better granularity for imported BOMs
> ------------------------------------
>
> Key: DROOLS-1137
> URL: https://issues.jboss.org/browse/DROOLS-1137
> Project: Drools
> Issue Type: Enhancement
> Components: build
> Affects Versions: 6.4.0.Final
> Reporter: Petr Široký
> Assignee: Petr Široký
>
> Projects/modules like Drools or OptaPlanner transitively require BOMs which are not actually needed at all (e.g. uberfire-bom or guvnor-bom). This brings a lot of issues for RPMs and is also weird.
> Proposal to fix this (discussed with [~ge0ffrey] as the best option):
> *kie-parent (created from kie-parent-metadata)*
> * has ip-parent as it’s parent
> * Does not contain dependency versions (empty dependencyManagement)
> *user-boms (kie-bom, drools-bom, optaplanner-bom, etc)*
> * have kie-parent as their parent
> * contain only depMgmt for the specific groupIds (e.g. org.optaplanner for optaplanner-bom)
> * nothing really changes here
> *kie-third-party-bom*
> * imports ip-bom to get the depMgmt
> * contains required overrides
> * does _not_ declare any versions for KIE deps (not even UF or Dashbuilder)
> Specific projects then import only what they need (obviously not 100 % true as the kie-third-party-bom would define many more versions than we need, but that is not easily fixable atm):
> *Drools parent POM (top-level pom in drools repo)*
> * has kie-parent as it’s parent
> * imports kie-third-party-bom + drools-bom
> *jBPM Console NG parent POM*
> * has kie-parent as it’s parent
> * imports kie-third-party-bom + drools-bom? + jbpm-bom + uf-bom + uf-ext-bom + dashuilder-bom + guvnor-bom
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBEE-160) jboss-transaction-api OSGi bundle requiring optional packages
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/JBEE-160?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar commented on JBEE-160:
----------------------------------
{noformat}
Manifest-Version: 1.0
Bundle-License: http://repository.jboss.org/licenses/cddl.txt, http://
repository.jboss.org/licenses/gpl-2.0-ce.txt
Bundle-SymbolicName: org.jboss.spec.javax.transaction.jboss-transactio n-api_1.2_spec
Archiver-Version: Plexus Archiver
Built-By: tomaz
Bnd-LastModified: 1461329347750
Specification-Title: JSR 907: Java Transaction API (JTA)
Implementation-Vendor-Id: org.jboss.spec.javax.transaction
Bundle-DocURL: http://www.jboss.org
Import-Package: javax.enterprise.context;resolution:=optional;version= "[1.1,2)",javax.enterprise.util;version="[1.1,2)",javax.interceptor;version="1.2,2)",javax.transaction.xa;version="[1.2,2)"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
Scm-Url: https://github.com/jboss/jboss-transaction-api_spec
Export-Package: javax.transaction;version="1.2";uses:="javax.enterprise.context,javax.enterprise.util,javax.interceptor,javax.transaction.xa",javax.transaction.xa;version="1.2"
Bundle-Name: Java Transaction API
Implementation-Title: Java Transaction API
Bundle-Description: The Java Transaction 1.2 API classes
Implementation-Version: 1.0.1.Final-SNAPSHOT
Java-Version: 1.8.0_74
Scm-Connection: scm:git:git@github.com:jboss/jboss-transaction-api_spec.git
Specification-Vendor: Oracle, Inc.
Os-Arch: amd64
Bundle-ManifestVersion: 2
Java-Vendor: Oracle Corporation
Bundle-Vendor: JBoss by Red Hat
Os-Name: Windows 10
Tool: Bnd-3.0.0.201509101326
Implementation-Vendor: JBoss by Red Hat
Os-Version: 10.0
Scm-Revision: cb860fe516ea064074140827a02956f12a1f748e
Bundle-Version: 1.0.1.Final-SNAPSHOT
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.8.0_74
Specification-Version: 1.2
Implementation-URL: http://www.jboss.org/jboss-transaction-api_1.2_spe
c
{noformat}
[~brmeyer] does this look ok to you?
> jboss-transaction-api OSGi bundle requiring optional packages
> -------------------------------------------------------------
>
> Key: JBEE-160
> URL: https://issues.jboss.org/browse/JBEE-160
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-transaction-api
> Reporter: Brett Meyer
> Assignee: Tomaz Cerar
>
> The jboss-transaction-api_1.2_spec OSGi bundle requires the 'javax.enterprise.context'. Instead, that should be optional, right? cdi-api shouldn't be required to simply use jta. Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1137) Better granularity for imported BOMs
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1137?page=com.atlassian.jira.plugi... ]
Petr Široký commented on DROOLS-1137:
-------------------------------------
Yes, ultimately `kie-parent-with-dependencies` should go. I will keep it around until all the repos are migrated (I would like to do the migration one repo at a time). About `kie-platform-bom`, I am not sure what the value is. Our projects won't use it, but it might be useful for our users in case they want single POM which will import all the versions they need. This initial proposal does not include it, but we may decide to add it back later on.
> Better granularity for imported BOMs
> ------------------------------------
>
> Key: DROOLS-1137
> URL: https://issues.jboss.org/browse/DROOLS-1137
> Project: Drools
> Issue Type: Enhancement
> Components: build
> Affects Versions: 6.4.0.Final
> Reporter: Petr Široký
> Assignee: Petr Široký
>
> Projects/modules like Drools or OptaPlanner transitively require BOMs which are not actually needed at all (e.g. uberfire-bom or guvnor-bom). This brings a lot of issues for RPMs and is also weird.
> Proposal to fix this (discussed with [~ge0ffrey] as the best option):
> *kie-parent (created from kie-parent-metadata)*
> * has ip-parent as it’s parent
> * Does not contain dependency versions (empty dependencyManagement)
> *user-boms (kie-bom, drools-bom, optaplanner-bom, etc)*
> * have kie-parent as their parent
> * contain only depMgmt for the specific groupIds (e.g. org.optaplanner for optaplanner-bom)
> * nothing really changes here
> *kie-third-party-bom*
> * imports ip-bom to get the depMgmt
> * contains required overrides
> * does _not_ declare any versions for KIE deps (not even UF or Dashbuilder)
> Specific projects then import only what they need (obviously not 100 % true as the kie-third-party-bom would define many more versions than we need, but that is not easily fixable atm):
> *Drools parent POM (top-level pom in drools repo)*
> * has kie-parent as it’s parent
> * imports kie-third-party-bom + drools-bom
> *jBPM Console NG parent POM*
> * has kie-parent as it’s parent
> * imports kie-third-party-bom + drools-bom? + jbpm-bom + uf-bom + uf-ext-bom + dashuilder-bom + guvnor-bom
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-511) Adjust HTTP APIs to return collections from request object
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-511:
------------------------------------
Summary: Adjust HTTP APIs to return collections from request object
Key: ELY-511
URL: https://issues.jboss.org/browse/ELY-511
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI, HTTP
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta6
By using collections we both provide the ability for them to be protected against modifications and also give the implementation of the SPI the ability to lazily initialise them.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1137) Better granularity for imported BOMs
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1137?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1137:
------------------------------------------
Note that the RPM work is working around this, so RPM's shouldn't really impact the decision here. I do think it's an improvement nonetheless.
In this proposal (let's call it proposal A), what are the changes?
- Will it remove 1 POM (because kie-parent-with-dependencies and kie-platform-bom will become kie-third-party-bom)?
- Child poms don't change, only top level multiproject parent poms.
> Better granularity for imported BOMs
> ------------------------------------
>
> Key: DROOLS-1137
> URL: https://issues.jboss.org/browse/DROOLS-1137
> Project: Drools
> Issue Type: Enhancement
> Components: build
> Affects Versions: 6.4.0.Final
> Reporter: Petr Široký
> Assignee: Petr Široký
>
> Projects/modules like Drools or OptaPlanner transitively require BOMs which are not actually needed at all (e.g. uberfire-bom or guvnor-bom). This brings a lot of issues for RPMs and is also weird.
> Proposal to fix this (discussed with [~ge0ffrey] as the best option):
> *kie-parent (created from kie-parent-metadata)*
> * has ip-parent as it’s parent
> * Does not contain dependency versions (empty dependencyManagement)
> *user-boms (kie-bom, drools-bom, optaplanner-bom, etc)*
> * have kie-parent as their parent
> * contain only depMgmt for the specific groupIds (e.g. org.optaplanner for optaplanner-bom)
> * nothing really changes here
> *kie-third-party-bom*
> * imports ip-bom to get the depMgmt
> * contains required overrides
> * does _not_ declare any versions for KIE deps (not even UF or Dashbuilder)
> Specific projects then import only what they need (obviously not 100 % true as the kie-third-party-bom would define many more versions than we need, but that is not easily fixable atm):
> *Drools parent POM (top-level pom in drools repo)*
> * has kie-parent as it’s parent
> * imports kie-third-party-bom + drools-bom
> *jBPM Console NG parent POM*
> * has kie-parent as it’s parent
> * imports kie-third-party-bom + drools-bom? + jbpm-bom + uf-bom + uf-ext-bom + dashuilder-bom + guvnor-bom
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1137) Better granularity for imported BOMs
by Petr Široký (JIRA)
Petr Široký created DROOLS-1137:
-----------------------------------
Summary: Better granularity for imported BOMs
Key: DROOLS-1137
URL: https://issues.jboss.org/browse/DROOLS-1137
Project: Drools
Issue Type: Enhancement
Components: build
Affects Versions: 6.4.0.Final
Reporter: Petr Široký
Assignee: Petr Široký
Projects/modules like Drools or OptaPlanner transitively require BOMs which are not actually needed at all (e.g. uberfire-bom or guvnor-bom). This brings a lot of issues for RPMs and is also weird.
Proposal to fix this (discussed with [~ge0ffrey] as the best option):
*kie-parent (created from kie-parent-metadata)*
* has ip-parent as it’s parent
* Does not contain dependency versions (empty dependencyManagement)
*user-boms (kie-bom, drools-bom, optaplanner-bom, etc)*
* have kie-parent as their parent
* contain only depMgmt for the specific groupIds (e.g. org.optaplanner for optaplanner-bom)
* nothing really changes here
*kie-third-party-bom*
* imports ip-bom to get the depMgmt
* contains required overrides
* does _not_ declare any versions for KIE deps (not even UF or Dashbuilder)
Specific projects then import only what they need (obviously not 100 % true as the kie-third-party-bom would define many more versions than we need, but that is not easily fixable atm):
*Drools parent POM (top-level pom in drools repo)*
* has kie-parent as it’s parent
* imports kie-third-party-bom + drools-bom
*jBPM Console NG parent POM*
* has kie-parent as it’s parent
* imports kie-third-party-bom + drools-bom? + jbpm-bom + uf-bom + uf-ext-bom + dashuilder-bom + guvnor-bom
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6547) logging custom-handler does not load module with slot
by Erwan Lacoste (JIRA)
[ https://issues.jboss.org/browse/WFLY-6547?page=com.atlassian.jira.plugin.... ]
Erwan Lacoste updated WFLY-6547:
--------------------------------
Description:
Tested on EAP 6.4
when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
my/loghandler/main
- module.xml
- my.jar
{code:xml}
<custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
{code}
Nevertheless I want to version the module, therefore package my module with a given slot:
my/loghandler/1.0
- module.xml
- my.jar
{code:xml}
<custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
{code}
But this fails with following stacktrace:
{code}
11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
("subsystem" => "logging"),
("custom-handler" => "4H")
]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
... 13 more
{code}
why is the module not found being *my.loghandler:1.0:main* ?
was:
Tested on EAP 6.4
when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
my/lognahdler/main
module.xml
my.jar
{code:xml}
<custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
{code}
Nevertheless I want to version the module, therefore package my module with a given slot:
my/lognahdler/1.0
module.xml
my.jar
{code:xml}
<custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
{code}
But this fails with following stacktrace:
{code}
11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
("subsystem" => "logging"),
("custom-handler" => "4H")
]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
... 13 more
{code}
> logging custom-handler does not load module with slot
> -----------------------------------------------------
>
> Key: WFLY-6547
> URL: https://issues.jboss.org/browse/WFLY-6547
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Erwan Lacoste
> Assignee: James Perkins
>
> Tested on EAP 6.4
> when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
> my/loghandler/main
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
> {code}
> Nevertheless I want to version the module, therefore package my module with a given slot:
> my/loghandler/1.0
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
> {code}
> But this fails with following stacktrace:
> {code}
> 11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "4H")
> ]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 13 more
> {code}
> why is the module not found being *my.loghandler:1.0:main* ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years