[JBoss JIRA] (WFLY-1421) Listing JNDI tree from container when an entry is not available causes exception
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1421?page=com.atlassian.jira.plugin.... ]
Eduardo Martins resolved WFLY-1421.
-----------------------------------
Fix Version/s: (was: Awaiting Volunteers)
Resolution: Rejected
Context#list() is the JNDI API equivalent to the JNDI View management op. With respect to Context#listBindings(), the exception must be thrown, its result requires the concrete bound objects to be retrieved.
> Listing JNDI tree from container when an entry is not available causes exception
> --------------------------------------------------------------------------------
>
> Key: WFLY-1421
> URL: https://issues.jboss.org/browse/WFLY-1421
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Alpha1
> Reporter: Jan Martiska
> Assignee: Eduardo Martins
>
> When you list server's JNDI tree using management APIs and some entries cannot be retrieved, instead of these entries, it will return a marker denoting an unknown value. However, if you list the JNDI tree programatically from within the container and this happens, you get a NamingException. I believe that the listBindings operation should also return a marker for an unknown value (like null), rather than failing the whole operation.
> How to reproduce:
> Bind a federated JNDI context, like so:
> {noformat}
> /subsystem=naming/binding=java\:global\/tt:add(binding-type=external-context, module=org.jboss.as.naming, class=javax.naming.directory.InitialDirContext, environment={["java.naming.provider.url"=>"ldap://some.ldap.url:389", "java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory", "initial-context-class"=>"javax.naming.directory.InitialDirContext"]}, cache=false)
> {noformat}
> then, at some point in time, make this context become unavailable, for example stop the backing LDAP server (or block the connection to it using a firewall..).
> *Other option* - as a simpler reproducer, you may just add any invalid URL in the java.naming.provider.url property, then it will fail always.
> After that, do this in a deployed application:
> {noformat}
> InitialContext ctx = new InitialContext();
> ctx.listBindings("java:global");
> {noformat}
> it will throw a NamingException after the connection attempt times out.
> {noformat}
> javax.naming.NamingException: java.lang.reflect.InvocationTargetException [Root exception is java.lang.RuntimeException: java.lang.reflect.InvocationTargetException]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
> at org.jboss.as.naming.ServiceBasedNamingStore.listBindings(ServiceBasedNamingStore.java:216)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:347)
> at org.jboss.as.naming.InitialContext.listBindings(InitialContext.java:131)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:363)
> at javax.naming.InitialContext.listBindings(InitialContext.java:466) [rt.jar:1.7.0_21]
> at ListingServlet.doGet(ListingServlet.java:30) ... 33 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:258)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> ... 39 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
> at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:52)
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> ... 40 more
> Caused by: javax.naming.CommunicationException: ldap.cz:3890 [Root exception is java.net.ConnectException: Connection timed out]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:224) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_21]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_21]
> at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) [rt.jar:1.7.0_21]
> ... 47 more
> Caused by: java.net.ConnectException: Connection timed out
> at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_21]
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:528) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:425) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:208) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:366) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:201) [rt.jar:1.7.0_21]
> ... 60 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (WFLY-1421) Listing JNDI tree from container when an entry is not available causes exception
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1421?page=com.atlassian.jira.plugin.... ]
Eduardo Martins reassigned WFLY-1421:
-------------------------------------
Assignee: Eduardo Martins
> Listing JNDI tree from container when an entry is not available causes exception
> --------------------------------------------------------------------------------
>
> Key: WFLY-1421
> URL: https://issues.jboss.org/browse/WFLY-1421
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Alpha1
> Reporter: Jan Martiska
> Assignee: Eduardo Martins
> Fix For: Awaiting Volunteers
>
>
> When you list server's JNDI tree using management APIs and some entries cannot be retrieved, instead of these entries, it will return a marker denoting an unknown value. However, if you list the JNDI tree programatically from within the container and this happens, you get a NamingException. I believe that the listBindings operation should also return a marker for an unknown value (like null), rather than failing the whole operation.
> How to reproduce:
> Bind a federated JNDI context, like so:
> {noformat}
> /subsystem=naming/binding=java\:global\/tt:add(binding-type=external-context, module=org.jboss.as.naming, class=javax.naming.directory.InitialDirContext, environment={["java.naming.provider.url"=>"ldap://some.ldap.url:389", "java.naming.factory.initial"=>"com.sun.jndi.ldap.LdapCtxFactory", "initial-context-class"=>"javax.naming.directory.InitialDirContext"]}, cache=false)
> {noformat}
> then, at some point in time, make this context become unavailable, for example stop the backing LDAP server (or block the connection to it using a firewall..).
> *Other option* - as a simpler reproducer, you may just add any invalid URL in the java.naming.provider.url property, then it will fail always.
> After that, do this in a deployed application:
> {noformat}
> InitialContext ctx = new InitialContext();
> ctx.listBindings("java:global");
> {noformat}
> it will throw a NamingException after the connection attempt times out.
> {noformat}
> javax.naming.NamingException: java.lang.reflect.InvocationTargetException [Root exception is java.lang.RuntimeException: java.lang.reflect.InvocationTargetException]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142)
> at org.jboss.as.naming.ServiceBasedNamingStore.listBindings(ServiceBasedNamingStore.java:216)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:347)
> at org.jboss.as.naming.InitialContext.listBindings(InitialContext.java:131)
> at org.jboss.as.naming.NamingContext.listBindings(NamingContext.java:363)
> at javax.naming.InitialContext.listBindings(InitialContext.java:466) [rt.jar:1.7.0_21]
> at ListingServlet.doGet(ListingServlet.java:30) ... 33 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:258)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> ... 39 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
> at org.jboss.as.naming.ExternalContextObjectFactory.createContext(ExternalContextObjectFactory.java:87)
> at org.jboss.as.naming.ExternalContextObjectFactory.getObjectInstance(ExternalContextObjectFactory.java:52)
> at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:255)
> ... 40 more
> Caused by: javax.naming.CommunicationException: ldap.cz:3890 [Root exception is java.net.ConnectException: Connection timed out]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:224) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1600) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_21]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.<init>(InitialContext.java:216) [rt.jar:1.7.0_21]
> at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) [rt.jar:1.7.0_21]
> ... 47 more
> Caused by: java.net.ConnectException: Connection timed out
> at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_21]
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_21]
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_21]
> at java.net.Socket.connect(Socket.java:528) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:425) [rt.jar:1.7.0_21]
> at java.net.Socket.<init>(Socket.java:208) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:366) [rt.jar:1.7.0_21]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:201) [rt.jar:1.7.0_21]
> ... 60 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (WFLY-261) Add way to properly parse JNDI urls in AS codebase
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-261?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins closed WFLY-261.
--------------------------------
Resolution: Out of Date
> Add way to properly parse JNDI urls in AS codebase
> --------------------------------------------------
>
> Key: WFLY-261
> URL: https://issues.jboss.org/browse/WFLY-261
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Fix For: 9.0.0.Beta1
>
>
> This is a followup of AS7-2138. Original code, in case no URL context threw NamingException. The AS7-2138 introduced a fallback to NamingContext in case AS7 does not provide custom hack for url( like EJB ). However the fallback did not fail with NamingException in case it did not locate Context. This essentially made it go knee deep into AS7 service lookups, which hides real cause of failure.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4196.
----------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Rejected
This is not really a bug, however I am updating Undertow to use setContentLength instead of setContentLengthLong where possible (which should be pretty much all cases).
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 9.0.0.Beta1
>
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Nicolas Cazottes (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Nicolas Cazottes commented on WFLY-4196:
----------------------------------------
Hello,
I have done a few more search on this subject and you guessed right.
Actually, the gzip filter uses an HttpServletResponseWrapper that overrides the method setContentLength with an implementation that does nothing.
This wrapper does not override setContentLengthLong as it has been written with servlet 2.5 compliance.
I upgraded the filter's building dependency javax.servlet-api version to 3.1 and overriden the setContentLengthLong method to do nothing.
It works then successfully with wildfly and also all versions of Jboss on which my application runs :).
My conclusion is that, for my use case, wildfly breaks the compatibility of the servlet api previous to 3.1 : it requires the application to be rebuild with a constraint of 3.1 servlet api version.
I don't know if wildfly should be able to run pure servlet 2.5 web application for spec compliance and if this point is to be considered a bug or if 3.1 is mandatory for the application to be run.
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (DROOLS-673) NPE because ConsequenceMetaData.toString is not null-safe
by george thomas (JIRA)
[ https://issues.jboss.org/browse/DROOLS-673?page=com.atlassian.jira.plugin... ]
george thomas updated DROOLS-673:
---------------------------------
Attachment: ConsequenceMetaData.NPE.log
> NPE because ConsequenceMetaData.toString is not null-safe
> ---------------------------------------------------------
>
> Key: DROOLS-673
> URL: https://issues.jboss.org/browse/DROOLS-673
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Reporter: george thomas
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: ConsequenceMetaData.NPE.log
>
>
> The {{toString()}} method in {{org.drools.core.rule.ConsequenceMetaData}} is not null-safe. It assumes that the {{List}} {{statements}} contains at least one element.
> This is a problem when the method gets invoked during the serialization-based deep clone effected during initialization under certain conditions (see the "Reproduce" section).
> With this combination, code in {{java.io.ObjectOutputStream}} ends up invoking the {{toString()}} method in order to print additional information in the stack trace for {{java.io.NotSerializableException}}. I have attached a snippet of the stack trace as a reference.
> This is a problem even in the [latest version in github|https://github.com/droolsjbpm/drools/blob/master/drools-core/src/m...].
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (DROOLS-673) NPE because ConsequenceMetaData.toString is not null-safe
by george thomas (JIRA)
[ https://issues.jboss.org/browse/DROOLS-673?page=com.atlassian.jira.plugin... ]
george thomas updated DROOLS-673:
---------------------------------
Description:
The {{toString()}} method in {{org.drools.core.rule.ConsequenceMetaData}} is not null-safe. It assumes that the {{List}} {{statements}} contains at least one element.
This is a problem when the method gets invoked during the serialization-based deep clone effected during initialization under certain conditions (see the "Reproduce" section).
With this combination, code in {{java.io.ObjectOutputStream}} ends up invoking the {{toString()}} method in order to print additional information in the stack trace for {{java.io.NotSerializableException}}. I have attached a snippet of the stack trace as a reference.
The code in question is unchanged even in the [latest version in github|https://github.com/droolsjbpm/drools/blob/master/drools-core/src/m...].
was:
The {{toString()}} method in {{org.drools.core.rule.ConsequenceMetaData}} is not null-safe. It assumes that the {{List}} {{statements}} contains at least one element.
This is a problem when the method gets invoked during the serialization-based deep clone effected during initialization under certain conditions (see the "Reproduce" section).
With this combination, code in {{java.io.ObjectOutputStream}} ends up invoking the {{toString()}} method in order to print additional information in the stack trace for {{java.io.NotSerializableException}}. I have attached a snippet of the stack trace as a reference.
This is a problem even in the [latest version in github|https://github.com/droolsjbpm/drools/blob/master/drools-core/src/m...].
> NPE because ConsequenceMetaData.toString is not null-safe
> ---------------------------------------------------------
>
> Key: DROOLS-673
> URL: https://issues.jboss.org/browse/DROOLS-673
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Reporter: george thomas
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: ConsequenceMetaData.NPE.log
>
>
> The {{toString()}} method in {{org.drools.core.rule.ConsequenceMetaData}} is not null-safe. It assumes that the {{List}} {{statements}} contains at least one element.
> This is a problem when the method gets invoked during the serialization-based deep clone effected during initialization under certain conditions (see the "Reproduce" section).
> With this combination, code in {{java.io.ObjectOutputStream}} ends up invoking the {{toString()}} method in order to print additional information in the stack trace for {{java.io.NotSerializableException}}. I have attached a snippet of the stack trace as a reference.
> The code in question is unchanged even in the [latest version in github|https://github.com/droolsjbpm/drools/blob/master/drools-core/src/m...].
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (DROOLS-673) NPE because ConsequenceMetaData.toString is not null-safe
by george thomas (JIRA)
george thomas created DROOLS-673:
------------------------------------
Summary: NPE because ConsequenceMetaData.toString is not null-safe
Key: DROOLS-673
URL: https://issues.jboss.org/browse/DROOLS-673
Project: Drools
Issue Type: Bug
Affects Versions: 6.1.0.Final
Reporter: george thomas
Assignee: Mark Proctor
Priority: Minor
Attachments: ConsequenceMetaData.NPE.log
The {{toString()}} method in {{org.drools.core.rule.ConsequenceMetaData}} is not null-safe. It assumes that the {{List}} {{statements}} contains at least one element.
This is a problem when the method gets invoked during the serialization-based deep clone effected during initialization under certain conditions (see the "Reproduce" section).
With this combination, code in {{java.io.ObjectOutputStream}} ends up invoking the {{toString()}} method in order to print additional information in the stack trace for {{java.io.NotSerializableException}}. I have attached a snippet of the stack trace as a reference.
This is a problem even in the [latest version in github|https://github.com/droolsjbpm/drools/blob/master/drools-core/src/m...].
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
by Nick . (JIRA)
Nick . created WFLY-4205:
----------------------------
Summary: 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, Spring MVC, Ubuntu 14.04
Reporter: Nick .
Assignee: Stuart Douglas
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.3.11#6341)
9 years, 12 months
[JBoss JIRA] (WFLY-4204) Add predicate support for response-header filter
by Dino Tsoumakis (JIRA)
[ https://issues.jboss.org/browse/WFLY-4204?page=com.atlassian.jira.plugin.... ]
Dino Tsoumakis commented on WFLY-4204:
--------------------------------------
I use the same predicate for gzip filter and it works fine. I also tested other predicates (e.g. equals, exists,...) with response-header, but nothing works.
> Add predicate support for response-header filter
> ------------------------------------------------
>
> Key: WFLY-4204
> URL: https://issues.jboss.org/browse/WFLY-4204
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Dino Tsoumakis
> Assignee: Stuart Douglas
> Priority: Minor
>
> gzip filter has predicate support. response-header filter seems to ignore predicates.
> It would be great to add predicate support to the response-header filter in the same way as it is working for gzip filter. Thus it would be possible to set response-header values dependent on other header values. This is interesting for setting a correct "Vary:" header value.
> If using the predicate
> {code}
> predicate="regex[pattern='(?:application/javascript|text/css|text/html)(;.*)?', value=%{o,Content-Type}, full-match=true]"
> {code}
> for filter-ref of a response-header filter request result in a 500 error producing the following stack trace in the log:
> {code}
> ^[[0m^[[31m17:05:15,286 ERROR [io.undertow.request] (default I/O-1) Blocking request failed HttpServerExchange{ GET /}: java.lang.NullPointerException
> at java.util.regex.Matcher.getTextLength(Matcher.java:1283) [rt.jar:1.8.0_25]
> at java.util.regex.Matcher.reset(Matcher.java:309) [rt.jar:1.8.0_25]
> at java.util.regex.Matcher.<init>(Matcher.java:229) [rt.jar:1.8.0_25]
> at java.util.regex.Pattern.matcher(Pattern.java:1093) [rt.jar:1.8.0_25]
> at io.undertow.predicate.RegularExpressionPredicate.resolve(RegularExpressionPredicate.java:41)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:24)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:66)
> at io.undertow.server.handlers.RequestLimit.handleRequest(RequestLimit.java:103)
> at io.undertow.server.handlers.RequestLimitingHandler.handleRequest(RequestLimitingHandler.java:81)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:57)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:43)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
