[JBoss JIRA] (WFLY-6889) ArrayIndexOutOfBoundsException happens when Accept header is just a slash
by Dmitrii Tikhomirov (JIRA)
Dmitrii Tikhomirov created WFLY-6889:
----------------------------------------
Summary: ArrayIndexOutOfBoundsException happens when Accept header is just a slash
Key: WFLY-6889
URL: https://issues.jboss.org/browse/WFLY-6889
Project: WildFly
Issue Type: Bug
Components: JSF
Affects Versions: 10.0.0.Final
Reporter: Dmitrii Tikhomirov
Assignee: Dmitrii Tikhomirov
Fix For: 10.1.0.CR1
Some clients send Accept header with just '/'. It causes ArrayIndexOutOfBoundsException as follows.
{code}
2016-07-26 14:22:57,119 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-15) Error Rendering View[/index.xhtml]: java.lang.ArrayIndexOutOfBoundsException: 0
at com.sun.faces.renderkit.RenderKitUtils.buildTypeArrayFromString(RenderKitUtils.java:913)
at com.sun.faces.renderkit.RenderKitUtils.determineContentType(RenderKitUtils.java:563)
at com.sun.faces.renderkit.RenderKitImpl.createResponseWriter(RenderKitImpl.java:260)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1193)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:405)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:134)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:802)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
This is fixed in the upstream as JAVASERVERFACES-4077 but not backported yet.
https://java.net/jira/browse/JAVASERVERFACES-4077
https://github.com/javaserverfaces/mojarra/commit/14514cfe589cacad683f86a...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2080:
--------------------------------
More issues: if we create the address in an {{AddressGenerator}}, the bind_addr and bind_port are set (e.g. 127.0.0.1 and 7800). However, the port might change on connect time: e.g. if port 7800 is taken, 7801 will be taken, so the address should be 127.0.0.1:7801 instead of 127.0.0.1:7800!
Perhaps {{AddressGenerator}} is not such a good idea and we need to use {{IpAddressUUID}} via a mechanism that's enabled/disabled in the transport and returns {{TP.getPhysicalAddress()}}...
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Henryk Konsek (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Henryk Konsek commented on DROOLS-355:
--------------------------------------
Will do! Just been snowed with some other stuff recently. :)
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Petr Široký
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6133) Add --connection-properties to datasource add command
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6133?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-6133:
-------------------------------
When use {{--connection-properties}} instead of {{connection-url}} to add a new Datasource, it makes the {{connection-url}} not mandatory anymore, so it depends on Jira: WFLY-6200 to be resolved.
> Add --connection-properties to datasource add command
> -----------------------------------------------------
>
> Key: WFLY-6133
> URL: https://issues.jboss.org/browse/WFLY-6133
> Project: WildFly
> Issue Type: Task
> Components: CLI, JCA
> Reporter: Alexey Loubyansky
> Assignee: Lin Gao
>
> It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
> It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}}
> After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6133) Add --connection-properties to datasource add command
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6133?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-6133:
--------------------------
Description:
It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}}
<pre>
After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase.
</pre>
was:After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase.
> Add --connection-properties to datasource add command
> -----------------------------------------------------
>
> Key: WFLY-6133
> URL: https://issues.jboss.org/browse/WFLY-6133
> Project: WildFly
> Issue Type: Task
> Components: CLI, JCA
> Reporter: Alexey Loubyansky
> Assignee: Lin Gao
>
> It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
> It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}}
> <pre>
> After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase.
> </pre>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6133) Add --connection-properties to datasource add command
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6133?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-6133:
--------------------------
Description:
It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}}
After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase.
was:
It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}}
<pre>
After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase.
</pre>
> Add --connection-properties to datasource add command
> -----------------------------------------------------
>
> Key: WFLY-6133
> URL: https://issues.jboss.org/browse/WFLY-6133
> Project: WildFly
> Issue Type: Task
> Components: CLI, JCA
> Reporter: Alexey Loubyansky
> Assignee: Lin Gao
>
> It isn't possible to add connection-properties using {{datasource add}} command. They can be added after the DS is created by directly working on {{/subsystem=datasources/data-source=XX/connection-properties}}
> It would be nice to have parameter --connection-properties in datasource add command. It could work the same way as {{xa-data-source add --name=DS --xa-datasource-properties=}}
> After WFCORE-1362 has been merged, a test for it has to be added to org.jboss.as.test.integration.management.cli.DataSourceTestCase.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months