January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4254) Symbolic links within web applications do not work

by James Roos (JIRA)

[ https://issues.jboss.org/browse/WFLY-4254?page=com.atlassian.jira.plugin.... ] James Roos commented on WFLY-4254: ---------------------------------- Is there any possibility of a patch for 8.2.0 being created to address this issue. I've got a dead line and can't wait for 9.x to be released and I would rather not role back to 8.1.0. > Symbolic links within web applications do not work > -------------------------------------------------- > > Key: WFLY-4254 > URL: https://issues.jboss.org/browse/WFLY-4254 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Kris Iyer > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > Symbolic Linking under exploded web-apps to files and/or directories outside the web-app do not work. > Here is what I tried under an exploded war: > <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" > version="8.0"> > <symbolic-linking-enabled>true</symbolic-linking-enabled> > </jboss-web> > Does not follow links and results in a 404. > HTTP/?.? 404 Not Found > Connection: keep-alive > X-Powered-By: Undertow/1 > Server: WildFly/8 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-868: -------------------------------------------------- Ondrej Kotek <okotek(a)redhat.com> changed the Status of [bug 1181084|https://bugzilla.redhat.com/show_bug.cgi?id=1181084] from ON_QA to VERIFIED > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Beta3 > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-185: --------------------------------------- The problem was identified long after 5.5 was released officially. Please try a more recent version Best Davide > ClassCastException at ConditionEvaluator > ---------------------------------------- > > Key: DROOLS-185 > URL: https://issues.jboss.org/browse/DROOLS-185 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final > Reporter: Sergey Alaev > Assignee: Mario Fusco > > Stacktrace: > Caused by: java.lang.ClassCastException: ***** cannot be cast to ****** > at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source) > at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200) > at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157) > at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318) > at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116) > at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154) > at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) > Reason: > ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments. > Given following: > interface A { > String getString(); > } > interface B { > String getString(); > } > class X implements B, A {} > class Y implements A{} > rule "test rule" > when: > A(string != null) > then: > end > When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B. > Thus second call with instance of class Y will cause ClassCastException of casting Y to B. > Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A. > Quickfix: use following declaration of class X: > class X implements A, B {} > Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4290) Datasource template operation

by Jesper Pedersen (JIRA)

Jesper Pedersen created WFLY-4290: ------------------------------------- Summary: Datasource template operation Key: WFLY-4290 URL: https://issues.jboss.org/browse/WFLY-4290 Project: WildFly Issue Type: Task Components: JCA Reporter: Jesper Pedersen Assignee: Stefano Maestri {noformat} /subsystem=datasources/datasource=<datasource-name>:add(type=”postgresql”, url=””, driver=””) {noformat} Could have an optional capacity profile -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks

by Anuj Shah (JIRA)

Anuj Shah created JGRP-1908: ------------------------------- Summary: Optional Executing protocol behavior to not attempt to repeat tasks Key: JGRP-1908 URL: https://issues.jboss.org/browse/JGRP-1908 Project: JGroups Issue Type: Feature Request Reporter: Anuj Shah Assignee: Bela Ban As discussed on forum: http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le... {quote} I've noticed that runnable tasks submitted to the ExecutionService can be run more than once! This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc // The person currently servicing our request has gone down // without completing so we have to keep our request alive by // sending ours back to the coordinator The problem is that there is no guarantee that the request was not completed. For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout. I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though) Perhaps there could be control over the behaviour: * At least once - assumes task failed and resubmits * At most once - assumes task completed and cleans up - may not actually be complete * Exactly once - not sure if this is possible {quote} There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork: https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192... Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-866: -------------------------------------------------- Ondrej Kotek <okotek(a)redhat.com> changed the Status of [bug 1181086|https://bugzilla.redhat.com/show_bug.cgi?id=1181086] from ON_QA to VERIFIED > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-4289: --------------------------------- Assignee: Alessio Soldano (was: Darran Lofthouse) > Authentication bug on one-way JAX-WS methods > -------------------------------------------- > > Key: WFLY-4289 > URL: https://issues.jboss.org/browse/WFLY-4289 > Project: WildFly > Issue Type: Bug > Components: Security, Web Services > Affects Versions: 8.2.0.Final > Reporter: Jakub Grabowski > Assignee: Alessio Soldano > > 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL. > 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation. > 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal. > 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected. > It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4165) Invalidating another session removes the JSESSIONID cookie of the current session

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4165?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-4165. ---------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done > Invalidating another session removes the JSESSIONID cookie of the current session > --------------------------------------------------------------------------------- > > Key: WFLY-4165 > URL: https://issues.jboss.org/browse/WFLY-4165 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 8.2.0.Final > Environment: WildFly 8.1.0.Final and WildFly 8.2.0.Final on Windows 7 x64 > JDK 8u25 > Session storage set to Cookie > Reporter: Nicolas Grussenmeyer > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > When calling {{invalidate()}} on a HttpSession object of another session than the current one, the server sends back a "cookie expired" header {{Set-Cookie: JSESSIONID=XXXXXXXX; path=/; HttpOnly; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT}} where XXXXXXXX is the session id of the invalidated session. > This results in the current JSESSIONID cookie being discarded by the browser, and the current session being lost. > I was able to narrow the "problem" in {{[io.undertow.servlet.spec.HttpSessionImpl:193|https://github.com/undertow-io/undertow/blob/1.0.15.Final/servlet/src/main/java/io/undertow/servlet/spec/HttpSessionImpl.java#L193]}} (in Undertow 1.0.15.Final), where the ServletRequestContext is taken from the ThreadLocal storage, returning the current request context instead of null (as the target session is not associated to the current ServletRequestContext ) > A workaround is to call {{invalidate()}} in a new Thread, so the retrieved ServletRequestContext is null -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-207) Add start/stop operations to hornetq-server resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-207: ---------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1099730|https://bugzilla.redhat.com/show_bug.cgi?id=1099730] from NEW to CLOSED > Add start/stop operations to hornetq-server resource > ---------------------------------------------------- > > Key: WFLY-207 > URL: https://issues.jboss.org/browse/WFLY-207 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > Currently it is not possible to start/stop a hornetq-server resource without removing or adding it. > For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-84) Jboss JMX: Operation failed with status WAITING

by Thorsten Kunz (JIRA)

[ https://issues.jboss.org/browse/REMJMX-84?page=com.atlassian.jira.plugin.... ] Thorsten Kunz commented on REMJMX-84: ------------------------------------- Not sure if this is still the right issue to post to or if there is another one for WildFly but the issue still persists in WildFly 8.2: {code} Caused by: java.lang.RuntimeException: Operation failed with status WAITING at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:240) ~[jboss-cli-client.jar:8.2.0.Final] at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:151) ~[jboss-cli-client.jar:8.2.0.Final] at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:102) ~[jboss-cli-client.jar:8.2.0.Final] at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:268) ~[na:1.7.0_65] at com.zabbix.gateway.JMXItemChecker.getValues(JMXItemChecker.java:95) ~[zabbix-java-gateway-2.2.5.jar:na] {code} The issue is still intermittent. JDK: java version "1.7.0_65" OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) OS: LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 6.5 (Santiago) Release: 6.5 Codename: Santiago > Jboss JMX: Operation failed with status WAITING > ------------------------------------------------ > > Key: REMJMX-84 > URL: https://issues.jboss.org/browse/REMJMX-84 > Project: Remoting JMX > Issue Type: Bug > Environment: jboss-as-7.1.1.Final on windows server > Reporter: Abhishek Apoorva > Assignee: David Lloyd > > Version : jboss-as-7.1.1.Final on windows server > I am getting below mentioned strange issue intermittently while fetching > Jboss JMX Mbean. > Can anyone help me to find the real cause of the issue? Secong thing is why it is coming intermittently either it should come always or it should not come at all. > JMXConnectorFactory.connect(serviceURL, environment); > While executing above mentioned line system is throwing below mentioned exception. > {noformat} > May 08 02:30:53:375 [DC#0, jboss] java.lang.RuntimeException: Operation failed with status WAITING > at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:216) > at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:143) > at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:94) > at javax.management.remote.JMXConnectorFactory.connect(Unknown Source) > at com.nimsoft.nimbus.probe.application.jboss.JmxConnection.createConnection(JmxConnection.java:68) > at com.nimsoft.nimbus.probe.application.jsr160.Entity.createConnection(Entity.java:1772) > at com.nimsoft.nimbus.probe.application.jsr160.Entity.getValue(Entity.java:1567) > at com.nimsoft.nimbus.probe.application.extractbase.Extract.processMonitor(Extract.java:1324) > at com.nimsoft.nimbus.probe.application.extractbase.Extract.processResource(Extract.java:1908) > at com.nimsoft.nimbus.probe.application.extractbase.Extract$DataCollector.run(Extract.java:1158) > at java.lang.Thread.run(Unknown Source) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015