[JBoss JIRA] (WFLY-2972) Load vault impls from modules other than org.jboss.security
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2972?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-2972.
------------------------------------
Resolution: Duplicate Issue
> Load vault impls from modules other than org.jboss.security
> -----------------------------------------------------------
>
> Key: WFLY-2972
> URL: https://issues.jboss.org/browse/WFLY-2972
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Anil Saldhana
>
> The vault resources in our management model have a "code" attribute that specifies the classname of a custom Vault impl. But there is no "module" attribute to specify the name of the module to load that class from. This means users would have to modify the org.jboss.security module's module.xml to statically declare their module as a dependency.
> There should be a "module" attribute and org.jboss.security.vault.SecurityVaultFactory should expose a "get" variant that takes a ClassLoader so the appropriate module classloader can be used.
> I only looked at the core model but I suspect the security subsystem has the same issue.
--
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, 1 month
[JBoss JIRA] (JGRP-1808) Mac OS: no multicast route for 127.0.0.1
by Bela Ban (JIRA)
Bela Ban created JGRP-1808:
------------------------------
Summary: Mac OS: no multicast route for 127.0.0.1
Key: JGRP-1808
URL: https://issues.jboss.org/browse/JGRP-1808
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
On Mac OS (Mavericks), there is no multicast route in the routing table. So the default route is used (say 192.168.1.1). However, this doesn't work for nodes bound to 127.0.0.1 (don't know why).
So for loopback, an mcast route has to be added, e.g.
{noformat}
sudo route add -net 224.0.0.0/4 127.0.0.1
{noformat}
This adds a default route to all class D (multicast) addresses via loopback. However, this doesn't work if the node is bound to 192.168.1.x !
TODO:
* See if we can get a default multicast route through 192.168.1.1 and make nodes bound to 127.0.0.1 use it
* If this doesn't work, define multiple mcast routes for different mcast addresses, e.g.
{noformat}
sudo route add -net 224.0.0.0/4 127.0.0.1
sudo route add -net 230.0.0.0/8 192.168.1.0
{noformat}
This adds loopback as default mcast route, but uses en0 if a multicast address starts with 230.x.x.x.
--
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, 1 month
[JBoss JIRA] (JGRP-1808) Mac OS: no multicast route for 127.0.0.1
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1808?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1808:
---------------------------
Priority: Minor (was: Major)
> Mac OS: no multicast route for 127.0.0.1
> ----------------------------------------
>
> Key: JGRP-1808
> URL: https://issues.jboss.org/browse/JGRP-1808
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> On Mac OS (Mavericks), there is no multicast route in the routing table. So the default route is used (say 192.168.1.1). However, this doesn't work for nodes bound to 127.0.0.1 (don't know why).
> So for loopback, an mcast route has to be added, e.g.
> {noformat}
> sudo route add -net 224.0.0.0/4 127.0.0.1
> {noformat}
> This adds a default route to all class D (multicast) addresses via loopback. However, this doesn't work if the node is bound to 192.168.1.x !
> TODO:
> * See if we can get a default multicast route through 192.168.1.1 and make nodes bound to 127.0.0.1 use it
> * If this doesn't work, define multiple mcast routes for different mcast addresses, e.g.
> {noformat}
> sudo route add -net 224.0.0.0/4 127.0.0.1
> sudo route add -net 230.0.0.0/8 192.168.1.0
> {noformat}
> This adds loopback as default mcast route, but uses en0 if a multicast address starts with 230.x.x.x.
--
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, 1 month
[JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1807?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1807.
----------------------------
Resolution: Done
> UNICAST: skipping of seqnos
> ---------------------------
>
> Key: JGRP-1807
> URL: https://issues.jboss.org/browse/JGRP-1807
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> {noformat}
> The log starts with:
> 10-Mar-2014 13:21:47 WARN [org.jgroups.protocols.UNICAST2] (OOB-105,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511786 not found in retransmission table of AS_DR_IBE06/web:
> [1511785 | 1511785 | 1511857] (53 elements, 19 missing)
> The numbers are 1511786-1511804 for "not found in retransmission...."
> And end:
> 10-Mar-2014 14:48:26 WARN [org.jgroups.protocols.UNICAST2] (OOB-118,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511804 not found in retransmission table of AS_DR_IBE06/web:
> [1511785 | 1511785 | 1514802] (2998 elements, 19 missing)
> {noformat}
> It seems that 03 is missing messages 1511785-1511804 which it sent to 06. Since a null message cannot be added to the sender table (due to the {{msg.isFlagSet()}} which would throw an NPE), I asume we're skipping a seqno:
> In {{UNICAST}}, {{UNICAST2}} and {{UNICAST3}} {{down()}}, if a seqno is skipped, we get endless retransmissions. Example:
> * We get the next seqno 1, add the message to the table and send it
> * We get the next seqno 2. However, if {{running}} is false, we don't add the message
> * We get the next seqno 3. Now {{running}} is true, and we add 3 to the table
> --> Now we have a missing message 2 which will always be null as it hasn't been added to the table
> This is highly unlikely, as I haven't been able to find a scenario where running flips from true to false to true quickly. If it flips from true to false, this is because {{stop()}} has been called. Also, in {{down()}}, we actually check {{running}} and return if false.
> In this scenario, the connections are all removed, so seqno is reset to 1.
> Anyway, I'm going to replace the {{while(running)}} loop with a {{do while(running)}} loop, so we always add the message to the table, even if running=false.
> [1] https://github.com/belaban/JGroups/blob/Branch_JGroups_3_2/src/org/jgroup...
--
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, 1 month
[JBoss JIRA] (JGRP-1792) "No buffer space available" when sending on Mac OS
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1792?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1792.
----------------------------
Resolution: Done
Doesn't occur anymore with JGRP-1765 in place, probably because we now use the DatagramSocket to send multicasts, not the MulticastSocket.
> "No buffer space available" when sending on Mac OS
> --------------------------------------------------
>
> Key: JGRP-1792
> URL: https://issues.jboss.org/browse/JGRP-1792
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> When sending multicast messages (with MPerf & fast.xml), the following message appears:
> {noformat}
> 8981 [ERROR] UDP: JGRP000029: A: failed sending message to cluster (1053 bytes): java.io.IOException: No buffer space available,
> headers: MPerf: DATA999, NAKACK2: [MSG, seqno=1003], UDP: [cluster_name=mperf]
> {noformat}
> The messages *are* received, but the error message occurs on almost every message (1 sender thread sending 1000 messages).
> With {{UdpPerf}} (also shipped with JGroups), which also multicasts messages, the error doesn't happen.
> With {{UPerf}}, which uses unicasts, the error doesn't occur either.
> Todo: compare UdpPerf to MPerf (UDP protocol) to see what the diff is.
--
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, 1 month
[JBoss JIRA] (JASSIST-219) Generic signature is lost after using ProxyFactory to enchant another class.
by Elis Edlund (JIRA)
[ https://issues.jboss.org/browse/JASSIST-219?page=com.atlassian.jira.plugi... ]
Elis Edlund updated JASSIST-219:
--------------------------------
Attachment: IssueMissingGenericTypeInfoForEnchantedClassTest.java
really simple class to reproduce the problem.
> Generic signature is lost after using ProxyFactory to enchant another class.
> ----------------------------------------------------------------------------
>
> Key: JASSIST-219
> URL: https://issues.jboss.org/browse/JASSIST-219
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA, 3.17.1-GA, 3.18.0-GA, 3.18.1-GA
> Environment: Windows 7
> java 1.5 1.6 1.7
> Reporter: Elis Edlund
> Assignee: Shigeru Chiba
> Labels: generics, missing
> Attachments: IssueMissingGenericTypeInfoForEnchantedClassTest.java
>
>
> Its not possible to get any generic information out of a class that have been 'enchanted' with ProxyFactory.
> example output before and after an 'enchantment' (produced with method.toGenericString())
> ------Enchant Object------
> stringMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getStringList()
> numberMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getNumberList()
> stringMethod sigature myObject : public java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getStringList()
> numberMethod sigature myObject : public java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getNumberList()
> ------Enchant Interface------
> stringMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getStringList()
> numberMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getNumberList()
> stringMethod sigature myInterface : public abstract java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getStringList()
> numberMethod sigature myInterface : public abstract java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getNumberList()
--
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, 1 month
[JBoss JIRA] (JASSIST-219) Generic signature is lost after using ProxyFactory to enchant another class.
by Elis Edlund (JIRA)
Elis Edlund created JASSIST-219:
-----------------------------------
Summary: Generic signature is lost after using ProxyFactory to enchant another class.
Key: JASSIST-219
URL: https://issues.jboss.org/browse/JASSIST-219
Project: Javassist
Issue Type: Bug
Affects Versions: 3.18.1-GA, 3.18.0-GA, 3.17.1-GA, 3.16.1-GA
Environment: Windows 7
java 1.5 1.6 1.7
Reporter: Elis Edlund
Assignee: Shigeru Chiba
Its not possible to get any generic information out of a class that have been 'enchanted' with ProxyFactory.
example output before and after an 'enchantment' (produced with method.toGenericString())
------Enchant Object------
stringMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getStringList()
numberMethod sigature enchantedObject: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject_$$_javassist_0.getNumberList()
stringMethod sigature myObject : public java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getStringList()
numberMethod sigature myObject : public java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyObject.getNumberList()
------Enchant Interface------
stringMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getStringList()
numberMethod sigature enchantedInterface: public final java.util.List IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface_$$_javassist_1.getNumberList()
stringMethod sigature myInterface : public abstract java.util.List<java.lang.String> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getStringList()
numberMethod sigature myInterface : public abstract java.util.List<? extends java.lang.Number> IssueMissingGenericTypeInfoForEnchantedClassTest$MyInterface.getNumberList()
--
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, 1 month
[JBoss JIRA] (JGRP-1807) UNICAST: skipping of seqnos
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1807?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1807:
--------------------------------
Same change for NAKACK2
> UNICAST: skipping of seqnos
> ---------------------------
>
> Key: JGRP-1807
> URL: https://issues.jboss.org/browse/JGRP-1807
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> {noformat}
> The log starts with:
> 10-Mar-2014 13:21:47 WARN [org.jgroups.protocols.UNICAST2] (OOB-105,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511786 not found in retransmission table of AS_DR_IBE06/web:
> [1511785 | 1511785 | 1511857] (53 elements, 19 missing)
> The numbers are 1511786-1511804 for "not found in retransmission...."
> And end:
> 10-Mar-2014 14:48:26 WARN [org.jgroups.protocols.UNICAST2] (OOB-118,shared=tcp) AS_DR_IBE03/web: (requester=AS_DR_IBE06/web) message AS_DR_IBE06/web::1511804 not found in retransmission table of AS_DR_IBE06/web:
> [1511785 | 1511785 | 1514802] (2998 elements, 19 missing)
> {noformat}
> It seems that 03 is missing messages 1511785-1511804 which it sent to 06. Since a null message cannot be added to the sender table (due to the {{msg.isFlagSet()}} which would throw an NPE), I asume we're skipping a seqno:
> In {{UNICAST}}, {{UNICAST2}} and {{UNICAST3}} {{down()}}, if a seqno is skipped, we get endless retransmissions. Example:
> * We get the next seqno 1, add the message to the table and send it
> * We get the next seqno 2. However, if {{running}} is false, we don't add the message
> * We get the next seqno 3. Now {{running}} is true, and we add 3 to the table
> --> Now we have a missing message 2 which will always be null as it hasn't been added to the table
> This is highly unlikely, as I haven't been able to find a scenario where running flips from true to false to true quickly. If it flips from true to false, this is because {{stop()}} has been called. Also, in {{down()}}, we actually check {{running}} and return if false.
> In this scenario, the connections are all removed, so seqno is reset to 1.
> Anyway, I'm going to replace the {{while(running)}} loop with a {{do while(running)}} loop, so we always add the message to the table, even if running=false.
> [1] https://github.com/belaban/JGroups/blob/Branch_JGroups_3_2/src/org/jgroup...
--
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, 1 month