September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1891) HTTPSession sharing between wars delivered in an EAR

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1891?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reopened WFLY-1891: ------------------------------- > HTTPSession sharing between wars delivered in an EAR > ---------------------------------------------------- > > Key: WFLY-1891 > URL: https://issues.jboss.org/browse/WFLY-1891 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: John Doyle > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > WAS and WL have this feature, and its been requested for several earlier versions of AS. Having this capability will ease the migration of users from WAS and WL to WildFly. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-998) run-as does not work for Servlet.init()

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-998?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar updated WFLY-998: ----------------------------- Fix Version/s: 8.2.0.CR1 > run-as does not work for Servlet.init() > --------------------------------------- > > Key: WFLY-998 > URL: https://issues.jboss.org/browse/WFLY-998 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Derek Horton > Assignee: Stuart Douglas > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > According to the servlet 2.4 spec, the run-as should be used for Servlet.init() > page 285: > " Clarification: run-as identity must apply to all calls from a servlet including init() and destroy() (12.7)" > This isn't working. > In JBoss 5.x, it looks like this functionality was implemented by a RunAsListener. However, that listener does not appear to exist in the EAP 6 code base. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3300) Provide a way to change SSO session id cookie name. It is fixed to JSESSIONIDSSO now

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3300?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3300: ------------------------------ Fix Version/s: 8.2.0.CR1 > Provide a way to change SSO session id cookie name. It is fixed to JSESSIONIDSSO now > ------------------------------------------------------------------------------------ > > Key: WFLY-3300 > URL: https://issues.jboss.org/browse/WFLY-3300 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Loc Ha > Assignee: Tomaz Cerar > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3391) Multipart handling broken when HttpServletRequest accessed by servlet filter

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3391?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3391: ------------------------------ Fix Version/s: 8.2.0.CR1 > Multipart handling broken when HttpServletRequest accessed by servlet filter > ---------------------------------------------------------------------------- > > Key: WFLY-3391 > URL: https://issues.jboss.org/browse/WFLY-3391 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Lincoln Baxter III > Assignee: Stuart Douglas > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > See forum post for full description: http://ocpsoft.org/support/topic/command-not-fired-with-multipart-form-js... > I don't exactly know if this is a bug or not, but I wanted to raise the issue just in case. It seems like a "corner" case that could occur quite easily, and given that it requires a pretty nasty workaround (using undertow internals,) I figured it should probably be addressed. > Should DefaultServlet be aware of multipart requests? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3448) Session ID change with sub-directories using "/" context (virtual host)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3448?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3448: ------------------------------ Fix Version/s: 8.2.0.CR1 > Session ID change with sub-directories using "/" context (virtual host) > ----------------------------------------------------------------------- > > Key: WFLY-3448 > URL: https://issues.jboss.org/browse/WFLY-3448 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Wildfly 8.1.0 RC2 > Reporter: David Cabillic > Assignee: Stuart Douglas > Labels: sessionid, virtualhosts > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > I used a virtual host in Wildfly like this : > <host name="toto" alias="www.toto.com"> > <location name="/" handler="welcome-content"/> > </host> > When I try to access www.toto.com/sub/, a new cookie is created. It would be great with a "/sub" context but it is not for a "/" context. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3514) JASPIAuthenticationMechanism#authenticate installs secureResponse handler twice or more

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3514?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3514: ------------------------------ Fix Version/s: 8.2.0.CR1 > JASPIAuthenticationMechanism#authenticate installs secureResponse handler twice or more > --------------------------------------------------------------------------------------- > > Key: WFLY-3514 > URL: https://issues.jboss.org/browse/WFLY-3514 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: arjan tijms > Assignee: Stuart Douglas > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > {{JASPIAuthenticationMechanism#authenticate}} installs a response wrapper to later on handle {{secureResponse}}. > This is correct for the initial call to the SAM/context (prior to entering the Servlet pipeline), but this is most likely not correct for a call following {{HttpServletRequest#authenticate}}. In many situations this will lead to exceptions about a "requestChannel" already been opened (perhaps this should be "responseChannel"?). > {{JASPIAuthenticationMechanism#authenticate}} contains the following code: > {code} > @Override > public AuthenticationMechanismOutcome authenticate(final HttpServerExchange exchange, final SecurityContext sc) { > final ServletRequestContext requestContext = exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY); > final JASPIServerAuthenticationManager sam = createJASPIAuthenticationManager(); > final GenericMessageInfo messageInfo = createMessageInfo(exchange, sc); > final String applicationIdentifier = buildApplicationIdentifier(requestContext); > // ... > secureResponse(exchange, sc, sam, messageInfo, cbh); > return outcome; > {code} > With {{secureResponse}}: > {code} > private void secureResponse(final HttpServerExchange exchange, final SecurityContext securityContext, final JASPIServerAuthenticationManager sam, final GenericMessageInfo messageInfo, final JASPICallbackHandler cbh) { > // we add a response wrapper to properly invoke the secureResponse, after processing the destination > exchange.addResponseWrapper(new ConduitWrapper<StreamSinkConduit>() { > @Override > public StreamSinkConduit wrap(final ConduitFactory<StreamSinkConduit> factory, final HttpServerExchange exchange) { > ServletRequestContext requestContext = exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY); > String applicationIdentifier = buildApplicationIdentifier(requestContext); > // ... > return factory.create(); > } > }); > } > {code} > As can be seen, every call to {{authenticate}} attempts to install the handler again. > I guess {{secureResponse}} should somehow check if the call was made from {{request#authenticate}}, or that it was done at the beginning of the request, or simply remember whether a registration has already been made or not. > I patched the code locally to use a request attribute to implement the last option and this seems to work. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3507) REGRESSION: JSP servlet cannot be mapped to different extensions

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3507?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3507: ------------------------------ Fix Version/s: 8.2.0.CR1 > REGRESSION: JSP servlet cannot be mapped to different extensions > ---------------------------------------------------------------- > > Key: WFLY-3507 > URL: https://issues.jboss.org/browse/WFLY-3507 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Richard Kennard > Assignee: Emmanuel Hugonnet > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > Attachments: jsp-mapping.zip > > > When migrating an app from JBoss 7.1.1.Final to WildFly 8.1.0.Final, one can no longer remap the default JSP servlet to different extensions. > This is useful when you want some lightweight server-side processing of, say, JavaScript or CSS files. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3717) TldParsingDeploymentProcessor.parseTLD does not attach root cause

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3717?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-3717: ------------------------------ Fix Version/s: 8.2.0.CR1 > TldParsingDeploymentProcessor.parseTLD does not attach root cause > ----------------------------------------------------------------- > > Key: WFLY-3717 > URL: https://issues.jboss.org/browse/WFLY-3717 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: James Livingston > Assignee: James Livingston > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > > When TldParsingDeploymentProcessor.parseTLD() catches IOException it attached it as the root cause of the DeploymentUnitProcessingException. When it catches XMLStreamException it does not. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1172) mechanism to load tag libraries from module

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1172?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-1172: ------------------------------ Fix Version/s: 8.2.0.CR1 > mechanism to load tag libraries from module > ------------------------------------------- > > Key: WFLY-1172 > URL: https://issues.jboss.org/browse/WFLY-1172 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Ivica Loncar > Assignee: Stuart Douglas > Priority: Critical > Labels: modules, tag, taglib, tld > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > Attachments: ExternalTld.txt, ExternalTldParsingDeploymentProcessor.java.diff > > Original Estimate: 1 day > Remaining Estimate: 1 day > > tag libraries are scanned only if they appear in jar inside WEB-INF/lib or are defined in tld under WEB-INF. > The simplest scenario to explain why this is a problem: portlet 2 defines standard portlet taglib, but the classes in this file come from concrete implementations. Currently I see no way to use 2 different portals in a portable way. > Please provide a way to notify a relevant subsystem for web applications that specific module contains a .tld. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3719) Missing <uri> in the tld files causes NullPointerException during deployment on WildFly

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3719?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-3719. ------------------------------- Resolution: Done > Missing <uri> in the tld files causes NullPointerException during deployment on WildFly > --------------------------------------------------------------------------------------- > > Key: WFLY-3719 > URL: https://issues.jboss.org/browse/WFLY-3719 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Stuart Douglas > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > Attachments: TagClassDemo.war > > > - If The TLD file has missing *<uri>* tag in it then rather than validating WildFly throws NullPointerException. > *WEB-INF/custom.tld* > {code} > <taglib> > <tlib-version>1.0</tlib-version> > <jsp-version>2.0</jsp-version> >  > <short-name>Example TLD with Body</short-name> > <tag> > <name>Hello</name> > <tag-class>tags.HelloTag</tag-class> > <body-content>scriptless</body-content> > </tag> > </taglib> > {code} > - During deployment of a war containing above TLD causes following NullPointerException on WildFly: > {code} > 13:15:25,857 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: java.lang.NullPointerException > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createTldsInfo(UndertowDeploymentInfoService.java:1028) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:552) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > 13:15:25,865 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./TagClassDemo.UndertowDeploymentInfoService: Failed to start service > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

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 September 2014