April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3203) Inconsistent handling of @Resource for URL in EJB vs JSF managed bean

by Scott Stark (JIRA)

Scott Stark created WFLY-3203: --------------------------------- Summary: Inconsistent handling of @Resource for URL in EJB vs JSF managed bean Key: WFLY-3203 URL: https://issues.jboss.org/browse/WFLY-3203 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: EJB, JSF Affects Versions: 8.0.0.Final Environment: [standalone 526]$ /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) Reporter: Scott Stark Assignee: David Lloyd Given a set of simple jndi bindings like the following: <subsystem xmlns="urn:jboss:domain:naming:2.0"> <bindings> <simple name="java:global/NSPDomain" value="domain" type="java.lang.String"/> <simple name="java:global/NSPURL" value="http://red-hat-summit.cloudapp.net:8081/" type="java.net.URL"/> <simple name="java:global/NotificationCallbackURL" value="http://dmz.starkinternational.com:8080/iotbof-web/rest/events/send" type="java.net.URL"/> </bindings> <remote-naming/> </subsystem> The following works from an EJB: import javax.ejb.Singleton; import javax.ejb.Startup; @Singleton @Startup public class NSPConnector { ... @Resource(name = "java:global/NotificationCallbackURL") private URL notificationURL; but fails with a NameNotFoundException when used from within a JSF managed bean. import javax.enterprise.context.ApplicationScoped; import javax.inject.Named; @Named("nspmodel") @ApplicationScoped public class NSPModel { private static Logger logger = Logger.getLogger(NSPModel.class); @Resource(name = "java:global/NotificationCallbackURL") private URL notificationURL; Has the following error when accessed: Caused by: javax.naming.NameNotFoundException: env/java:global/NotificationCallbackURL -- service jboss.naming.context.java.module.iot-ear.iotbof-web.env.java:global.NotificationCallbackURL at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:104) [wildfly-naming-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-8.0.0.Final.jar:8.0.0.Final] at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-8.0.0.Final.jar:8.0.0.Final] at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0] at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0] at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185) [wildfly-weld-8.0.0.Final.jar:8.0.0.Final] ... 71 more -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3200) Support Jackson 2 out of the box

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3200?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3200: ------------------------------ Fix Version/s: 9.0.0.CR1 > Support Jackson 2 out of the box > -------------------------------- > > Key: WFLY-3200 > URL: https://issues.jboss.org/browse/WFLY-3200 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: REST > Affects Versions: 8.0.0.Final > Reporter: Nathaniel A. Johnson > Assignee: Stuart Douglas > Priority: Minor > Fix For: 9.0.0.CR1 > > > Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following: > {code:xml} > <jboss-deployment-structure> > <deployment> > <exclusions> > <module name="org.jboss.resteasy.resteasy-jackson-provider"/> > </exclusions> > <dependencies> > <module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/> > </dependencies> > </deployment> > </jboss-deployment-structure> > {code} > It would be better if Jackson 2 were the default provider and this were not necessary. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3202) Research behavior of fork with ProcessBuilder on modern JVMs

by David Lloyd (JIRA)

David Lloyd created WFLY-3202: --------------------------------- Summary: Research behavior of fork with ProcessBuilder on modern JVMs Key: WFLY-3202 URL: https://issues.jboss.org/browse/WFLY-3202 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Right now our Process Controller exists for two primary reasons: # fork() misbehaves for large processes on some OSes, causing leaks or crashes # if the HC crashes, the PC can respawn it We have never (afaik) seen #2 happen. We need to verify whether #1 is still true on modern JVMs on the following operating systems: * Linux * Solaris * IBM OSes * Windows * BSDs * Mac OS X Test by creating processes with large heap and lots of concurrent file descriptor activity while forking to see what happens. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3201) Channel end notification received, closing channel ... should be logged at debug

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-3201: ---------------------------------- Summary: Channel end notification received, closing channel ... should be logged at debug Key: WFLY-3201 URL: https://issues.jboss.org/browse/WFLY-3201 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Naming Reporter: Brad Maxwell Assignee: Brad Maxwell Remote naming is logging this at ERROR, though it seems normal and no adverse effects are apparent, we should log it at debug instead of error. ERROR Channel end notification received, closing channel Channel ID b8e969d6 (outbound) of Remoting connection 4970f4db to ... -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2881) org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2881?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-2881: ------------------------------- Priority: Blocker (was: Major) > org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout > -------------------------------------------------------------------------------------- > > Key: WFLY-2881 > URL: https://issues.jboss.org/browse/WFLY-2881 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Frank Langelage > Assignee: Eduardo Martins > Priority: Blocker > Fix For: 8.0.1.Final > > Attachments: org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.txt, TEST-org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.xml > > > Running build with smoke tests on current github sources I get failure in this test case. > HOUR_OF_DAY is not 0 as expected but 1. > I changed the Assert in the test case to print out firstTimeout.toString() instead of only timeZoneDisplayName. > See attached files for more. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3200) Support Jackson 2 out of the box

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3200?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3200: ------------------------------ Affects Version/s: 8.0.0.Final > Support Jackson 2 out of the box > -------------------------------- > > Key: WFLY-3200 > URL: https://issues.jboss.org/browse/WFLY-3200 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: REST > Affects Versions: 8.0.0.Final > Reporter: Nathaniel A. Johnson > Assignee: Stuart Douglas > Priority: Minor > > Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following: > <jboss-deployment-structure> > <deployment> > <exclusions> > <module name="org.jboss.resteasy.resteasy-jackson-provider"/> > </exclusions> > <dependencies> > <module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/> > </dependencies> > </deployment> > </jboss-deployment-structure> > It would be better if Jackson 2 were the default provider and this were not necessary. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3200) Support Jackson 2 out of the box

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3200?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3200: ------------------------------ Description: Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following: {code:xml} <jboss-deployment-structure> <deployment> <exclusions> <module name="org.jboss.resteasy.resteasy-jackson-provider"/> </exclusions> <dependencies> <module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/> </dependencies> </deployment> </jboss-deployment-structure> {code} It would be better if Jackson 2 were the default provider and this were not necessary. was: Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following: <jboss-deployment-structure> <deployment> <exclusions> <module name="org.jboss.resteasy.resteasy-jackson-provider"/> </exclusions> <dependencies> <module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/> </dependencies> </deployment> </jboss-deployment-structure> It would be better if Jackson 2 were the default provider and this were not necessary. > Support Jackson 2 out of the box > -------------------------------- > > Key: WFLY-3200 > URL: https://issues.jboss.org/browse/WFLY-3200 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: REST > Affects Versions: 8.0.0.Final > Reporter: Nathaniel A. Johnson > Assignee: Stuart Douglas > Priority: Minor > > Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following: > {code:xml} > <jboss-deployment-structure> > <deployment> > <exclusions> > <module name="org.jboss.resteasy.resteasy-jackson-provider"/> > </exclusions> > <dependencies> > <module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/> > </dependencies> > </deployment> > </jboss-deployment-structure> > {code} > It would be better if Jackson 2 were the default provider and this were not necessary. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3193) upgrade Generic JMS RA to 1.0.4.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3193?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3193: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1082617|https://bugzilla.redhat.com/show_bug.cgi?id=1082617] from POST to MODIFIED > upgrade Generic JMS RA to 1.0.4.Final > ------------------------------------- > > Key: WFLY-3193 > URL: https://issues.jboss.org/browse/WFLY-3193 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: JCA, JMS > Affects Versions: 8.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.1.Final > > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ] Darran Lofthouse updated SECURITY-815: -------------------------------------- Fix Version/s: Negotiation_2_3_0_Final > NegotiationAuthenticator loses post data > ---------------------------------------- > > Key: SECURITY-815 > URL: https://issues.jboss.org/browse/SECURITY-815 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_0_Final > > > The NegotiationAuthenticator loses post data. > A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding. > If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL. > If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ] Derek Horton updated SECURITY-815: ---------------------------------- Git Pull Request: https://github.com/wildfly/jboss-negotiation/pull/3 > NegotiationAuthenticator loses post data > ---------------------------------------- > > Key: SECURITY-815 > URL: https://issues.jboss.org/browse/SECURITY-815 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Darran Lofthouse > > The NegotiationAuthenticator loses post data. > A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding. > If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL. > If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page. -- 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, 3 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 April 2014