April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6545) Add an attribute to the JSF subsystem to specify whether or not DOCTYPE declarations in JSF deployments should be disallowed

by Farah Juma (JIRA)

Farah Juma created WFLY-6545: -------------------------------- Summary: Add an attribute to the JSF subsystem to specify whether or not DOCTYPE declarations in JSF deployments should be disallowed Key: WFLY-6545 URL: https://issues.jboss.org/browse/WFLY-6545 Project: WildFly Issue Type: Feature Request Components: JSF Affects Versions: 10.0.0.Final Reporter: Farah Juma Assignee: Farah Juma When JAXP secure processing features are added to Xerces (i.e., once Ron Sigal's [Xerces PR|https://github.com/jboss/xerces/pull/12] is merged), WildFly will be using a {{SAXParserFactory}} implementation that disallows DOCTYPE declarations by default. This will cause a {{ServletException}} to occur when accessing any JSF .xhtml page that includes a DOCTYPE declaration. We should give users the option to override this default behaviour and allow DOCTYPE declarations for JSF apps, if desired. We can accomplish this as follows: 1) Add a "com.sun.faces.disallowDoctypeDecl" context parameter to Mojarra to explicitly specify whether or not DOCTYPE declarations should be allowed. * I've created [JAVASERVERFACES-4130|https://java.net/jira/browse/JAVASERVERFACES-4130] to track this and I've submitted a patch upstream to the Mojarra team. 2) Add a {{disallow-doctype-decl}} attribute to the JSF subsystem to specify the default value of the "com.sun.faces.disallowDoctypeDecl" context parameter for JSF apps. * I've implemented the changes required for this: https://github.com/fjuma/wildfly/commit/e6076549ea5c4b84a93dbe4ea0db9f8c2... If my patch for the new context parameter looks good to the Mojarra team, I can apply it to our Mojarra fork and submit a PR against WildFly with these changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBMETA-394) jboss-app_7_0.xsd imports jboss-common_6_0.xsd and application_6.xsd

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBMETA-394?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBMETA-394: -------------------------------------------- [~ehugonnet] if you have a set of DTD/XSD's with fixes and upstream wildfly don't want to fix theirs we should put these "fixed" DTD's/XSD's in a shared repo we could use. > jboss-app_7_0.xsd imports jboss-common_6_0.xsd and application_6.xsd > -------------------------------------------------------------------- > > Key: JBMETA-394 > URL: https://issues.jboss.org/browse/JBMETA-394 > Project: JBoss Metadata > Issue Type: Bug > Components: ear > Reporter: Rob Stryker > > The following xml code in eclipse fails the validate: > {code} > <?xml version="1.1" encoding="UTF-8"?> > <jboss-app version="7.0" xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:jee="http://www.jboss.com/xml/ns/javaee" > xsi:schemaLocation=" > http://www.jboss.com/xml/ns/javaee > http://www.jboss.org/schema/jbossas/jboss-app_7_0.xsd"> > <description>test</description> > </jboss-app> > {code} > The error is: cvc-complex-type.3.1: Value '7.0' of attribute 'version' of element 'jboss-app' is not valid with respect to > the corresponding attribute use. Attribute 'version' has a fixed value of '6'. > This is clearly caused by the intermingling of jee 7 with jee6 in the schemas. These schemas need to be cleaned up or our users will be experiencing errors all the time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBMETA-395) jboss-app:moduleType should use jee:moduleType as a base

by Rob Stryker (JIRA)

Rob Stryker created JBMETA-395: ---------------------------------- Summary: jboss-app:moduleType should use jee:moduleType as a base Key: JBMETA-395 URL: https://issues.jboss.org/browse/JBMETA-395 Project: JBoss Metadata Issue Type: Bug Components: ear Reporter: Rob Stryker While attempting to make a simple ear with a war and a service inside, we run into several validation errors continuously. The following xml, for example, fails to validate: {code} <?xml version="1.1" encoding="UTF-8"?> <jboss-app version="6" xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jbee="http://www.jboss.com/xml/ns/javaee" xmlns:jee="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation=" http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-app_7_0.xsd"> <jee:display-name>Test</jee:display-name> <jee:module> <jee:web> <jee:web-uri>myweb.war</jee:web-uri> <jee:context-root>SomeRoot</jee:context-root> </jee:web> <jbee:service>bundled.sar</jbee:service> </jee:module> <jbee:distinct-name>MyDistinct</jbee:distinct-name> </jboss-app> {code} The error is: cvc-complex-type.2.4.a: Invalid content was found starting with element 'jbee:service'. One of '{"http:// java.sun.com/xml/ns/javaee":alt-dd}' is expected. Basically, a jbee:service does not belong inside a jee:module. However, trying to declare jbee:module rather than jee:module fails because: cvc-complex-type.2.4.a: Invalid content was found starting with element 'jbee:module'. One of '{"http:// java.sun.com/xml/ns/javaee":display-name, "http://java.sun.com/xml/ns/javaee":icon, "http://java.sun.com/ xml/ns/javaee":initialize-in-order, "http://java.sun.com/xml/ns/javaee":module}' is expected. In short, jbee:moduleType should probably be using jee:moduleType as a base. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBMETA-394) jboss-app_7_0.xsd imports jboss-common_6_0.xsd and application_6.xsd

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBMETA-394?page=com.atlassian.jira.plugin... ] Rob Stryker commented on JBMETA-394: ------------------------------------ How much fixing did you do to the schema? And did you ever try to submit the fixes back upstream? > jboss-app_7_0.xsd imports jboss-common_6_0.xsd and application_6.xsd > -------------------------------------------------------------------- > > Key: JBMETA-394 > URL: https://issues.jboss.org/browse/JBMETA-394 > Project: JBoss Metadata > Issue Type: Bug > Components: ear > Reporter: Rob Stryker > > The following xml code in eclipse fails the validate: > {code} > <?xml version="1.1" encoding="UTF-8"?> > <jboss-app version="7.0" xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:jee="http://www.jboss.com/xml/ns/javaee" > xsi:schemaLocation=" > http://www.jboss.com/xml/ns/javaee > http://www.jboss.org/schema/jbossas/jboss-app_7_0.xsd"> > <description>test</description> > </jboss-app> > {code} > The error is: cvc-complex-type.3.1: Value '7.0' of attribute 'version' of element 'jboss-app' is not valid with respect to > the corresponding attribute use. Attribute 'version' has a fixed value of '6'. > This is clearly caused by the intermingling of jee 7 with jee6 in the schemas. These schemas need to be cleaned up or our users will be experiencing errors all the time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall

by George Turner (JIRA)

[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ] George Turner commented on WFLY-4769: ------------------------------------- Ok, you are on the track I am on. But I am on WildFly 10 and using artemis, not hornetq, and a lot of the class are changed. Can you give me that same example for a WF 10 server client? > WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-4769 > URL: https://issues.jboss.org/browse/WFLY-4769 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final > Environment: RedHat7 > Reporter: George Turner > Assignee: Jeff Mesnil > > Server is behind NAT firewall. Client code: > Properties topicProperties = new Properties(); > topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory"); > topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port); > InitialContext ctx = new InitialContext(topicProperties); > ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory"); > connection = tmp.createConnection(); > Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit> > INFO: XNIO version 3.3.1.Final > Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit> > INFO: XNIO NIO Implementation Version 3.3.1.Final > Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit> > INFO: JBoss Remoting version 4.0.9.Final > javax.jms.JMSException: Failed to create session factory > at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673) > at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112) > at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107) > at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36) > at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24) > Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.] > at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905) > at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669) > ... 4 more > Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket' > > Client debugger shows the ConnectionFactory instance returned: > initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183} > 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor" > name = {java.lang.String@2198} "http-connector" > factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory" > params = {java.util.HashMap@2200} size = 4 > 0 = {java.util.HashMap$Node@2203} "port" -> "8080" > 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77" > 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true" > 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor" > 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBMETA-394) jboss-app_7_0.xsd imports jboss-common_6_0.xsd and application_6.xsd

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/JBMETA-394?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet commented on JBMETA-394: ------------------------------------------ i 'fixed' them for the netbeans plugin as some of the code is generated from the schema http://hg.netbeans.org/web-main/file/b6047fd83b76/javaee.wildfly/src/org/... > jboss-app_7_0.xsd imports jboss-common_6_0.xsd and application_6.xsd > -------------------------------------------------------------------- > > Key: JBMETA-394 > URL: https://issues.jboss.org/browse/JBMETA-394 > Project: JBoss Metadata > Issue Type: Bug > Components: ear > Reporter: Rob Stryker > > The following xml code in eclipse fails the validate: > {code} > <?xml version="1.1" encoding="UTF-8"?> > <jboss-app version="7.0" xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:jee="http://www.jboss.com/xml/ns/javaee" > xsi:schemaLocation=" > http://www.jboss.com/xml/ns/javaee > http://www.jboss.org/schema/jbossas/jboss-app_7_0.xsd"> > <description>test</description> > </jboss-app> > {code} > The error is: cvc-complex-type.3.1: Value '7.0' of attribute 'version' of element 'jboss-app' is not valid with respect to > the corresponding attribute use. Attribute 'version' has a fixed value of '6'. > This is clearly caused by the intermingling of jee 7 with jee6 in the schemas. These schemas need to be cleaned up or our users will be experiencing errors all the time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBMETA-394) jboss-app_7_0.xsd imports jboss-common_6_0.xsd and application_6.xsd

by Rob Stryker (JIRA)

Rob Stryker created JBMETA-394: ---------------------------------- Summary: jboss-app_7_0.xsd imports jboss-common_6_0.xsd and application_6.xsd Key: JBMETA-394 URL: https://issues.jboss.org/browse/JBMETA-394 Project: JBoss Metadata Issue Type: Bug Components: ear Reporter: Rob Stryker The following xml code in eclipse fails the validate: {code} <?xml version="1.1" encoding="UTF-8"?> <jboss-app version="7.0" xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jee="http://www.jboss.com/xml/ns/javaee" xsi:schemaLocation=" http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-app_7_0.xsd"> <description>test</description> </jboss-app> {code} The error is: cvc-complex-type.3.1: Value '7.0' of attribute 'version' of element 'jboss-app' is not valid with respect to the corresponding attribute use. Attribute 'version' has a fixed value of '6'. This is clearly caused by the intermingling of jee 7 with jee6 in the schemas. These schemas need to be cleaned up or our users will be experiencing errors all the time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ELY-510) Adjust HttpServerRequest.getParameters() is it includes form parameters.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-510: ------------------------------------ Summary: Adjust HttpServerRequest.getParameters() is it includes form parameters. Key: ELY-510 URL: https://issues.jboss.org/browse/ELY-510 Project: WildFly Elytron Issue Type: Enhancement Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta6 Also add some methods to access headers by name - this will give opportunity at SPI integration point to provide optimised implementations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1496) rollback-across-groups completion

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1496: -------------------------------------------- Summary: rollback-across-groups completion Key: WFCORE-1496 URL: https://issues.jboss.org/browse/WFCORE-1496 Project: WildFly Core Issue Type: Feature Request Components: CLI Affects Versions: 3.0.0.Alpha1 Reporter: Jean-Francois Denise Assignee: Alexey Loubyansky rollout completion ignores the fact that the rollback-across-groups can be set to true or false. It does not propose true/false. That is fine. If one write rollback-across-groups=, there is no completion. If one write rollback-across-groups=t the completion is lost and the following completion is done: rollback-across-groups=tollback-across-groups So completion should better handle the rollback-across-groups= case. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (ELY-509) Multi Step HTTP Authentication

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-509: ------------------------------------ Summary: Multi Step HTTP Authentication Key: ELY-509 URL: https://issues.jboss.org/browse/ELY-509 Project: WildFly Elytron Issue Type: Enhancement Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta7 This is a variation of FORM authentication and closely related to ELY-508. The scenario would be prompt for a username, then prompt for a password and if the password is valid and the account supports OTP prompt for the OTP. The mechanism may also be responsible for sending the OTP but that is probably a side topic. I have raised this in terms of being a HTTP mechanism but the main point we need to ensure is covered is the requirements about identifying what checks are required for a specific user and tracking they are all complete. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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 April 2016