March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3179) Dynamic Deployment of Security Domain

by shinzey shinzey (JIRA)

shinzey shinzey created WFLY-3179: ------------------------------------- Summary: Dynamic Deployment of Security Domain Key: WFLY-3179 URL: https://issues.jboss.org/browse/WFLY-3179 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Security Affects Versions: 8.0.0.Final Environment: WildFly 8.0.0.Final Reporter: shinzey shinzey Assignee: Darran Lofthouse In JBoss 6, security domains can be dynamically deployed using jboss-beans.xml, which is not working in WildFly 8. It would be quite useful to bring back this feature, so that no manual operations or extra scripts are needed to create security domains during application deployment. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3178) Update Remoting to 4.0.3.Final

by David Lloyd (JIRA)

David Lloyd created WFLY-3178: --------------------------------- Summary: Update Remoting to 4.0.3.Final Key: WFLY-3178 URL: https://issues.jboss.org/browse/WFLY-3178 Project: WildFly Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Remoting Reporter: David Lloyd Assignee: David Lloyd Priority: Blocker Fix For: 8.0.1.Final This update prevents a potentially nasty spin loop (REM3-186). -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1797: ----------------------------------------------- Richard Achmatowicz <rachmato(a)redhat.com> changed the Status of [bug 927966|https://bugzilla.redhat.com/show_bug.cgi?id=927966] from NEW to ON_QA > NakackTest testReceptionOfAllMessages fails to receive all messages > ------------------------------------------------------------------- > > Key: JGRP-1797 > URL: https://issues.jboss.org/browse/JGRP-1797 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions. > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.2.13 > > Attachments: stdout.txt > > > This test does the following: > - involves channels A, B, and C where only B and C are senders and all are receivers > - B and C send 1000 multicast messages > - checks that all messages are received and in the correct order > This test is failing intermittently but quite often. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols configured with plain text passwords

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1721: -------------------------------- I'm going to close this as the keystore name and password can be injected programmatically > AUTH and ENCRYPT protocols configured with plain text passwords > --------------------------------------------------------------- > > Key: JGRP-1721 > URL: https://issues.jboss.org/browse/JGRP-1721 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4 > Reporter: Martin Gencur > Assignee: Bela Ban > Fix For: 3.5 > > > The following parameters of AUTH protocol are stored as plain text: > * keystore_password > The following parameters of ENCRYPT protocol are stored as plain text: > * store_password > * key_password > Example: > {code} > <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/> > {code} > Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3105) Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-3105: ------------------------------------ And for verifying the fix as well! :) > Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-3105 > URL: https://issues.jboss.org/browse/WFLY-3105 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: 8.0.0.Final > Reporter: Christian Bauer > Assignee: Scott Marlow > Fix For: 8.0.1.Final > > > https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/s... > Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. > Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3105) Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3105?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-3105. ------------------------------ Thanks for reporting this Christian! > Container-managed EXTENDED persistence context is always joined with transaction even if UNSYNCHRONIZED > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-3105 > URL: https://issues.jboss.org/browse/WFLY-3105 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: 8.0.0.Final > Reporter: Christian Bauer > Assignee: Scott Marlow > Fix For: 8.0.1.Final > > > https://github.com/weld/wildfly/blob/master/testsuite/integration/basic/s... > Change this test to {code}@PersistenceContext(type = EXTENDED, synchronization = UNSYNCHRONIZED){code} and it will break. > Looks like an extended PC is always joined to the transaction and flushed on commit, the unsynchronized mode is ignored. From what I can see this is not specified and indeed would make the whole new UNSYNCHRONIZED feature kind of pointless. It's primary use case is propagation of unflushed/unsynchronized extended PC from a SFSB to other beans while keeping transactions intact. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1815) TP: sending a message to a non-existent physical address takes too much time

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1815?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1815. ---------------------------- Resolution: Done > TP: sending a message to a non-existent physical address takes too much time > ---------------------------------------------------------------------------- > > Key: JGRP-1815 > URL: https://issues.jboss.org/browse/JGRP-1815 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > When sending a message in the transport, e.g. a message batch, and one or more destinations have no physical addresses in {{logical_addr_cache}}, then we loop {{physical_addr_max_fetch_attempts}} (default: 3) times and also sleep a random number of ms (in range [1..500]). > This delays the sending of other messages in the same batch, or of other messages in general. Also, if TransferQueueBundler is used, the transfer queue might get filled, so other sender threads are blocked. > SOLUTION: > * Remove the loop when sending a message: if the physical address for a message is not found, simply send a discovery request and drop the message > * The discovery request needs to be sent on a separate thread, as calling {{up(Event)}} directly could also delay the sending of the message or message batch. > * JGRP-1814 will also help, as connections to left members are closed, and therefore not finding a physical address for a destination should be rare -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1814) No physical address for X; dropping message

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1814?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1814. ---------------------------- Resolution: Done > No physical address for X; dropping message > ------------------------------------------- > > Key: JGRP-1814 > URL: https://issues.jboss.org/browse/JGRP-1814 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > When we have view \{A,B\} and B leaves, then the following happens in UNICAST3: > * B sends a LEAVE-REQ to A > * A sends a LEAVE-RSP to B > * Because the LEAVE-RSP is reliable, A keeps sending the LEAVE-RSP to B until it receives an ACK for the LEAVE-RSP > * However, when B receives the LEAVE-RSP, it marks its connection to be acked, which means that when the next retransmission kicks in, an ACK for the LEAVE-RSP will be sent back to A > * Before this happens, B leaves: the ACK is never sent to A > * A keeps resending the LEAVE-RSP until {{max_retransmit_time}} (default=60s) elapses and the connection is closed. However, the connection is only closed after another 60s (default for {{conn_close_timeout}}). > * Because the reaper removes all entries of {{logical_addr_cache}} before that happens, we're seeing the above warnings > SOLUTION: > # Send LEAVE-RSP unreliable. This bypasses UNICAST3 altogether. The leaver won't block forever if the LEAVE-RSP message is dropped, but only for 3 x {{GMS.leave_timeout}} ms > # Also add a MBR_LEFT event which is sent up and down the stack by GMS when a member left *gracefully*. This allows UNICAST3 to close the connection to a given member *immediately*, stopping unneeded retransmissions to members which left. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3114) @Resource(lookup="java:...") causes an exception for URL resources

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3114?page=com.atlassian.jira.plugin.... ] Eduardo Martins closed WFLY-3114. --------------------------------- Assignee: Eduardo Martins Resolution: Out of Date > @Resource(lookup="java:...") causes an exception for URL resources > ------------------------------------------------------------------- > > Key: WFLY-3114 > URL: https://issues.jboss.org/browse/WFLY-3114 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Thomas Kriechbaum > Assignee: Eduardo Martins > > When referencing an URL resource via @Resource the lookup-property only supports a valid URLs (e.g. http://www.jboss.org). A JNDI-Name causes an exception (e.g. java:global/url/Configuration or java:app/url/Configuration) > Issue has been discussed in the user form. > Note: > @Resource(name="java:global/url/Configuration") works. > From my point of view, the javadoc of @Resource is not very easy to understand. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3115) JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3115?page=com.atlassian.jira.plugin.... ] Eduardo Martins closed WFLY-3115. --------------------------------- Assignee: Eduardo Martins Resolution: Out of Date > JNDI-Names should be supported in jboss-specific deployment descriptors for URL resources > ----------------------------------------------------------------------------------------- > > Key: WFLY-3115 > URL: https://issues.jboss.org/browse/WFLY-3115 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Thomas Kriechbaum > Assignee: Eduardo Martins > > When using URL-Resources it would be very helpful, if the jboss-specific deployment descriptor (e.g. jboss-web.xml or jboss-app.xml) allows to reference a JNDI-name. At the moment, only valid URLs are supported. > When defining JNDI-names (e.g. java:jboss/url/Configuration) instead of concrete URLs, the EAR must not be adopted for each deployment as the specific URL is part of the server configuration (e.g. standalone.xml). > see proposal by [~sfcoy] at https://community.jboss.org/message/861952#861952 -- 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, 2 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 March 2014