[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
by David Edwards (JIRA)
[ https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin.... ]
David Edwards edited comment on WFLY-4205 at 11/9/15 5:02 AM:
--------------------------------------------------------------
Does the fix for this still require a META-INF/services/javax.servlet.ServletContainerIntializer file in the WAR's WEB-INF/lib? This certainly seems to be the case in 9.0.2.Final. I have an example project showing the work arounds I have had to add to get Spring Boot WARs to work in an EAR on Wildfly: https://github.com/purple52/spring-boot-ear-skinny-war.
It appears that once there is an SCI in META-INF/services of each WAR, Wildfly loads the SpringServletContainerInitializer from the EAR's lib folder. However, when it scans for WebApplicationInitializer implementations, it only looks in the EAR's lib folder, so does not find Spring Boot applications in the WAR files.
was (Author: purple52):
Does the fix for this still require a META-INF/services/javax.servlet.ServletContainerIntializer file in the WAR's WEB-INF/lib? This certainly seems to be the case in 9.0.2.Final. I have an example project showing the work arounds I have had to add to get Spring Boot WARs to work in an EAR on Wildfly: https://github.com/purple52/spring-boot-ear-skinny-war.
> Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
> --------------------------------------------------------------------------------
>
> Key: WFLY-4205
> URL: https://issues.jboss.org/browse/WFLY-4205
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04
> Reporter: Nick .
> Assignee: Stuart Douglas
> Labels: EAR, servlet3.0, spring-mvc
> Fix For: 9.0.0.Beta1
>
>
> Hi,
> I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All my spring mvc related jar's are in my EAR/lib, i'm using SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as follows
> {code}
> @HandlesTypes(WebApplicationInitializer.class)
> public class SpringServletContainerInitializer implements ServletContainerInitializer {
> @Override
> public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
> throws ServletException {
> List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
> if (webAppInitializerClasses != null) {
> for (Class<?> waiClass : webAppInitializerClasses) {
> // Be defensive: Some servlet containers provide us with invalid classes,
> // no matter what @HandlesTypes says...
> if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) &&
> WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
> try {
> initializers.add((WebApplicationInitializer) waiClass.newInstance());
> }
> catch (Throwable ex) {
> throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex);
> }
> }
> }
> }
> if (initializers.isEmpty()) {
> servletContext.log("No Spring WebApplicationInitializer types detected on classpath");
> return;
> }
> AnnotationAwareOrderComparator.sort(initializers);
> servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers);
> for (WebApplicationInitializer initializer : initializers) {
> initializer.onStartup(servletContext);
> }
> }
> }
> {code}
> But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the EAR/lib
> Even i have tried adding the extracted the SPI from spring-web jar and added inside my war's WEB-INF/lib as a jar
> WEB-INF/lib/web-init-spi.jar which contains
> META-INF/services/javax.servlet.ServletContainerIntializer file with org.springframework.web.SpringServletContainerInitializer as an entry. This time its detecting SpringServletContainerInitializer but not detecting what defined in @HandlesTypes
> Its only working If i package all those spring mvc jars inside WEB-INF/lib then everything started working.
> I have no idea this is how the servlet specification works or its a wildfly issue but i see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR deployment structure.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-3971) Jar Services in META-INF/services are not loaded from static modules
by David Edwards (JIRA)
[ https://issues.jboss.org/browse/WFLY-3971?page=com.atlassian.jira.plugin.... ]
David Edwards commented on WFLY-3971:
-------------------------------------
This is causing me problems with bundling skinny WARs containing Spring Boot applications. I have an example project showing my work arounds: :https://github.com/purple52/spring-boot-ear-skinny-war. Adding your own META-INF/services isn't a great solution, especially if the WARs in question are from an external source. Is there a reason Wildfly doesn't use the full class path when looking for SCIs?
I also see a further problem once a local SCI is added; the search for implementations of WebApplicationInitializer only scans the common modules in my EAR's lib directory, not the WAR files' WEB-INF/lib!
> Jar Services in META-INF/services are not loaded from static modules
> --------------------------------------------------------------------
>
> Key: WFLY-3971
> URL: https://issues.jboss.org/browse/WFLY-3971
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 9.0.0.Final, 10.0.0.Alpha6
> Reporter: Tomas Repel
> Assignee: Stuart Douglas
>
> If the web application (war) uses jar file from static module, the content of META-INF/services has no effect. If the jar is located inside WEB-INF/lib, services are loaded successfully.
> Neither adding `Dependencies: my.module.name.com services` into MANIFEST.MF nor adding `services="import"` to jboss-deployment-structure.xml works.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
by David Edwards (JIRA)
[ https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin.... ]
David Edwards commented on WFLY-4205:
-------------------------------------
Does the fix for this still require a META-INF/services/javax.servlet.ServletContainerIntializer file in the WAR's WEB-INF/lib? This certainly seems to be the case in 9.0.2.Final. I have an example project showing the work arounds I have had to add to get Spring Boot WARs to work in an EAR on Wildfly: https://github.com/purple52/spring-boot-ear-skinny-war.
> Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
> --------------------------------------------------------------------------------
>
> Key: WFLY-4205
> URL: https://issues.jboss.org/browse/WFLY-4205
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04
> Reporter: Nick .
> Assignee: Stuart Douglas
> Labels: EAR, servlet3.0, spring-mvc
> Fix For: 9.0.0.Beta1
>
>
> Hi,
> I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All my spring mvc related jar's are in my EAR/lib, i'm using SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as follows
> {code}
> @HandlesTypes(WebApplicationInitializer.class)
> public class SpringServletContainerInitializer implements ServletContainerInitializer {
> @Override
> public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
> throws ServletException {
> List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
> if (webAppInitializerClasses != null) {
> for (Class<?> waiClass : webAppInitializerClasses) {
> // Be defensive: Some servlet containers provide us with invalid classes,
> // no matter what @HandlesTypes says...
> if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) &&
> WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
> try {
> initializers.add((WebApplicationInitializer) waiClass.newInstance());
> }
> catch (Throwable ex) {
> throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex);
> }
> }
> }
> }
> if (initializers.isEmpty()) {
> servletContext.log("No Spring WebApplicationInitializer types detected on classpath");
> return;
> }
> AnnotationAwareOrderComparator.sort(initializers);
> servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers);
> for (WebApplicationInitializer initializer : initializers) {
> initializer.onStartup(servletContext);
> }
> }
> }
> {code}
> But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the EAR/lib
> Even i have tried adding the extracted the SPI from spring-web jar and added inside my war's WEB-INF/lib as a jar
> WEB-INF/lib/web-init-spi.jar which contains
> META-INF/services/javax.servlet.ServletContainerIntializer file with org.springframework.web.SpringServletContainerInitializer as an entry. This time its detecting SpringServletContainerInitializer but not detecting what defined in @HandlesTypes
> Its only working If i package all those spring mvc jars inside WEB-INF/lib then everything started working.
> I have no idea this is how the servlet specification works or its a wildfly issue but i see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR deployment structure.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5473) Session.invalidate() does not invalidate SSO context for non-distributable applications
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5473?page=com.atlassian.jira.plugin.... ]
Richard Janík updated WFLY-5473:
--------------------------------
Steps to Reproduce:
*- two servers with non-distributable application (requires FORM authentication, user added) and <single-sign-on/> set up
- create a few requests to both servers, you'll be required to authenticate for the first request
- you should now have at least two sessions with the same SSO context
- invalidate one of those sessions by calling session.invalidate()
- what happens: another request to either of the servers won't require you to authenticate
- what's expected: you should be required to authenticate again (SSO context should be destroyed) - this happens when the application is <distributable/>*
was:
- two servers with non-distributable application (requires FORM authentication, user added) and <single-sign-on/> set up
- create a few requests to both servers, you'll be required to authenticate for the first request
- you should now have at least two sessions with the same SSO context
- invalidate one of those sessions by calling session.invalidate()
- what happens: another request to either of the servers won't require you to authenticate
- what's expected: you should be required to authenticate again (SSO context should be destroyed) - this happens when the application is <distributable/>
> Session.invalidate() does not invalidate SSO context for non-distributable applications
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5473
> URL: https://issues.jboss.org/browse/WFLY-5473
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.Final
>
>
> See "Steps to Reproduce" for detailed description.
> According to my limited knowledge, this was also the core issue in https://bugzilla.redhat.com/show_bug.cgi?id=924456 which has been dispatched as a one-off to a customer. Thus, I'm setting the priority to blocker as this is a regression against 6.4.x. No exceptions have been observed in the server output however.
> Adding Clustering component as I've been trying this with standalone-ha.xml and BZ 924456 relates to clustering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5473) Session.invalidate() does not invalidate SSO context for non-distributable applications
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5473?page=com.atlassian.jira.plugin.... ]
Richard Janík updated WFLY-5473:
--------------------------------
Steps to Reproduce:
- two servers with non-distributable application (requires FORM authentication, user added) and <single-sign-on/> set up
- create a few requests to both servers, you'll be required to authenticate for the first request
- you should now have at least two sessions with the same SSO context
- invalidate one of those sessions by calling session.invalidate()
- what happens: another request to either of the servers won't require you to authenticate
- what's expected: you should be required to authenticate again (SSO context should be destroyed) - this happens when the application is <distributable/>*
was:
*- two servers with non-distributable application (requires FORM authentication, user added) and <single-sign-on/> set up
- create a few requests to both servers, you'll be required to authenticate for the first request
- you should now have at least two sessions with the same SSO context
- invalidate one of those sessions by calling session.invalidate()
- what happens: another request to either of the servers won't require you to authenticate
- what's expected: you should be required to authenticate again (SSO context should be destroyed) - this happens when the application is <distributable/>*
> Session.invalidate() does not invalidate SSO context for non-distributable applications
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5473
> URL: https://issues.jboss.org/browse/WFLY-5473
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.Final
>
>
> See "Steps to Reproduce" for detailed description.
> According to my limited knowledge, this was also the core issue in https://bugzilla.redhat.com/show_bug.cgi?id=924456 which has been dispatched as a one-off to a customer. Thus, I'm setting the priority to blocker as this is a regression against 6.4.x. No exceptions have been observed in the server output however.
> Adding Clustering component as I've been trying this with standalone-ha.xml and BZ 924456 relates to clustering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5473) Session.invalidate() does not invalidate SSO context for non-distributable applications
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5473?page=com.atlassian.jira.plugin.... ]
Richard Janík reopened WFLY-5473:
---------------------------------
I've checked with 7.0.0.DR13 (should be 10.0.0.Final) and I still see this behavior. Additionally, when a user authenticates to a server after step 1, and then makes requests to the other server, the session on the first server is destroyed. I don't think this behavior was present back when the issue was filed.
> Session.invalidate() does not invalidate SSO context for non-distributable applications
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5473
> URL: https://issues.jboss.org/browse/WFLY-5473
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.Final
>
>
> See "Steps to Reproduce" for detailed description.
> According to my limited knowledge, this was also the core issue in https://bugzilla.redhat.com/show_bug.cgi?id=924456 which has been dispatched as a one-off to a customer. Thus, I'm setting the priority to blocker as this is a regression against 6.4.x. No exceptions have been observed in the server output however.
> Adding Clustering component as I've been trying this with standalone-ha.xml and BZ 924456 relates to clustering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Richard Janík reopened WFLY-5484:
---------------------------------
Hey,
I'm still seeing this with 7.0.0.DR13. Since this was said to be related to WFLY-5473, I'm extra checking that issue.
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.Final
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-973) Endpoint doesn't respond JSON requests
by 재우 이 (JIRA)
재우 이 created DROOLS-973:
---------------------------
Summary: Endpoint doesn't respond JSON requests
Key: DROOLS-973
URL: https://issues.jboss.org/browse/DROOLS-973
Project: Drools
Issue Type: Sub-task
Components: core engine
Affects Versions: 6.3.0.Final
Environment: Drools 6.3.0 Final, CentOS 6.4, WildFly.
Reporter: 재우 이
Assignee: Mario Fusco
The below erros occured again in drools 6.3.0.
-------------------------------------------------------------------------------------
DROOLS-712
I am using latest version of kie-server-6.2.CR4 only,war downloaded from the https://repository.jboss.org/nexus/content/groups/public/org/kie/kie-serv...
with xml request getting proper response,but when ever try to use JSON request throwing the below expection.
error:
====
com.thoughtworks.xstream.io.StreamException: : only whitespace content
allowed before start tag and not { (position: START_DOCUMENT seen {... @1:1)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months