July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1864) UDP unable to bind to ephemeral port: port out of range:65536

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/JGRP-1864?page=com.atlassian.jira.plugin.... ] Ion Savin commented on JGRP-1864: --------------------------------- This is sufficient to trigger the failure with JGroups on that machine: https://github.com/isavin/sample-ipv6-bind-fail/blob/master/src/main/java... Since the non-JGroups app fails (ping6 fails also) this is probably not related to JGroups. If I find anything which might be relevant to this issue I'll reopen / update it. Thanks for looking at this and sorry for the noise! > UDP unable to bind to ephemeral port: port out of range:65536 > ------------------------------------------------------------- > > Key: JGRP-1864 > URL: https://issues.jboss.org/browse/JGRP-1864 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.4.4 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4.5, 3.5 > > > It looks like {{UDP.createEphemeralDatagramSocket()}} swallows any errors it gets while creating the socket, and throws this exception after trying to bind to all ports in the 0 - 65535 range: > {noformat} > java.lang.IllegalArgumentException: port out of range:65536 > at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143) > at java.net.InetSocketAddress.<init>(InetSocketAddress.java:185) > at java.net.DatagramSocket.<init>(DatagramSocket.java:284) > at org.jgroups.util.DefaultSocketFactory.createDatagramSocket(DefaultSocketFactory.java:62) > at org.jgroups.protocols.UDP.createEphemeralDatagramSocket(UDP.java:429) > at org.jgroups.protocols.UDP.createSockets(UDP.java:311) > at org.jgroups.protocols.UDP.start(UDP.java:216) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966) > at org.jgroups.JChannel.startStack(JChannel.java:889) > at org.jgroups.JChannel._preConnect(JChannel.java:547) > at org.jgroups.JChannel.connect(JChannel.java:282) > at org.jgroups.JChannel.connect(JChannel.java:273) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:200) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-37) Audit Logging Integration

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-37: ----------------------------------- Summary: Audit Logging Integration Key: ELY-37 URL: https://issues.jboss.org/browse/ELY-37 Project: WildFly Elytron Issue Type: Task Security Level: Public (Everyone can see) Components: API / SPI, Audit Reporter: Darran Lofthouse Fix For: 1.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-36) Authentication Context Lifecycle

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-36: ----------------------------------- Summary: Authentication Context Lifecycle Key: ELY-36 URL: https://issues.jboss.org/browse/ELY-36 Project: WildFly Elytron Issue Type: Task Security Level: Public (Everyone can see) Components: API / SPI Reporter: Darran Lofthouse Fix For: 1.0.0.Beta1 The authentication context is used with a sequence of calls during the authentication process, this task is to look into how we can apply a lifecycle to that so that appropriate clean up can be performed. This could be closely related to ELY-35 which specifically looks at outcome notification. When considering a lifecycle I think we have two key events to think about, the most natural one being once the authentication process is complete regardless of outcome - however should also consider intermediate responses going back to the client - we do not want to be holding onto expensive resources once we pass control back to the client as that risks a Dos based attack. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-35) Notification of outcome from authentication mechanism through to realm.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-35: ----------------------------------- Summary: Notification of outcome from authentication mechanism through to realm. Key: ELY-35 URL: https://issues.jboss.org/browse/ELY-35 Project: WildFly Elytron Issue Type: Task Security Level: Public (Everyone can see) Components: API / SPI Reporter: Darran Lofthouse Fix For: 1.0.0.Beta1 Realm implementations may want to track successful / unsuccessful calls. Note: There may be a better way to consider this so do not take the title too literally. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-34) Create a JAAS based security realm.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-34: ----------------------------------- Summary: Create a JAAS based security realm. Key: ELY-34 URL: https://issues.jboss.org/browse/ELY-34 Project: WildFly Elytron Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Realms Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Beta1 Legacy integration is always going to be a concern so should verify that we can delegate to JAAS if required. _Delegating to JAAS is always going to simplify the password types supported so this is more of an ensure we can integrate with JAAS rather than ensure we can fully integrate with JAAS._ -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3638) Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3638?page=com.atlassian.jira.plugin.... ] Brian Stansberry edited comment on WFLY-3638 at 7/31/14 11:55 AM: ------------------------------------------------------------------ One last background comment... this test has a bunch of stuff related to letting arquillian provide a modular environment (actually starting a full server process), and then a full mock model controller etc is run inside that environment. My assumption is all that stuff about providing the environment remains in ParseAndMarshalModelsTestCase and the static utility methods will "just work", same as they do now. We don't allow an arquillian dependency in core, so we can't move any of that stuff into the utility. was (Author: brian.stansberry): One last background comment... this test has a bunch of stuff related to letting arquillian provide a modular environment (actually starting a full server process), and then a full mock model controller etc is run inside that environment. My assumption is all that stuff remains in ParseAndMarshalModelsTestCase and the static utility methods will "just work", same as they do now. We don't allow an arquillian dependency in core, so we can't move any of that stuff into the utility. > Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-3638 > URL: https://issues.jboss.org/browse/WFLY-3638 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 9.0.0.Beta1 > > > ServerRootResourceDefinition constructor and CoreManagementResourceDefinition static methods have been deprecated. > Replace their use with the new methods with the BootErrorCollector parameter. > This can be done with core 1.0.0.Alpha4. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3638) Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3638?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-3638: ---------------------------------------- One last background comment... this test has a bunch of stuff related to letting arquillian provide a modular environment (actually starting a full server process), and then a full mock model controller etc is run inside that environment. My assumption is all that stuff remains in ParseAndMarshalModelsTestCase and the static utility methods will "just work", same as they do now. We don't allow an arquillian dependency in core, so we can't move any of that stuff into the utility. > Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-3638 > URL: https://issues.jboss.org/browse/WFLY-3638 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 9.0.0.Beta1 > > > ServerRootResourceDefinition constructor and CoreManagementResourceDefinition static methods have been deprecated. > Replace their use with the new methods with the BootErrorCollector parameter. > This can be done with core 1.0.0.Alpha4. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3638) Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3638?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-3638: ---------------------------------------- The standaloneXmlTest, domainXmlTest and hostXmlTest methods can all be made static and provided by a utility class in wildfly-core/testsuite-core/shared. So lets add that, @Ignore this test, replace the current methods with those names with methods that throw UnsupportedOperationException, rip out all the code those current methods call, and then when we integrate the wildfly-core version with the new utility, replace the unsupported methods with calls to the utility and un-@Ignore the test. > Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-3638 > URL: https://issues.jboss.org/browse/WFLY-3638 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 9.0.0.Beta1 > > > ServerRootResourceDefinition constructor and CoreManagementResourceDefinition static methods have been deprecated. > Replace their use with the new methods with the BootErrorCollector parameter. > This can be done with core 1.0.0.Alpha4. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3638) Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3638?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-3638: ---------------------------------------- I believe this is all about ParseAndMarshalModelsTestCase. I'm finding another conflict in this class with some other changes I'm making in core. So instead of just changing this signature, we need to change this class so it does not rely on so many wildfly-core internals. Expose something simple in wildfly-core/testsuite-core/shared that tests like this can simply call. > Remove use of deprecated methods from CoreManagementResourceDefinition and ServerRootResourceDefinition > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-3638 > URL: https://issues.jboss.org/browse/WFLY-3638 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 9.0.0.Beta1 > > > ServerRootResourceDefinition constructor and CoreManagementResourceDefinition static methods have been deprecated. > Replace their use with the new methods with the BootErrorCollector parameter. > This can be done with core 1.0.0.Alpha4. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3698) Could not inject persistence unit into CDI managed bean

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-3698?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-3698: ------------------------------------ probably would be better to ask questions like this on the wildfly forums. Anyway, I would enable TRACE logging for JPA to get more insight on why the persistence unit wasn't found. [Read this link for help in getting that going |https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPAReferenceGuide-Troubleshooting] Also try the WildFly 9 nightly build, in case that helps (https://community.jboss.org/thread/224262). > Could not inject persistence unit into CDI managed bean > ------------------------------------------------------- > > Key: WFLY-3698 > URL: https://issues.jboss.org/browse/WFLY-3698 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: CDI / Weld, JPA / Hibernate > Affects Versions: 8.1.0.Final > Environment: Windows 8.1 64 bits, Notebook Lenovo Z570 Intel Core i7 (2nd Gen) 2670QM / 2.2 GHz , 8GB RAM, using Eclipse Luna to develop > Reporter: Oscar Calderon > Assignee: Stuart Douglas > Original Estimate: 1 week > Remaining Estimate: 1 week > > I have a project running Spring 4 & JSF 2.1 using Primefaces 5 and Hibernate JPA 2.0. I use Wildfly 8.1 and configured a datasource pointing to an Oracle 10 database. The Wildfly datasource works fine (i've tested using plain JDBC) but when i try to create a LocalContainerEntityManagerFactoryBean through Spring i set the property persistenceUnitName to specify the name of my PU and then injecting in my DAOs using @PersistenceContext(unitName="myPersUnit"). > Using JBoss AS 7.1.1 Final works fine and even i don't need to specify persistenceUnitName and it creates as "default" and injects it to my DAOs without specifying name, but with JBoss 8.1 Final it doesn't work. With the same configuration, it shows me the next error: > Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named persUnit in deployment > But, when i remove the @PersistenceContext annotation from my property in my DAO, strangely it initializes the persistenceUnit as i can see in server log: > 08:19:57,144 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-13) HHH000204: Processing PersistenceUnitInfo [ > name: persUnit > ...] > But when i try to inject it, it doesn't -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 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 July 2014