October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2198) Remote Naming throws the same exception for different causes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2198: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1014414 > Remote Naming throws the same exception for different causes > ------------------------------------------------------------ > > Key: WFLY-2198 > URL: https://issues.jboss.org/browse/WFLY-2198 > Project: WildFly > Issue Type: Bug > Components: Naming > Reporter: Brad Maxwell > Assignee: Brad Maxwell > > A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported. > We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. > If all the the servers specified are not not running: > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) > If one of the servers is running, but the client's username/password are incorrect > -------------------------------------------------------------------------------------------- > javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2198) Remote Naming throws the same exception for different causes

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-2198: ---------------------------------- Summary: Remote Naming throws the same exception for different causes Key: WFLY-2198 URL: https://issues.jboss.org/browse/WFLY-2198 Project: WildFly Issue Type: Bug Components: Naming Reporter: Brad Maxwell Assignee: Brad Maxwell A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported. We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. If all the the servers specified are not not running: -------------------------------------------------------------------------------------------- javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) If one of the servers is running, but the client's username/password are incorrect -------------------------------------------------------------------------------------------- javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447] at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213) -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2190) Priviledge alignment for scoped resources

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2190?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-2190: ----------------------------------- Parent: WFLY-490 Issue Type: Sub-task (was: Enhancement) > Priviledge alignment for scoped resources > ----------------------------------------- > > Key: WFLY-2190 > URL: https://issues.jboss.org/browse/WFLY-2190 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Heiko Braun > Assignee: Brian Stansberry > Fix For: 8.0.0.CR1 > > > server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges. > Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}? -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-194) Add support in KIE to register custom Wagons

by Kurt Stam (JIRA)

[ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin... ] Kurt Stam commented on DROOLS-194: ---------------------------------- Hi Mario, 1. We store the kieJars in our S-RAMP repository (instead of maven). 2. Now when KIE wants to read this kiejar (https://github.com/Governance/dtgov/blob/master/dtgov-war/src/main/java/o...) we register the sramp Wagon extension: <code> Extension extension = new Extension(); extension.setArtifactId("s-ramp-wagon"); //$NON-NLS-1$ extension.setGroupId("org.overlord.sramp"); //$NON-NLS-1$ extension.setVersion(wagonVersion); build.addExtension(extension); project.setBuild(build); </code> So this registers the sramp protocol. The issue is that in your Aether class you don't honor this custom protocol. So to fix this we added <code> @Override public Wagon lookup( String roleHint ) throws Exception { if ( "http".equals( roleHint ) ) { //$NON-NLS-1$ return new AhcWagon(); } if ( "sramp".equals( roleHint ) ) { //$NON-NLS-1$ return new SrampWagonProxy(); } return null; } </code> However it should be possible to have it figure this out byitself; or at least one should be able to add Wagon by way of configuration. I'm going to add a test for it using something like the FileWagon so you don't need a running S-RAMP server. > Add support in KIE to register custom Wagons > -------------------------------------------- > > Key: DROOLS-194 > URL: https://issues.jboss.org/browse/DROOLS-194 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kurt Stam > Assignee: Mark Proctor > > The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code: > {quote} > private static class ManualWagonProvider implements WagonProvider { > public Wagon lookup( String roleHint ) throws Exception { > if ( "http".equals( roleHint ) ) { > return new AhcWagon(); > } > if ( "sramp".equals( roleHint ) ) { > return new SrampWagon(); > } > return null; > } > public void release( Wagon wagon ) { } > } > {quote} -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-194) Add support in KIE to register custom Wagons

by Kurt Stam (JIRA)

[ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin... ] Kurt Stam edited comment on DROOLS-194 at 10/1/13 4:31 PM: ----------------------------------------------------------- Hi Mario, 1. We store the kieJars in our S-RAMP repository (instead of maven). 2. Now when KIE wants to read this kiejar (https://github.com/Governance/dtgov/blob/master/dtgov-war/src/main/java/o...) we register the sramp Wagon extension: {code:java} Extension extension = new Extension(); extension.setArtifactId("s-ramp-wagon"); //$NON-NLS-1$ extension.setGroupId("org.overlord.sramp"); //$NON-NLS-1$ extension.setVersion(wagonVersion); build.addExtension(extension); project.setBuild(build); {code:} So this registers the sramp protocol. The issue is that in your Aether class you don't honor this custom protocol. So to fix this we added {code:java} @Override public Wagon lookup( String roleHint ) throws Exception { if ( "http".equals( roleHint ) ) { //$NON-NLS-1$ return new AhcWagon(); } if ( "sramp".equals( roleHint ) ) { //$NON-NLS-1$ return new SrampWagonProxy(); } return null; } {code} However it should be possible to have it figure this out byitself; or at least one should be able to add Wagon by way of configuration. I'm going to add a test for it using something like the FileWagon so you don't need a running S-RAMP server. was (Author: kurtstam): Hi Mario, 1. We store the kieJars in our S-RAMP repository (instead of maven). 2. Now when KIE wants to read this kiejar (https://github.com/Governance/dtgov/blob/master/dtgov-war/src/main/java/o...) we register the sramp Wagon extension: <code> Extension extension = new Extension(); extension.setArtifactId("s-ramp-wagon"); //$NON-NLS-1$ extension.setGroupId("org.overlord.sramp"); //$NON-NLS-1$ extension.setVersion(wagonVersion); build.addExtension(extension); project.setBuild(build); </code> So this registers the sramp protocol. The issue is that in your Aether class you don't honor this custom protocol. So to fix this we added <code> @Override public Wagon lookup( String roleHint ) throws Exception { if ( "http".equals( roleHint ) ) { //$NON-NLS-1$ return new AhcWagon(); } if ( "sramp".equals( roleHint ) ) { //$NON-NLS-1$ return new SrampWagonProxy(); } return null; } </code> However it should be possible to have it figure this out byitself; or at least one should be able to add Wagon by way of configuration. I'm going to add a test for it using something like the FileWagon so you don't need a running S-RAMP server. > Add support in KIE to register custom Wagons > -------------------------------------------- > > Key: DROOLS-194 > URL: https://issues.jboss.org/browse/DROOLS-194 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kurt Stam > Assignee: Mark Proctor > > The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code: > {quote} > private static class ManualWagonProvider implements WagonProvider { > public Wagon lookup( String roleHint ) throws Exception { > if ( "http".equals( roleHint ) ) { > return new AhcWagon(); > } > if ( "sramp".equals( roleHint ) ) { > return new SrampWagon(); > } > return null; > } > public void release( Wagon wagon ) { } > } > {quote} -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2197) ClientCompatibilityUnitTestCase is broken in an IPv6 environment

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-2197: -------------------------------------- Summary: ClientCompatibilityUnitTestCase is broken in an IPv6 environment Key: WFLY-2197 URL: https://issues.jboss.org/browse/WFLY-2197 Project: WildFly Issue Type: Bug Components: Domain Management, Test Suite Affects Versions: 8.0.0.Alpha4 Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 8.0.0.Beta1 ClientCompatibilityUnitTestCase has "localhost" hard coded as the address it tries to connect to. This fails when IPv6 is configured for testsuite runs, as the server is not listening on 127.0.0.1 but rather ::1. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2196) add x-forwarded-* headers support

by Michał Zegan (JIRA)

Michał Zegan created WFLY-2196: ---------------------------------- Summary: add x-forwarded-* headers support Key: WFLY-2196 URL: https://issues.jboss.org/browse/WFLY-2196 Project: WildFly Issue Type: Feature Request Reporter: Michał Zegan Priority: Minor Hello. If it is desirable, can you add the possibility for wildfly/undertow subsystem to retrieve x-forwarded-host and similar headers and set a remote ip address and hostname based on it? This header is set by proxy servers to indicate proxies this request has passed and to indicate the client's real ip address. It's extremely useful if an application checks and uses the hostname or ip of a client that connects to it. In the case of wildfly directly open to the public, the ip and host given will be that of a client, but if the server where an application is running is just a backend server and there is a frontend before it that proxies to it, the ip and host will be that of the proxy, often localhost if the proxy sits on the same machine, that is undesirable because you don't want to ip-ban a proxy. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2193) Upgrade javax.json to version 1.0.3

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.... ] Shelly McGowan updated WFLY-2193: --------------------------------- Fix Version/s: 8.0.0.Beta1 (was: 8.0.0.CR1) > Upgrade javax.json to version 1.0.3 > ----------------------------------- > > Key: WFLY-2193 > URL: https://issues.jboss.org/browse/WFLY-2193 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: 8.0.0.Beta1 > > > WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2193) Upgrade javax.json to version 1.0.3

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.... ] Shelly McGowan resolved WFLY-2193. ---------------------------------- Resolution: Done The pull request has been merged. Resolving. > Upgrade javax.json to version 1.0.3 > ----------------------------------- > > Key: WFLY-2193 > URL: https://issues.jboss.org/browse/WFLY-2193 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: 8.0.0.Beta1 > > > WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2195) add defensive check against EntityManagerFactory/EntityManager already being closed by ill-behaved deployment

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2195?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-2195: ------------------------------------ This is needed for the entityManagerFactoryCloseExceptions tck test. > add defensive check against EntityManagerFactory/EntityManager already being closed by ill-behaved deployment > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-2195 > URL: https://issues.jboss.org/browse/WFLY-2195 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 8.0.0.CR1 > > > When closing container managed entity manager or entity manager factory, check if the entity manager factory was already closed unexpectedly. -- 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, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2013