February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1263) Beef up testsuite coverage of web deployment metrics

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1263?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-1263: --------------------------------- Assignee: Tomaz Cerar > Beef up testsuite coverage of web deployment metrics > ---------------------------------------------------- > > Key: WFLY-1263 > URL: https://issues.jboss.org/browse/WFLY-1263 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management, Web (Undertow) > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > > More tests. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-911) Deploying Spring OSGi WAR bundle

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-911?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar closed WFLY-911. ---------------------------- Resolution: Out of Date JbossWeb & Osgi are no longer part of WildFly 8 > Deploying Spring OSGi WAR bundle > -------------------------------- > > Key: WFLY-911 > URL: https://issues.jboss.org/browse/WFLY-911 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (JBoss Web) > Reporter: Rui Abreu > Labels: osgi, spring > > When deploying a Spring powered OSGi WAR bundle to 7.1.1 Final, the following exception arises: > 11:52:08,998 ERROR [stderr] (WebExtender-Init) Exception in thread "WebExtender-Init" java.lang.NoClassDefFoundError: org/apache/catalina/Loader > 11:52:08,998 ERROR [stderr] (WebExtender-Init) at org.springframework.osgi.web.extender.internal.activator.WarListenerConfiguration.createDefaultWarDeployer(WarListenerConfiguration.java:194) > 11:52:08,999 ERROR [stderr] (WebExtender-Init) at org.springframework.osgi.web.extender.internal.activator.WarListenerConfiguration.<init>(WarListenerConfiguration.java:105) > 11:52:08,999 ERROR [stderr] (WebExtender-Init) at org.springframework.osgi.web.extender.internal.activator.WarLoaderListener$1.run(WarLoaderListener.java:361) > 11:52:09,000 ERROR [stderr] (WebExtender-Init) at java.lang.Thread.run(Thread.java:722) > 11:52:09,001 ERROR [stderr] (WebExtender-Init) Caused by: java.lang.ClassNotFoundException: org.apache.catalina.Loader from [Module "deployment.org.springframework.osgi.web:1.2.1" from Service Module Loader] > The spring-osgi-1.2.1 was previously deployed to the server and the test of sharing a spring bean between two Spring OSGi JAR bundles was successful -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2892) Deploying exploded RAR with exploded JAR fails with CNFE

by Darryl Miles (JIRA)

[ https://issues.jboss.org/browse/WFLY-2892?page=com.atlassian.jira.plugin.... ] Darryl Miles commented on WFLY-2892: ------------------------------------ Note this is the default method of deploying when debugging RAR in Eclipse, using Maven, using 2 Maven projects, a type=rar project (my-ra.rar), that consumes a type=jar project (my-ra-impl.jar) > Deploying exploded RAR with exploded JAR fails with CNFE > -------------------------------------------------------- > > Key: WFLY-2892 > URL: https://issues.jboss.org/browse/WFLY-2892 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.CR1 > Reporter: Darryl Miles > Assignee: Jesper Pedersen > > This is the default method of deployment for JBoss AS Connector when using Eclipse and JBoss Tools. > The resulting file layout is like: > deployments/com.domain.rarproject.rar/com.domain.rarimpl.jar/com/domain/MyClassFile.class > When the RAR is built into a JAR file, that contains the com.domain.rarimpl.jar inside deployment is sucessfull. > The RAR deployer should allow the exploded layout where the "com.domain.rarimpl.jar" is of type directory (not file). > Or JBoss AS Tooling should be fixed to understand the limitation of the AS RAR deployer during development of RAR/JCA driver. > Other kinds of deployments allow exploded format via JBoss VFS. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2884) WildFly issuing new cookie for every request, when faces view is not directly in root (/ )

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2884?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-2884: ----------------------------------- Andre, can you supply some simple reproducer app? > WildFly issuing new cookie for every request, when faces view is not directly in root (/ ) > ------------------------------------------------------------------------------------------ > > Key: WFLY-2884 > URL: https://issues.jboss.org/browse/WFLY-2884 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Reporter: André Prata > Assignee: Stuart Douglas > > Hello everyone. > I have seen possibly similar issues, but people just aren't able to reproduce them anymore and they seem to be closed without further inspection. Maybe this is the same problem. > I started seeing a problem in a new application I'm developing. For views such as "/view.xhtml" everything is working fine. But if I move the view to another directory, e.g. "/admin/view.xtml", I get ViewExpiredExceptions when interacting with backing beans. > Two things: > - This does not happen if there is already a cookie associated with the session. I.e., I can only reproduce the issue if the first cookie is created by accessing "/admin/view.xhtml". Accessing something in the root and then the other directories works just fine (the server won't send set-cookies again). > - When accessing "/admin/view.xhtml" new cookies are issued for every .xhtml request. Fetching PrimeFaces .js.xhtml files after the initial page is loaded, for example, triggers new sessions. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1263) Beef up testsuite coverage of web deployment metrics

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1263?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-1263: ------------------------------ Component/s: Web (Undertow) (was: Web (JBoss Web)) > Beef up testsuite coverage of web deployment metrics > ---------------------------------------------------- > > Key: WFLY-1263 > URL: https://issues.jboss.org/browse/WFLY-1263 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management, Web (Undertow) > Reporter: Brian Stansberry > > More tests. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2892) Deploying exploded RAR with exploded JAR fails with CNFE

by Darryl Miles (JIRA)

Darryl Miles created WFLY-2892: ---------------------------------- Summary: Deploying exploded RAR with exploded JAR fails with CNFE Key: WFLY-2892 URL: https://issues.jboss.org/browse/WFLY-2892 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA Affects Versions: 8.0.0.CR1 Reporter: Darryl Miles Assignee: Jesper Pedersen This is the default method of deployment for JBoss AS Connector when using Eclipse and JBoss Tools. The resulting file layout is like: deployments/com.domain.rarproject.rar/com.domain.rarimpl.jar/com/domain/MyClassFile.class When the RAR is built into a JAR file, that contains the com.domain.rarimpl.jar inside deployment is sucessfull. The RAR deployer should allow the exploded layout where the "com.domain.rarimpl.jar" is of type directory (not file). Or JBoss AS Tooling should be fixed to understand the limitation of the AS RAR deployer during development of RAR/JCA driver. Other kinds of deployments allow exploded format via JBoss VFS. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-897) Lifecycle and injections ignored in @ManagedBean dynamic Servlet

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-897?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar commented on WFLY-897: ---------------------------------- Cheng can you verify that this issue still exists in WildFly 8? > Lifecycle and injections ignored in @ManagedBean dynamic Servlet > ---------------------------------------------------------------- > > Key: WFLY-897 > URL: https://issues.jboss.org/browse/WFLY-897 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (JBoss Web) > Reporter: Cheng Fang > Assignee: Remy Maucherat > > These classes are annotated with javax.annotation.ManagedBean, and added as dynamic servlet. The regular request processing works, but all lifecycle callback methods and resource injectsions in this dynamic servlet class are ignored. > Since this class is a managed bean, these annotations need to be honored, though dynamic servelt itself does not require so. > {quote} > 4.4.3.5 Annotation processing requirements for programmatically added Servlets, Filters and Listeners > Resource injection on all components (Servlets, Filters and Listeners) added programmatically or created programmatically, other than the ones added via the methods that takes an instance, will only be supported when the component is a Managed Bean. > {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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-977) Servlet AsyncListener PreDestroy method not called

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-977?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar commented on WFLY-977: ---------------------------------- Cheng can you verify that this issue still exists in WildFly 8? > Servlet AsyncListener PreDestroy method not called > --------------------------------------------------- > > Key: WFLY-977 > URL: https://issues.jboss.org/browse/WFLY-977 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (JBoss Web) > Reporter: Cheng Fang > Assignee: Remy Maucherat > Attachments: asynccontext.zip > > > The PostConstruct method of an AsyncListener is called, but the PreDestroy method is not called. > For example, the listener is created and registered as follows: > {code:java} > AsyncContext ac = request.startAsync(); > > ac.addListener(ac.createListener(MyAsyncListener.class)); > {code} > AsyncListener is considered a web event listener and Java EE component, and its PreDestroy method should be called when the current request terminates. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-941) Dynamic servlet filter destroy method not called

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-941?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar commented on WFLY-941: ---------------------------------- Cheng can you verify that this issue still exists in WildFly 8? > Dynamic servlet filter destroy method not called > ------------------------------------------------ > > Key: WFLY-941 > URL: https://issues.jboss.org/browse/WFLY-941 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (JBoss Web) > Reporter: Cheng Fang > Assignee: Remy Maucherat > > I added a servlet filter by calling ServletContext.addFilter(name, filterInstance) > the init method of filterInstance (the instance I created and registered) is called, but its destroy method is not called throughout the life of the webapp, even after undeploy. > I would expect the init/destroy methods to be symmetric; if one is called, the other should be called too, to release any resources and clean things up. > For the container-managed filter instance (see AS7-5802), init and destroyed are correctly called. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-796) Servlet response contains DOS-style EOL characters

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-796?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar closed WFLY-796. ---------------------------- Resolution: Out of Date JbossWeb is no longer used in WildFly 8. if problem also exists in new servlet container Undertow, please create new issue for it. > Servlet response contains DOS-style EOL characters > -------------------------------------------------- > > Key: WFLY-796 > URL: https://issues.jboss.org/browse/WFLY-796 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (JBoss Web) > Environment: Mac OS > Reporter: Cheng Fang > Assignee: Remy Maucherat > Attachments: test.war > > > I'm running AS7 on Mac, but found sometimes my servlet PrintWriter produces output with dos-style eol. When opening the output in vi, there are a couple of ^M at end of line. > This does not always happen. After trying out a few samples, I found if the line already contains line.separator, then its eol will be ^M. For example, > {code:java} > PrintWriter out = response.getWriter(); > out.println("From " + System.getProperty("line.separator") + this); > {code} > {noformat} > From > test.TestServlet@180ab18^M > {noformat} > If line.separator is not used when constructing servlet output, then everything looks normal. > My guess is the servlet container may first apply a dos-style eol, then does some sort of replacing with native eol by searching for the first occurrence of line.separator. -- 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, 5 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 February 2014