August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3787) Add apache.cxf:cxf-rt-transports-http-hc to cxf impl module

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/WFLY-3787?page=com.atlassian.jira.plugin.... ] Jim Ma updated WFLY-3787: ------------------------- Description: Add this dependency to enable > Add apache.cxf:cxf-rt-transports-http-hc to cxf impl module > ----------------------------------------------------------- > > Key: WFLY-3787 > URL: https://issues.jboss.org/browse/WFLY-3787 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.1.0.Final > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 9.0.0.Final > > > Add this dependency to enable -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3787) Add apache.cxf:cxf-rt-transports-http-hc to cxf impl module

by Jim Ma (JIRA)

Jim Ma created WFLY-3787: ---------------------------- Summary: Add apache.cxf:cxf-rt-transports-http-hc to cxf impl module Key: WFLY-3787 URL: https://issues.jboss.org/browse/WFLY-3787 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 8.1.0.Final Reporter: Jim Ma Assignee: Jim Ma Fix For: 9.0.0.Final -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3782) add-user.sh actually does not honor JBOSS_BASE_DIR

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFLY-3782?page=com.atlassian.jira.plugin.... ] Claudio Miranda commented on WFLY-3782: --------------------------------------- You can use -sc option. The help says "Define the location the server config directory." Sample: ./add-user.sh -u admin -p admin123@ -sc /jboss_domains/domain1/configuration/ > add-user.sh actually does not honor JBOSS_BASE_DIR > -------------------------------------------------- > > Key: WFLY-3782 > URL: https://issues.jboss.org/browse/WFLY-3782 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Scripts > Affects Versions: 8.1.0.Final > Environment: linux > Reporter: David Tonhofer > Assignee: Darran Lofthouse > Fix For: Awaiting Volunteers > > > add-user.sh does not check whether the JBOSS_BASE_DIR points to another directory that the one which can be deduced from JBOSS_HOME assuming the default installation. This may not be what one wants, as one actually wants to update files: > JBOSS_BASE_DIR/configuration/mgmt-users.properties' > JBOSS_BASE_DIR/configuration/mgmt-users.properties' > instead of > JBOSS_HOME/standalone/configuration/mgmt-users.properties' > JBOSS_HOME/standalone/configuration/mgmt-users.properties' -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3786) Validator interceptor does not work in 8.1 on EJBs

by John Ament (JIRA)

John Ament created WFLY-3786: -------------------------------- Summary: Validator interceptor does not work in 8.1 on EJBs Key: WFLY-3786 URL: https://issues.jboss.org/browse/WFLY-3786 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 8.1.0.Final Reporter: John Ament Assignee: Jason Greene Take a look at the following git repo https://github.com/johnament/hornetq-jms-issue Run the test ValidationTest. When you execute, you'll see the following error: Caused by: org.jboss.arquillian.test.spi.ArquillianProxyException: org.jboss.weld.exceptions.IllegalArgumentException : WELD-001456: Argument bean must not be null [Proxied because : Original exception caused: class java.lang.ClassNotFoundException: org.jboss.weld.exceptions.IllegalArgumentException] Looking at it at first, you might think it's the result of validation execution (since the bean's @notNull). What's actually happening is the interceptor is trying to get a reference to the validator and failing, hence the "argument bean must not be null" part. It seems like the validation extension doesn't get activated properly when I'm dealing with a JAR within a WAR file. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3758) Unable to run JSF applications deployed to "/"

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3758?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-3758: ------------------------------------ Assignee: Stuart Douglas (was: Tomaz Cerar) > Unable to run JSF applications deployed to "/" > ----------------------------------------------- > > Key: WFLY-3758 > URL: https://issues.jboss.org/browse/WFLY-3758 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF, Web (Undertow) > Affects Versions: 9.0.0.Beta1 > Environment: WildFly master at 50a830205c, JDK 1.7 > Reporter: Ken H > Assignee: Stuart Douglas > > I don't think the patch in pull request 6338 is right. I experienced the issue defined in WLFY-3448 on 8.1.0.Final, then built master at 50a830205c and the new behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x). > From web.xml: > {code} > <welcome-file-list> > <welcome-file>/</welcome-file> > </welcome-file-list> > {code} > From jboss-web.xml: > {code} > <jboss-web> > <context-root>/</context-root> > </jboss-web> > {code} > My app is packaged as a war, so no application.xml exists to define context-root. > I would say this is a regression caused by the resolution to WLFY-3448 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3758) Unable to run JSF applications deployed to "/"

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3758?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3758: -------------------------------------- This will be fixed in Undertow 1.1.0.Beta7 > Unable to run JSF applications deployed to "/" > ----------------------------------------------- > > Key: WFLY-3758 > URL: https://issues.jboss.org/browse/WFLY-3758 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF, Web (Undertow) > Affects Versions: 9.0.0.Beta1 > Environment: WildFly master at 50a830205c, JDK 1.7 > Reporter: Ken H > Assignee: Stuart Douglas > > I don't think the patch in pull request 6338 is right. I experienced the issue defined in WLFY-3448 on 8.1.0.Final, then built master at 50a830205c and the new behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x). > From web.xml: > {code} > <welcome-file-list> > <welcome-file>/</welcome-file> > </welcome-file-list> > {code} > From jboss-web.xml: > {code} > <jboss-web> > <context-root>/</context-root> > </jboss-web> > {code} > My app is packaged as a war, so no application.xml exists to define context-root. > I would say this is a regression caused by the resolution to WLFY-3448 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ] Ron Sigal commented on WFLY-2859: --------------------------------- Thanks, Stuart. I'm just looking for things to close. > Treating all JAX-RS components as CDI Beans has some negative consequences > -------------------------------------------------------------------------- > > Key: WFLY-2859 > URL: https://issues.jboss.org/browse/WFLY-2859 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld, REST > Affects Versions: 8.0.0.CR1 > Reporter: Matt Drees > Assignee: Stuart Douglas > > It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class. > See the forum link for a specific instance of this. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-2859: -------------------------------------- AFAIK my proposed patch is ok, but I have not had time to do any sort of extensive testing (i.e. run the WF test suite with a patched resteasy) > Treating all JAX-RS components as CDI Beans has some negative consequences > -------------------------------------------------------------------------- > > Key: WFLY-2859 > URL: https://issues.jboss.org/browse/WFLY-2859 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld, REST > Affects Versions: 8.0.0.CR1 > Reporter: Matt Drees > Assignee: Stuart Douglas > > It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class. > See the forum link for a specific instance of this. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ] Ron Sigal commented on WFLY-2859: --------------------------------- Any progress on this? > Treating all JAX-RS components as CDI Beans has some negative consequences > -------------------------------------------------------------------------- > > Key: WFLY-2859 > URL: https://issues.jboss.org/browse/WFLY-2859 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld, REST > Affects Versions: 8.0.0.CR1 > Reporter: Matt Drees > Assignee: Stuart Douglas > > It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class. > See the forum link for a specific instance of this. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2770) CDI Decorator should be enable on Websocket enpoint

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2770?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-2770: -------------------------------------- If the resolution fails then injection etc will still work, just not decorators. > CDI Decorator should be enable on Websocket enpoint > ---------------------------------------------------- > > Key: WFLY-2770 > URL: https://issues.jboss.org/browse/WFLY-2770 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: CDI / Weld, Web (Undertow) > Affects Versions: 8.0.0.CR1 > Reporter: Antoine Sabot-Durand > Assignee: Stuart Douglas > Attachments: websocket-decorator.zip > > > Defining a CDI decorator on Websocket Endpoint doesn't work. I know it's not strictly required by websocket spec (it only mentions interceptors) but as it's working in Glassfish 4, it could be nice and less confusing to add this feature to Wildfly -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 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 August 2014