August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-457) Replace mod_cluster proxy-list attribute with list of outbound socket bindings

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-457?page=com.atlassian.jira.plugin.s... ] Radoslav Husar updated WFLY-457: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.CR1) > Replace mod_cluster proxy-list attribute with list of outbound socket bindings > ------------------------------------------------------------------------------ > > Key: WFLY-457 > URL: https://issues.jboss.org/browse/WFLY-457 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > Fix For: 9.0.0.Beta1 > > > Currently, the mod_cluster subsystem defines proxies using a comma separated string of address:port. This attribute needs to be deprecated in favor of an attribute, call it "proxies" that defines an xs:list of outbound socket binding names. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-47) NFKC normalization in StringPrep is not in accordance with RFC

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-47?page=com.atlassian.jira.plugin.sys... ] David Lloyd commented on ELY-47: -------------------------------- OK good :) I was very worried we'd have to implement normalization ourselves - something that I dread :) > NFKC normalization in StringPrep is not in accordance with RFC > -------------------------------------------------------------- > > Key: ELY-47 > URL: https://issues.jboss.org/browse/ELY-47 > Project: WildFly Elytron > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Jan Kalina > Assignee: Darran Lofthouse > > StringPrep from utils use java.text.Normalizer to NFKC normalization. But this normalization is not in accordance with RFC 3454 - see mapping table: > http://tools.ietf.org/html/rfc3454#appendix-B.2 > Relevant profile description: > http://tools.ietf.org/html/rfc3454#section-3.2 > Full test is part of [pull request 13|https://github.com/wildfly-security/wildfly-sasl/pull/13], but for basic testing can be used this simple test: > {code:java} > @Test > public void testNormalizationWithNFKC(){ > ByteStringBuilder b = new ByteStringBuilder(); > String before = "\u0041\u0042\u0043\u0044\u0045\u0046\u0047"; > String after = "\u0061\u0062\u0063\u0064\u0065\u0066\u0067"; > StringPrep.encode(before, b, StringPrep.NORMALIZE_KC); > assertEquals(after, new String(b.toArray())); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-47) NFKC normalization in StringPrep is not in accordance with RFC

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-47?page=com.atlassian.jira.plugin.sys... ] Jan Kalina commented on ELY-47: ------------------------------- No, I created new test and I understood wrong meaning of NORMALIZE_KC profile. This profile correctly do NFKC normalization, but I think it should do also case folding. (I overlooked "4. Normalization" and found KC normalization only in "3.2 Case folding" in RFC) StringPrep in OK (except other problems fixed in pull request 13), only my test (part of same pull request) was wrong (also fixed). Thread can be closed. > NFKC normalization in StringPrep is not in accordance with RFC > -------------------------------------------------------------- > > Key: ELY-47 > URL: https://issues.jboss.org/browse/ELY-47 > Project: WildFly Elytron > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Jan Kalina > Assignee: Darran Lofthouse > > StringPrep from utils use java.text.Normalizer to NFKC normalization. But this normalization is not in accordance with RFC 3454 - see mapping table: > http://tools.ietf.org/html/rfc3454#appendix-B.2 > Relevant profile description: > http://tools.ietf.org/html/rfc3454#section-3.2 > Full test is part of [pull request 13|https://github.com/wildfly-security/wildfly-sasl/pull/13], but for basic testing can be used this simple test: > {code:java} > @Test > public void testNormalizationWithNFKC(){ > ByteStringBuilder b = new ByteStringBuilder(); > String before = "\u0041\u0042\u0043\u0044\u0045\u0046\u0047"; > String after = "\u0061\u0062\u0063\u0064\u0065\u0066\u0067"; > StringPrep.encode(before, b, StringPrep.NORMALIZE_KC); > assertEquals(after, new String(b.toArray())); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-70) Revisit redirect tests in HTTPSManagementInterfaceTestCase

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-70: -------------------------------------- Summary: Revisit redirect tests in HTTPSManagementInterfaceTestCase Key: WFCORE-70 URL: https://issues.jboss.org/browse/WFCORE-70 Project: WildFly Core Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management, Test Suite Reporter: Brian Stansberry See discussion at https://github.com/wildfly/wildfly-core/pull/120 HTTPSManagementInterfaceTestCase includes tests of how http/https redirects are handled by the http interface logic. But it seems that every time some variant of SSLException is thrown, which largely defeats the point of the tests. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3775) @TransactionAttribute ignored on non-public methods.

by Sławomir Wojtasiak (JIRA)

Sławomir Wojtasiak created WFLY-3775: ---------------------------------------- Summary: @TransactionAttribute ignored on non-public methods. Key: WFLY-3775 URL: https://issues.jboss.org/browse/WFLY-3775 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 8.1.0.Final Environment: SunOS, JDK1.7. Reporter: Sławomir Wojtasiak Assignee: David Lloyd Priority: Minor Currently @TransactionAttribute annotations are allowed only on public methods. It seems to be a reasonable rule because components are accesses by their public interfaces and session beans can be also accessed by a no-interface view that exposes all public methods of the bean class. Nevertheless in case of singletons @PostConstruct and @PreDestroy annotations can be applied to protected methods for instance. In such a case transaction attributes are silently ignored. (org.jboss.as.ejb3.component.EJBComponentCreateService:147) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3269) XML parsing mandating the 'force' attribute on username-to-dn even though it has a default value.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3269?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3269: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 1133961|https://bugzilla.redhat.com/show_bug.cgi?id=1133961] from ASSIGNED to POST > XML parsing mandating the 'force' attribute on username-to-dn even though it has a default value. > ------------------------------------------------------------------------------------------------- > > Key: WFLY-3269 > URL: https://issues.jboss.org/browse/WFLY-3269 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Emmanuel Hugonnet > Fix For: 9.0.0.Beta1 > > > {code} > Trying so, I run in the error (when starting WildFly) : > 10:28:29,674 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[76,25] > Message: JBAS014724: Missing required attribute(s): FORCE > at org.jboss.as.controller.parsing.ParseUtils.missingRequired(ParseUtils.java:134) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final] > at org.jboss.as.domain.management.parsing.ManagementXml.parseUsernameToDn_2_0(ManagementXml.java:2118) [wildfly-domain-management-8.0.0.Final.jar:8.0.0.Final] > {code} > {code} > <security-realm name="MgtRealm"> > <authentication> > <ldap connection="ovodavLDAP" base-dn="ou=People,dc=hydrogenic,dc=local"> >  > <username-filter attribute="uid"/> > </ldap> > </authentication> > <authorization> > <ldap connection="ovodavLDAP"> > <username-to-dn> > <username-filter base-dn="ou=People,dc=hydrogenic,dc=local" recursive="false" attribute="uid" user-dn-attribute="dn" /> > </username-to-dn> > <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid"> > <group-to-principal base-dn="ou=Groups,dc=hydrogenic,dc=local" recursive="true" search-by="DISTINGUISHED_NAME"> > <membership-filter principal-attribute="uniqueMember" /> > </group-to-principal> > </group-search> > </ldap> > </authorization> > </security-realm> > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3758) Unable to run JSF applications deployed to "/"

by Ken H (JIRA)

[ https://issues.jboss.org/browse/WFLY-3758?page=com.atlassian.jira.plugin.... ] Ken H closed WFLY-3758. ----------------------- Resolution: Rejected Withdrawn. I was unable to reproduce the behavior in a sample project until Rewrite/PrettyFaces was introduced to the JSF project. This was a bug in the Rewrite 2.0.12 servlet that has been addressed in 3.0.0.Alpha3. > Unable to run JSF applications deployed to "/" > ----------------------------------------------- > > Key: WFLY-3758 > URL: https://issues.jboss.org/browse/WFLY-3758 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF, Web (Undertow) > Affects Versions: 9.0.0.Beta1 > Environment: WildFly master at 50a830205c, JDK 1.7 > Reporter: Ken H > Assignee: Tomaz Cerar > > I don't think the patch in pull request 6338 is right. I experienced the issue defined in WLFY-3448 on 8.1.0.Final, then built master at 50a830205c and the new behavior is different but still broken. Now requests to http://host/login throws a Not Found, the server is expecting http://host//login (which explodes because it isn't valid). If I hit http://host then the redirect is generated to http://host//welcome because httpServletRequest.getContextPath() is returning "/" (when it was returning an empty string in 7.x). > From web.xml: > {code} > <welcome-file-list> > <welcome-file>/</welcome-file> > </welcome-file-list> > {code} > From jboss-web.xml: > {code} > <jboss-web> > <context-root>/</context-root> > </jboss-web> > {code} > My app is packaged as a war, so no application.xml exists to define context-root. > I would say this is a regression caused by the resolution to WLFY-3448 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped

by Claudio Illanes (JIRA)

[ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.... ] Claudio Illanes commented on WFLY-3149: --------------------------------------- I found that manually running ""jboss-cli.bat --controller=localhost:9990 --connect --command=:shutdown" did not shut the service down. To fix this install issue: 1. I went to the command line and ran "wildfly-mgr.exe //ES//Wildfly" 2. Visited the shutdown tab and realized that my wildfly install doesn't respond to localhost:9990. I changed "localhost" to my server IP, saved the change, and I was then able to stop the service from the command line. I guess my Wildfly setup is not permitting localhost:9990 to be reached. > Windows service on 64 bit systems cannot be stopped > --------------------------------------------------- > > Key: WFLY-3149 > URL: https://issues.jboss.org/browse/WFLY-3149 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Scripts > Affects Versions: 8.0.0.Final > Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09 > Reporter: Mohan Potturi > Assignee: Mladen Turk > > The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1014) DataSource class is never picked for establishing connection, driverClass is always picked.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1014?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1014: ------------------------------------------------ Martin Simka <msimka(a)redhat.com> changed the Status of [bug 957175|https://bugzilla.redhat.com/show_bug.cgi?id=957175] from NEW to CLOSED > DataSource class is never picked for establishing connection, driverClass is always picked. > ------------------------------------------------------------------------------------------- > > Key: JBJCA-1014 > URL: https://issues.jboss.org/browse/JBJCA-1014 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JDBC > Affects Versions: 1.0.13.Final > Environment: Windows-7, JBoss AS-7.1, SQL Server, JDK-1.7.0 > Reporter: Himanshu Bhardwaj > Assignee: Jesper Pedersen > Labels: JDBC > > Use Case: Implemented a custom datasource for some extension purposes over sqljdbc4.jar (JDBC-4 compliant). > Now when configuring the datasource, the module was loaded successfully, the configuration used in standalone.xml: > <datasource jta="true" jndi-name="java:jboss/datasources/ejb/testdbjndi" pool-name="test-cluster-Pool" enabled="true" use-java-context="true" use-ccm="false"> > <connection-url>jdbc:sqlserver://localhost:1433;databaseName=cm-6.5;</connection-url> > <datasource-class>com.himanshu.jdbcdriver.datasource.DataSource</datasource-class> > <connection-property name="serverName"> >  > </connection-property> > <driver>test-jdbc</driver> > <new-connection-sql>SET DATEFIRST 1</new-connection-sql> > <pool> > <min-pool-size>10</min-pool-size> > <max-pool-size>100</max-pool-size> > <prefill>false</prefill> > </pool> > <security> > <user-name>sa</user-name> > <password>sa</password> > </security> > <statement> > <prepared-statement-cache-size>32</prepared-statement-cache-size> > <share-prepared-statements>true</share-prepared-statements> > </statement> > </datasource> > <driver name="test-jdbc" module="com.himanshu.jdbc"/> > Now on doing testing the connections were successfully established and queries were getting executed. > But it turns out the my custom datasource class is not used, rather the connection is made via driverClass, DriverManager.getConnection() kind of method. > On debugging code for ironjacamar: > > org.jboss.ironjacamar > ironjacamar-jdbc > 1.0.13.Final-redhat-1 > On looking code for "org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory", it turns out that both the driverClass property (META-INF/services/java.sql.driver file) and dataSourceClass property (from standalone.xml) is read. > Now the way connection is made is bit confusing here. > Looking into method: private LocalManagedConnection getLocalManagedConnection(Properties props, Properties copy); in class > "LocalManagedConnectionFactory" > private LocalManagedConnection getLocalManagedConnection(Properties props, Properties copy) > throws ResourceException > { > Connection con = null; > try > { > if (driverClass != null) > { > String url = getConnectionURL(); > Driver d = getDriver(url); > con = d.connect(url, copy); > if (con == null) > throw new ResourceException("Wrong driver class [" + d.getClass() + "] for this connection URL [" + > url + "]"); > } > else > { > DataSource d = getDataSource(); > con = d.getConnection(copy.getProperty("user"), copy.getProperty("password")); > if (con == null) > throw new ResourceException("Unable to create connection from datasource"); > } > return new LocalManagedConnection(this, con, props, transactionIsolation, preparedStatementCacheSize); > } > catch (Throwable e) > { > if (con != null) > { > try > { > con.close(); > } > catch (Throwable ignored) > { > // Ignore > } > } > throw new ResourceException("Could not create connection", e); > } > } > Now the if-else block condition here is difficult to understand: > If I have driverClass available then all the connections are made via driverClass property, even if I mention datasourceClass or not. > This is because the first if condition always checks for driverClass the dataSourceClass check never executes. > So the question is how this can be avoided, becuase the DriverClass is picked automatically from the java.sql.driver file (being JDBC-4 compliant). > If there is no configuration for the same for giving priority to datasource class or explicitly setting the driver class to null, then definitely something's amiss. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-637) DataSource support

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-637?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBJCA-637: ----------------------------------------------- Martin Simka <msimka(a)redhat.com> changed the Status of [bug 957175|https://bugzilla.redhat.com/show_bug.cgi?id=957175] from NEW to CLOSED > DataSource support > ------------------ > > Key: JBJCA-637 > URL: https://issues.jboss.org/browse/JBJCA-637 > Project: IronJacamar > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Common, Deployer, JDBC > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.2.Final, 1.1.0.Alpha1 > > > We should support <datasource> deployments based on a javax.sql.DataSource instance. > Add <datasource-class> to <datasource> and <driver> as optional. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2014