[JBoss JIRA] (WFLY-1192) jboss-deployment-structure.xml top level exclusion does not work
by sathiya seelan (JIRA)
[ https://issues.jboss.org/browse/WFLY-1192?page=com.atlassian.jira.plugin.... ]
sathiya seelan commented on WFLY-1192:
--------------------------------------
Thanks for your response [~jaikiran]
I've followed the "HackinonWildfly" guide and set up locally.But having some issues, like "Testcases are failed".
So after fixing those issues, will drop a mail and start working on this issue.
> jboss-deployment-structure.xml top level exclusion does not work
> ----------------------------------------------------------------
>
> Key: WFLY-1192
> URL: https://issues.jboss.org/browse/WFLY-1192
> Project: WildFly
> Issue Type: Feature Request
> Components: Class Loading
> Environment: Windows, RedHat Linux
> Reporter: Markus Lindblom
> Fix For: Awaiting Volunteers
>
>
> When I try to exclude for example Log4J in the deployment structure I have to exclude it from every subdeployment in the deployment structure file, the top level exclusion should exclude it from the entire EAR and all of its subdeployments.
> Ed: The feature request is, to add a convenient way to cause exclusions to cascade to subdeployments. Right now it works per design.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1898:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from NEW to POST
> FD_HOST many false suspect with Full GC
> ---------------------------------------
>
> Key: JGRP-1898
> URL: https://issues.jboss.org/browse/JGRP-1898
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.5.1
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Fix For: 3.4.7, 3.5.2, 3.6.1
>
> Attachments: test-fdhost.zip
>
>
> Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop.
> {code}
> for (h: hosts) { ping_and_update_timestamp(host) }
> current = System.currentTimeMillis();
> for (h: hosts) { compare current and (ping_timestmp + timeout) }
> {code}
> Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects.
> For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation.
> To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-4120) JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507
by Manfred Otte (JIRA)
[ https://issues.jboss.org/browse/WFLY-4120?page=com.atlassian.jira.plugin.... ]
Manfred Otte updated WFLY-4120:
-------------------------------
Attachment: testjsr109.war
Reproduction should be possible with the attached WAR. It contains a very simple Webservice de.testjsr109.ServiceWithHandlerChain and an even simpler handler both packaged within a JAR.
The Webservice is annotated with a relative file-location: @HandlerChain(file = "../../handlerchain.xml"). The handler chain file resides in WEB-INF/classes. Deployment results in above mentioned error.
Moving the handler chain file from WEB-INF/classes to the root of the JAR results in a successful deployment and the endpoint is usable.
> JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-4120
> URL: https://issues.jboss.org/browse/WFLY-4120
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Environment: Windows 8.1
> Reporter: Manfred Otte
> Assignee: Alessio Soldano
> Priority: Minor
> Attachments: testjsr109.war
>
>
> Regarding JSR 109, chapter 6.3 the "handler chain file can also be packaged and specified in the annotation such that, it is accessible as a resource from the ClassPath. At runtime, container providers must first try to access the handler chain file as per the locations specified in JSR-181 specification. Failing that, they must try to access it as a resource from the ClassPath."
> The JBoss AS Documentation states that "The war is considered to be a single module, so classes defined in WEB-INF/lib are treated the same as classes in WEB-INF/classes. All classes packaged in the war will be loaded with the same class loader" (https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7).
> Following this statements I think it should be fine to have a HandlerChain-annnotated Webservice within a JAR inside a WAR (WEB-INF/lib) referencing a handler chain file that ist not part of the JAR but resides in WEB-INF/classes. However this situation results in
> {code}
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"testjsr109.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"testjsr109.war\".PARSE: JBAS018733: Failed to process phase PARSE of deployment \"testjsr109.war\"
> Caused by: javax.xml.ws.WebServiceException: JBAS015507: Handler chain config file handlerchain.xml not found in ResourceRoot [root=\"/D:/tools/wildfly-8.2.0.Final/bin/content/testjsr109.war/WEB-INF/lib/testjsr109.jar\"]"}},
> "rolled-back" => true
> }
> {code}
> The implementation of org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor seems to expect, that the handler chain file is always part of the ResourceRoot the annotated WebService lives in. With respect to JSR 109 I think that this expectation is wrong and that a handler chain file outside the JAR is a valid scenario.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-4120) JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507
by Manfred Otte (JIRA)
Manfred Otte created WFLY-4120:
----------------------------------
Summary: JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507
Key: WFLY-4120
URL: https://issues.jboss.org/browse/WFLY-4120
Project: WildFly
Issue Type: Bug
Components: Web Services
Affects Versions: 8.2.0.Final
Environment: Windows 8.1
Reporter: Manfred Otte
Assignee: Alessio Soldano
Priority: Minor
Regarding JSR 109, chapter 6.3 the "handler chain file can also be packaged and specified in the annotation such that, it is accessible as a resource from the ClassPath. At runtime, container providers must first try to access the handler chain file as per the locations specified in JSR-181 specification. Failing that, they must try to access it as a resource from the ClassPath."
The JBoss AS Documentation states that "The war is considered to be a single module, so classes defined in WEB-INF/lib are treated the same as classes in WEB-INF/classes. All classes packaged in the war will be loaded with the same class loader" (https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7).
Following this statements I think it should be fine to have a HandlerChain-annnotated Webservice within a JAR inside a WAR (WEB-INF/lib) referencing a handler chain file that ist not part of the JAR but resides in WEB-INF/classes. However this situation results in
{code}
Internal Server Error
{
"outcome" => "failed",
"failure-description" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"testjsr109.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"testjsr109.war\".PARSE: JBAS018733: Failed to process phase PARSE of deployment \"testjsr109.war\"
Caused by: javax.xml.ws.WebServiceException: JBAS015507: Handler chain config file handlerchain.xml not found in ResourceRoot [root=\"/D:/tools/wildfly-8.2.0.Final/bin/content/testjsr109.war/WEB-INF/lib/testjsr109.jar\"]"}},
"rolled-back" => true
}
{code}
The implementation of org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor seems to expect, that the handler chain file is always part of the ResourceRoot the annotated WebService lives in. With respect to JSR 109 I think that this expectation is wrong and that a handler chain file outside the JAR is a valid scenario.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable
by Vincent MATHON (JIRA)
[ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.... ]
Vincent MATHON edited comment on JBWEB-248 at 11/24/14 8:30 AM:
----------------------------------------------------------------
In a jar that is stored in JBoss 7 modules. This jar is also declared as a global module in standalone.xml.
was (Author: vmath):
In a jar that is stored in JBoss 7 modules. This jar is also the declared as a global module in standalone.xml.
> The default error report class valve should be overridable
> ----------------------------------------------------------
>
> Key: JBWEB-248
> URL: https://issues.jboss.org/browse/JBWEB-248
> Project: JBoss Web
> Issue Type: Feature Request
> Components: Tomcat
> Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA
> Reporter: Vincent MATHON
> Assignee: Remy Maucherat
>
> The default error report valve class cannot be configured since JBoss 7.x.
> The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable
by Vincent MATHON (JIRA)
[ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.... ]
Vincent MATHON commented on JBWEB-248:
--------------------------------------
In a jar that is stored in JBoss 7 modules. This jar is also the declared as a global module in standalone.xml.
> The default error report class valve should be overridable
> ----------------------------------------------------------
>
> Key: JBWEB-248
> URL: https://issues.jboss.org/browse/JBWEB-248
> Project: JBoss Web
> Issue Type: Feature Request
> Components: Tomcat
> Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA
> Reporter: Vincent MATHON
> Assignee: Remy Maucherat
>
> The default error report valve class cannot be configured since JBoss 7.x.
> The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.... ]
Jean-Frederic Clere commented on JBWEB-248:
-------------------------------------------
where do you put the valve?
> The default error report class valve should be overridable
> ----------------------------------------------------------
>
> Key: JBWEB-248
> URL: https://issues.jboss.org/browse/JBWEB-248
> Project: JBoss Web
> Issue Type: Feature Request
> Components: Tomcat
> Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA
> Reporter: Vincent MATHON
> Assignee: Remy Maucherat
>
> The default error report valve class cannot be configured since JBoss 7.x.
> The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-3152) Failed initializing module org.jboss.as.logging
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/WFLY-3152?page=com.atlassian.jira.plugin.... ]
Rob Stryker commented on WFLY-3152:
-----------------------------------
This bugzilla entry indicates connecting an agent might be a cause: https://bugzilla.redhat.com/show_bug.cgi?id=1037970
It seems JBDS contains plugins that connect an external agent to all new running java processes, scanning for new ones every x-seconds. This may be the cause on our side. The quick connection of the agent will cause this bug.
> Failed initializing module org.jboss.as.logging
> ------------------------------------------------
>
> Key: WFLY-3152
> URL: https://issues.jboss.org/browse/WFLY-3152
> Project: WildFly
> Issue Type: Bug
> Reporter: Huu Loi Lai
> Priority: Blocker
>
> I try to run integration test with arquillian and wildfly and I get following erros:
> ERROR: JBAS014612: Operation ("parallel-extension-add") failed - address: ([])
> java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:99)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:314)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:294)
> at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> at org.jboss.as.server.ServerService.boot(ServerService.java:331)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:91)
> ... 10 more
> Caused by: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:103)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:98)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:113)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable
by Vincent MATHON (JIRA)
[ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.... ]
Vincent MATHON commented on JBWEB-248:
--------------------------------------
Actually It does work. Anyway it is not portable to wildfly 8.x. I had this need for security reasons that wildfly does anticipate (no stack trace in case of error), so I do not need this hack anymore and this issue may be closed.
> The default error report class valve should be overridable
> ----------------------------------------------------------
>
> Key: JBWEB-248
> URL: https://issues.jboss.org/browse/JBWEB-248
> Project: JBoss Web
> Issue Type: Feature Request
> Components: Tomcat
> Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA
> Reporter: Vincent MATHON
> Assignee: Remy Maucherat
>
> The default error report valve class cannot be configured since JBoss 7.x.
> The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months