[JBoss JIRA] (JGRP-1740) Byteman tests fail on Windows
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1740?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1740.
----------------------------
Resolution: Done
> Byteman tests fail on Windows
> -----------------------------
>
> Key: JGRP-1740
> URL: https://issues.jboss.org/browse/JGRP-1740
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> The Byteman tests in the Jgroups testsuite fail when running the testsuite on Windows. The error text is as follows:
> {noformat}
> byteman:
> [testng] -- onStart -- byteman
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.BecomeServerTest#testSendingOfMsgsOnUnconnectedChannel
> [testng] FAIL: [1] org.jgroups.tests.byteman.BecomeServerTest.bmngBeforeTest-Method()
> [testng] SKIP: [1] org.jgroups.tests.byteman.BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel()
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.BecomeServerTest#testSendingOfMsgsOnUnconnectedChannel
> [testng] FAIL: [1] org.jgroups.tests.byteman.BecomeServerTest.bmngAfterTest-Method()
> [testng] SKIP: [1] org.jgroups.tests.byteman.ForwardToCoordFailoverTest.testSendingDuringViewChange()
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.ForwardToCoordFailoverTest#testSendingDuringViewChange
> [testng] FAIL: [1] org.jgroups.tests.byteman.ForwardToCoordFailoverTest.bmngAfterTest-Method()
> [testng] SKIP: [1] org.jgroups.tests.byteman.MessageBeforeConnectedTest.testSendingOfMsgsOnUnconnectedChannel()
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.MessageBeforeConnectedTest#testSendingOfMsgsOnUnconnectedChannel
> [testng] FAIL: [1] org.jgroups.tests.byteman.MessageBeforeConnectedTest.bmngAfterTest-Method()
> [testng] SKIP: [1] org.jgroups.tests.byteman.SequencerFailoverTest.testBroadcastSequenceSenderIsB()
> [testng] SKIP: [1] org.jgroups.tests.byteman.SequencerFailoverTest.testBroadcastSequenceSenderIsC()
> [testng] SKIP: [1] org.jgroups.tests.byteman.SequencerFailoverTest.testFailoverWithMultipleThreadsSendingMessages()
> [testng] SKIP: [1] org.jgroups.tests.byteman.SequencerFailoverTest.testResendingVersusNewMessages()
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.SequencerFailoverTest#testResendingVersusNewMessages
> [testng] FAIL: [1] org.jgroups.tests.byteman.SequencerFailoverTest.bmngAfterTest-Method()
> [testng] The tests failed.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JGRP-1740) Byteman tests fail on Windows
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1740?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1740:
--------------------------------
OK, scripts are now found. See my comment on the PR: I'm not going to apply the kludge to locate the byteman JARs.
> Byteman tests fail on Windows
> -----------------------------
>
> Key: JGRP-1740
> URL: https://issues.jboss.org/browse/JGRP-1740
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.5
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> The Byteman tests in the Jgroups testsuite fail when running the testsuite on Windows. The error text is as follows:
> {noformat}
> byteman:
> [testng] -- onStart -- byteman
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.BecomeServerTest#testSendingOfMsgsOnUnconnectedChannel
> [testng] FAIL: [1] org.jgroups.tests.byteman.BecomeServerTest.bmngBeforeTest-Method()
> [testng] SKIP: [1] org.jgroups.tests.byteman.BecomeServerTest.testSendingOfMsgsOnUnconnectedChannel()
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.BecomeServerTest#testSendingOfMsgsOnUnconnectedChannel
> [testng] FAIL: [1] org.jgroups.tests.byteman.BecomeServerTest.bmngAfterTest-Method()
> [testng] SKIP: [1] org.jgroups.tests.byteman.ForwardToCoordFailoverTest.testSendingDuringViewChange()
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.ForwardToCoordFailoverTest#testSendingDuringViewChange
> [testng] FAIL: [1] org.jgroups.tests.byteman.ForwardToCoordFailoverTest.bmngAfterTest-Method()
> [testng] SKIP: [1] org.jgroups.tests.byteman.MessageBeforeConnectedTest.testSendingOfMsgsOnUnconnectedChannel()
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.MessageBeforeConnectedTest#testSendingOfMsgsOnUnconnectedChannel
> [testng] FAIL: [1] org.jgroups.tests.byteman.MessageBeforeConnectedTest.bmngAfterTest-Method()
> [testng] SKIP: [1] org.jgroups.tests.byteman.SequencerFailoverTest.testBroadcastSequenceSenderIsB()
> [testng] SKIP: [1] org.jgroups.tests.byteman.SequencerFailoverTest.testBroadcastSequenceSenderIsC()
> [testng] SKIP: [1] org.jgroups.tests.byteman.SequencerFailoverTest.testFailoverWithMultipleThreadsSendingMessages()
> [testng] SKIP: [1] org.jgroups.tests.byteman.SequencerFailoverTest.testResendingVersusNewMessages()
> [testng] failed config: java.io.FileNotFoundException: Rule file not found for Byteman test case org.jgroups.tests.byteman.SequencerFailoverTest#testResendingVersusNewMessages
> [testng] FAIL: [1] org.jgroups.tests.byteman.SequencerFailoverTest.bmngAfterTest-Method()
> [testng] The tests failed.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2318) Access control exceptions missing for scoped roles
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-2318?page=com.atlassian.jira.plugin.... ]
Harald Pehl commented on WFLY-2318:
-----------------------------------
I'm wondering what kind of exceptions I can expect for nested nodes? Suppose that I have setup the following groups:
{code:xml}
<server-groups>
<server-group name="main-server-group" profile="full">
<jvm name="default">
<heap size="64m" max-size="512m"/>
</jvm>
<socket-binding-group ref="full-sockets"/>
</server-group>
<server-group name="other-server-group" profile="full-ha">
<jvm name="default">
<heap size="64m" max-size="512m"/>
</jvm>
<socket-binding-group ref="full-ha-sockets"/>
</server-group>
</server-groups>
{code}
If I ask for the rights of the JVM node using
{code}
/server-group=*/jvm=*:read-resource-description(access-control=trim-descriptions,operations=true){roles=[main-maintainer,other-monitor]}
{code}
I do get exceptions as long as there's a JVM node for the main group. If there's no JVM configurtation for "main-server-group" I don't see exceptions. Is this on purpose or am I missing something?
What I would like to see are exceptions no matter whether there's a JVM node defined or not. By that I can check if the user is allowed to *add* a JVM configuration for a specific server group. Right now I don't know how to resolve this.
> Access control exceptions missing for scoped roles
> --------------------------------------------------
>
> Key: WFLY-2318
> URL: https://issues.jboss.org/browse/WFLY-2318
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Harald Pehl
>
> The following setup: user with two scoped roles assigned. maintainer for "main-servers", monitor for "other-servers". Requesting the access control meta data for the server group wildcard ]does not include "exceptions".
> Expected result: the access control meta data response contains an "exception" for each server group (main-server-group & other-server-group)
> {code}
> [domain@localhost:9999 /] ./server-group=*:read-resource-description(access-control=trim-descriptions, operations=true){roles=main-servers, other-servers}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("server-group" => "*")],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "attributes" => undefined,
> "operations" => undefined,
> "children" => {
> "deployment" => {"model-description" => undefined},
> "system-property" => {"model-description" => undefined},
> "jvm" => {"model-description" => undefined},
> "deployment-overlay" => {"model-description" => undefined}
> },
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => true,
> "attributes" => {
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => true
> },
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => true
> },
> "profile" => {
> "read" => true,
> "write" => true
> }
> },
> "operations" => {
> "read-children-names" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "remove" => {"execute" => true},
> "read-resource-description" => {"execute" => true},
> "stop-servers" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => true},
> "read-attribute" => {"execute" => true},
> "whoami" => {"execute" => true},
> "read-children-types" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "undefine-attribute" => {"execute" => true},
> "start-servers" => {"execute" => true},
> "read-children-resources" => {"execute" => true},
> "restart-servers" => {"execute" => true},
> "replace-deployment" => {"execute" => true},
> "write-attribute" => {"execute" => true}
> }
> },
> "exceptions" => {}
> }
> }
> }]
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (SECURITY-772) SPNEGOLoginModule does not always respect removeRealmFromPrincipal
by Tom Fonteyne (JIRA)
Tom Fonteyne created SECURITY-772:
-------------------------------------
Summary: SPNEGOLoginModule does not always respect removeRealmFromPrincipal
Key: SECURITY-772
URL: https://issues.jboss.org/browse/SECURITY-772
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Negotiation
Affects Versions: Negotiation_2_2_6
Reporter: Tom Fonteyne
Assignee: Tom Fonteyne
Priority: Minor
org.jboss.security.negotiation.spnego.SPNEGOLoginModule
private class AcceptSecContext:
if (gssContext.isEstablished())
{
log.warn("Authentication was performed despite already being authenticated!");
// TODO - Refactor to only do this once.
setIdentity(new KerberosPrincipal(gssContext.getSrcName().toString()));
The last line should obey the "removeRealmFromPrincipal" flag similarly as a bit further down:
setIdentity(createIdentity(gssContext.getSrcName().toString()));
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2196) add x-forwarded-* headers support
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2196?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2196:
------------------------------
Fix Version/s: 8.0.0.CR1
> add x-forwarded-* headers support
> ---------------------------------
>
> Key: WFLY-2196
> URL: https://issues.jboss.org/browse/WFLY-2196
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Michał Zegan
> Assignee: Tomaz Cerar
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> Hello.
> If it is desirable, can you add the possibility for wildfly/undertow subsystem to retrieve x-forwarded-host and similar headers and set a remote ip address and hostname based on it?
> This header is set by proxy servers to indicate proxies this request has passed and to indicate the client's real ip address.
> It's extremely useful if an application checks and uses the hostname or ip of a client that connects to it.
> In the case of wildfly directly open to the public, the ip and host given will be that of a client, but if the server where an application is running is just a backend server and there is a frontend before it that proxies to it, the ip and host will be that of the proxy, often localhost if the proxy sits on the same machine, that is undesirable because you don't want to ip-ban a proxy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt() consumes 100% CPU
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-272:
------------------------------------------------
Tomas David <tdavid(a)redhat.com> changed the Status of [bug 1012140|https://bugzilla.redhat.com/show_bug.cgi?id=1012140] from ON_QA to VERIFIED
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
> Key: DROOLS-272
> URL: https://issues.jboss.org/browse/DROOLS-272
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR3
> Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
> Reporter: Duncan Doyle
> Assignee: Edson Tirelli
> Priority: Blocker
> Fix For: 6.0.0.CR5
>
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2196) add x-forwarded-* headers support
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2196?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-2196:
------------------------------------
Assignee: Tomaz Cerar
Tomaz, can you have a look at this?
Basically we just need to wire up the ProxyPeerAddressHandler, in the same manner that we already do for the SSLHeaderHandler.
> add x-forwarded-* headers support
> ---------------------------------
>
> Key: WFLY-2196
> URL: https://issues.jboss.org/browse/WFLY-2196
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Michał Zegan
> Assignee: Tomaz Cerar
> Priority: Minor
>
> Hello.
> If it is desirable, can you add the possibility for wildfly/undertow subsystem to retrieve x-forwarded-host and similar headers and set a remote ip address and hostname based on it?
> This header is set by proxy servers to indicate proxies this request has passed and to indicate the client's real ip address.
> It's extremely useful if an application checks and uses the hostname or ip of a client that connects to it.
> In the case of wildfly directly open to the public, the ip and host given will be that of a client, but if the server where an application is running is just a backend server and there is a frontend before it that proxies to it, the ip and host will be that of the proxy, often localhost if the proxy sits on the same machine, that is undesirable because you don't want to ip-ban a proxy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-2531) WildFly breaks utf-8 encoded strings in x-www-form-urlencoded
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2531?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-2531.
----------------------------------
Fix Version/s: 8.0.0.CR1
Resolution: Partially Completed
Wildfly now contains a way to set default encoding, as a way to fix the weld issue. There are also workarounds that are specified in the other issue.
> WildFly breaks utf-8 encoded strings in x-www-form-urlencoded
> -------------------------------------------------------------
>
> Key: WFLY-2531
> URL: https://issues.jboss.org/browse/WFLY-2531
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Denis Kostousov
> Assignee: Stuart Douglas
> Fix For: 8.0.0.CR1
>
>
> HTTP clients don't send the charset definition in a Content-Type header during form posting. The undertow-core library assume ISO-8859-1 as default encoding for x-www-form-urlencoded requests. Therefore a javaee application can't receive correct non-english characters.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-1950) Problems with connector 1.7
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-1950?page=com.atlassian.jira.plugin.... ]
Frank Langelage updated WFLY-1950:
----------------------------------
Attachment: filesystem.rar
> Problems with connector 1.7
> ---------------------------
>
> Key: WFLY-1950
> URL: https://issues.jboss.org/browse/WFLY-1950
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: Frank Langelage
> Assignee: Jeff Zhang
> Attachments: filesystem-ra.xml.1.6.1.7, filesystem-ra.xml.1.7, filesystem-ra.xml.before, filesystem.rar
>
>
> Usually I see this when deploying my RA:
> 21:30:53,599 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:30:53,745 INFO [org.jboss.as.connector.deployment#bindConnectionFactory] JBAS010406: Registered connection factory java:/Filesystem
> 21:30:53,750 INFO [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] IJ020002: Deployed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-acf9504f544e0a1d/contents/
> 21:30:53,764 INFO [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> 21:30:53,822 INFO [org.jboss.as.server#handleResult] JBAS018559: Deployed "filesystem.rar" (runtime-name : "filesystem.rar")
> Because JCA 1.7 was introduced to head at github I changed header of ra.xml to 1.7 version.
> But then I no longer see the line
> 21:30:53,764 INFO [org.jboss.as.connector.deployment#transition] JBAS010401: Bound JCA ConnectionFactory [java:/Filesystem]
> I did not specify the <outbound-resourceadapter> in ra.xml.
> Another adapter is working fine after version upgrade.
> So I added the <outbound-resourceadapter> also to the now failing one.
> But this gives this now:
> 21:35:57,797 INFO [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "filesystem.rar" (runtime-name: "filesystem.rar")
> 21:35:57,941 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in service jboss.ra.deployment."filesystem.rar_4": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:136)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:120)
> ... 5 more
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2564)
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:197)
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:113)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.jca.common.metadata.ra.common.OutboundResourceAdapterImpl.getReauthenticationSupport(OutboundResourceAdapterImpl.java:182)
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2073)
> ... 7 more
> 21:35:57,962 ERROR [org.jboss.as.controller.management-operation#executeStep] JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "filesystem.rar")]) - failure description: {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
> Caused by: java.lang.NullPointerException"}}
> 21:35:57,982 ERROR [org.jboss.as.server#handleResult] JBAS015870: Deploy of deployment "filesystem.rar" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.ra.deployment.\"filesystem.rar_4\"" => "org.jboss.msc.service.StartException in service jboss.ra.deployment.\"filesystem.rar_4\": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [filesystem]
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp8a8dd6af6d60d261/filesystem.rar-c256d8da3c2df580/contents/
> Caused by: java.lang.NullPointerException"}}
> 21:35:58,011 INFO [org.jboss.as.server.deployment#stop] JBAS015877: Stopped deployment filesystem.rar (runtime-name: filesystem.rar) in 24ms
> Adding also <reauthentication-support>false</reauthentication-support> solves this NPE, the RA gets deployed and bound to JNDI again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months