[JBoss JIRA] (JGRP-1749) Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1749?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1749:
---------------------------
Description:
If we have
{code:xml}
<UDP mcast_addr="${myapp.mcast_addr:235.5.5.5}".../>
{code}
, then the default mcast_addr is {{235.5.5.5}}.
If we set {{-Dmyapp.mcast_addr=238.5.5.5}} but also set {{-Djgroups.udp.mcast_addr=239.5.5.5}}, then *the latter system property always overrides the former*, so we'll use {{239.5.5.5}} as mcast_addr.
This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.mcast_addr}} and the other {{myapp2.mcast_addr}}. If {{-Djgroups.udp.mcast_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different mcast addresses !
This means that - if we use the same {{mcast_port}} value - the 2 clusters will see each other's traffic as they use the same {{mcast_addr}}.
Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this.
SOLUTION:
* If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.mcast_addr}}, then use that value
* If the value is not set and a system property (e.g. {{jgroups.udp.mcast_addr}}) has been set, set the value from that system property
was:
If we have
{code:xml}
<UDP bind_addr="${myapp.bind_addr:127.0.0.1}".../>
{code}
, then the default bind_addr is {{127.0.0.1}}.
If we set {{-Dmyapp.bind_addr=1.2.3.4}} but also set {{-Djgroups.bind_addr=5.6.7.8}}, then *the latter system property always overrides the former*.
This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.bind_addr}} and the other {{myapp2.bind_addr}}. If {{-Djgroups.bind_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different bind addresses !
Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this.
SOLUTION:
* If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.bind_addr}}, then use that value
* If the value is not set and a system property (e.g. {{jgroups.bind_addr}}) has been set, set the value from that system property
> Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port
> -------------------------------------------------------------------------------------
>
> Key: JGRP-1749
> URL: https://issues.jboss.org/browse/JGRP-1749
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.2, 3.5
>
>
> If we have
> {code:xml}
> <UDP mcast_addr="${myapp.mcast_addr:235.5.5.5}".../>
> {code}
> , then the default mcast_addr is {{235.5.5.5}}.
> If we set {{-Dmyapp.mcast_addr=238.5.5.5}} but also set {{-Djgroups.udp.mcast_addr=239.5.5.5}}, then *the latter system property always overrides the former*, so we'll use {{239.5.5.5}} as mcast_addr.
> This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.mcast_addr}} and the other {{myapp2.mcast_addr}}. If {{-Djgroups.udp.mcast_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different mcast addresses !
> This means that - if we use the same {{mcast_port}} value - the 2 clusters will see each other's traffic as they use the same {{mcast_addr}}.
> Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this.
> SOLUTION:
> * If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.mcast_addr}}, then use that value
> * If the value is not set and a system property (e.g. {{jgroups.udp.mcast_addr}}) has been set, set the value from that system property
--
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
12 years
[JBoss JIRA] (WFLY-2107) JASPI custom provider fails with no explicit error message
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2107?page=com.atlassian.jira.plugin.... ]
Stefan Guilhen resolved WFLY-2107.
----------------------------------
Fix Version/s: 8.0.0.CR1
Resolution: Done
This has been fixed a while ago in PicketBox as part of SECURITY-759
> JASPI custom provider fails with no explicit error message
> ----------------------------------------------------------
>
> Key: WFLY-2107
> URL: https://issues.jboss.org/browse/WFLY-2107
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> The JASPI module loading code does not provide a useful error message. The error appears to be generated in org.jboss.security.auth.message.config.JBossServerAuthConfig, but its lost before it makes it into the log file.
> A user can run into this issue when the auth-module class name (the 'code' attribute) is wrong or when a custom auth-module is used and the class loading dependencies are not setup correctly.
> Steps to Reproduce:
> 1. Misspell the auth-module class name
--
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
12 years
[JBoss JIRA] (WFLY-2682) Conversation identifier does not get incremented
by Adriano Scheffer (JIRA)
Adriano Scheffer created WFLY-2682:
--------------------------------------
Summary: Conversation identifier does not get incremented
Key: WFLY-2682
URL: https://issues.jboss.org/browse/WFLY-2682
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CDI / Weld, JSF
Affects Versions: 8.0.0.CR1
Environment: Windows 7
Reporter: Adriano Scheffer
Assignee: Stuart Douglas
The conversation id is not getting incremented when I open another browser tab. Conversally, this problems was not happening in Beta1.
--
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
12 years
[JBoss JIRA] (JGRP-1749) Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1749?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1749:
---------------------------
Description:
If we have
{code:xml}
<UDP bind_addr="${myapp.bind_addr:127.0.0.1}".../>
{code}
, then the default bind_addr is {{127.0.0.1}}.
If we set {{-Dmyapp.bind_addr=1.2.3.4}} but also set {{-Djgroups.bind_addr=5.6.7.8}}, then *the latter system property always overrides the former*.
This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.bind_addr}} and the other {{myapp2.bind_addr}}. If {{-Djgroups.bind_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different bind addresses !
Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this.
SOLUTION:
* If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.bind_addr}}, then use that value
* If the value is not set and a system property (e.g. {{jgroups.bind_addr}}) has been set, set the value from that system property
was:
If we have
{code:xml}
<UDP bind_addr="${myapp.bind_addr:127.0.0.1}".../>
{code}
, then the default bind_addr is {{127.0.0.1}}.
If we set {{-Dmyapp.bind_addr=1.2.3.4}} but also set {{-Djgroups.bind_addr=5.6.7.8}}, then *the latter system property always overrides the former*.
This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.bind_addr}} and the other {{myapp2.bind_addr}}. If {{-Djgroups.bind_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different bind addresses !
Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this.
SOLUTION: remove the _global_ system properties such as {{jgroups.bind_addr}}.
> Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, jgroups.udp.mcast_port
> -------------------------------------------------------------------------------------
>
> Key: JGRP-1749
> URL: https://issues.jboss.org/browse/JGRP-1749
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.2, 3.5
>
>
> If we have
> {code:xml}
> <UDP bind_addr="${myapp.bind_addr:127.0.0.1}".../>
> {code}
> , then the default bind_addr is {{127.0.0.1}}.
> If we set {{-Dmyapp.bind_addr=1.2.3.4}} but also set {{-Djgroups.bind_addr=5.6.7.8}}, then *the latter system property always overrides the former*.
> This is bad, e.g. when we have multiple channels in the same JVM, where one channel uses {{myapp1.bind_addr}} and the other {{myapp2.bind_addr}}. If {{-Djgroups.bind_addr}} is set (e.g. by JBoss EAP), then we'll always use it rather than the different bind addresses !
> Investigate whether we still need to use those overrides. Contact Brian Stansberry, IIRC he's the one who suggested this.
> SOLUTION:
> * If a property is set in the XML, either directly or via property substitution (e.g. {{myapp.bind_addr}}, then use that value
> * If the value is not set and a system property (e.g. {{jgroups.bind_addr}}) has been set, set the value from that system property
--
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
12 years
[JBoss JIRA] (SECURITY-777) Picketbox uses non-synchronized static maps
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-777?page=com.atlassian.jira.plug... ]
Stefan Guilhen resolved SECURITY-777.
-------------------------------------
Fix Version/s: PicketBox_4_0_20.Final
Resolution: Done
Patch has been applied to PicketBox trunk
> Picketbox uses non-synchronized static maps
> -------------------------------------------
>
> Key: SECURITY-777
> URL: https://issues.jboss.org/browse/SECURITY-777
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: PicketBox_4_0_20.Beta2
> Reporter: Stuart Douglas
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_0_20.Final
>
> Attachments: picketlink.diff
>
>
> Picketbox uses quite a few static maps as global registries (yuck), and unfortunately they are not all thread safe, which can result in races as Wildfly starts security domains asynchronously.
> Please see attached patch.
--
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
12 years
[JBoss JIRA] (WFLY-2448) Print IOR to a user specified file
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2448?page=com.atlassian.jira.plugin.... ]
Stefan Guilhen commented on WFLY-2448:
--------------------------------------
I think this is a perfectly valid RFE so I encourage you to submit your patch
> Print IOR to a user specified file
> ----------------------------------
>
> Key: WFLY-2448
> URL: https://issues.jboss.org/browse/WFLY-2448
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: IIOP
> Affects Versions: 8.0.0.Beta1
> Environment: Windows, Solaris, Linux
> Reporter: Sumanth M S
> Assignee: Stefan Guilhen
> Priority: Minor
> Fix For: 8.0.0.Final
>
>
> Jboss AS prints Corba IOR on console or log file. Many applications look for a file at a predefined location from where it can read the IOR; as it is difficult to read IOR programatically from a log file or console.
> An environment variable can be defined in standalone.conf to let the user specify the file location to which JBoss will print the IOR along with printing on the console.
> The solution has been tried and seems working. Please let us know if the solution can be submitted.
--
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
12 years