October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1723) Corrupted input stream on STATE exchange

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1723?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1723: -------------------------------- Looks like only STATE.buffer_size bytes are written to the BlockingInputStream at the receiver (even though 1'000'000 bytes are received). > Corrupted input stream on STATE exchange > ---------------------------------------- > > Key: JGRP-1723 > URL: https://issues.jboss.org/browse/JGRP-1723 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3.4, 3.4 > Environment: java7u25 > Reporter: Mathieu Bernatet > Assignee: Bela Ban > Fix For: 3.5 > > Attachments: corruptedStreamOnStateExchange.zip > > > Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream. > I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2. > Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exch... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes on authentication

by Julien Derveeuw (JIRA)

Julien Derveeuw created JBASMP-58: ------------------------------------- Summary: jboss-as-maven-plugin freezes on authentication Key: JBASMP-58 URL: https://issues.jboss.org/browse/JBASMP-58 Project: JBoss AS Maven Plugins Issue Type: Bug Components: deploy Affects Versions: 7.5.Final Environment: mac os x 10.8.5 Reporter: Julien Derveeuw Assignee: James Perkins Priority: Critical I have jboss 7.1.1 in standalone mode running on machine A (linux). I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18. If I connect from B to A using jboss-cli, everything works fine, I am able to login. If I try to deploy from maven with this : <plugin> <groupId>org.jboss.as.plugins</groupId> <artifactId>jboss-as-maven-plugin</artifactId> <version>7.5.Final</version> <configuration> <hostname>${deploy.jboss.host}</hostname> <port>${deploy.jboss.port}</port> <username>${deploy.jboss.user}</username> <password>${deploy.jboss.password}</password> </configuration> <executions> <execution> <phase>install</phase> <goals> <goal>deploy</goal> </goals> </execution> </executions> plugin freezes indefinitely on Authenticating against security realm: ManagementRealm No more details are available with mvn -X If I remove the password or username from pom, it fails correctly with : The connection failed: Authentication failed: all available authentication mechanisms failed After digging on google, I ended up adding -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider to mvn runner options because NIOs on jdk7@macosx is said to be buggy but it didn't help. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation dependency on JBoss Web - Provided

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-760: -------------------------------------------------- sgilda(a)redhat.com made a comment on [bug 1022679|https://bugzilla.redhat.com/show_bug.cgi?id=1022679] What is the current status of this bug? I'm still getting Jenkins build errors. > Make the JBoss Negotiation dependency on JBoss Web - Provided > ------------------------------------------------------------- > > Key: SECURITY-760 > URL: https://issues.jboss.org/browse/SECURITY-760 > Project: PicketBox > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_6 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-764) Move JBoss Negotiation to GIT

by Darran Lofthouse (JIRA)

Darran Lofthouse created SECURITY-764: ----------------------------------------- Summary: Move JBoss Negotiation to GIT Key: SECURITY-764 URL: https://issues.jboss.org/browse/SECURITY-764 Project: PicketBox Issue Type: Task Security Level: Public (Everyone can see) Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2_2_7 Updates to JBoss Negotiation how now slowed down considerably, time to get it moved over to git so that for ongoing maintenance it is in a repository consistent with the project making use of it. https://github.com/wildfly/jboss-negotiation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2319) LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2319: ----------------------------------------------- emartins(a)redhat.com made a comment on [bug 1014911|https://bugzilla.redhat.com/show_bug.cgi?id=1014911] Have you tried to use String base = "dc=sample,dc=com"; ? ldap:// names are to be used with no environment properties map, and the handling of such jndi names is mostly what we are fixing here, so proper names for LdapCtxFactory should work at the moment. Here is an example of proper usage on Oracle JNDI LDAP docs: http://docs.oracle.com/javase/jndi/tutorial/basics/directory/src/SearchRe... > LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-2319 > URL: https://issues.jboss.org/browse/WFLY-2319 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.Beta1 > Reporter: Darran Lofthouse > Assignee: Eduardo Martins > Fix For: 8.0.0.CR1 > > Attachments: LdapSearching.tgz > > > The following code: - > {code} > Hashtable env = new Hashtable(); > env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory"); > env.put("java.naming.security.authentication", "simple"); > env.put("java.naming.provider.url", "ldap://localhost:10389"); > env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system"); > env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret"); > SearchControls ctl = null; > String attrArr[] = new String[1]; > attrArr[0] = "sn"; > ctl = new SearchControls(2, 0L, 0, attrArr, false, false); > String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org"; > String filter = "(uid=UserOne)"; > NamingEnumeration nenum = null; > DirContext ictx = null; > ictx = new InitialDirContext(env); > nenum = ictx.search(base, filter, ctl); > {code} > Results in the following exception: - > {noquote} > 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org' > 13:03:45,599 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025) > 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840) > 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034) > {noquote} > Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works. > The underlying issue is that the default InitialContext implementation contains the following method: - > {code} > protected Context getURLOrDefaultInitCtx(String name) > throws NamingException { > if (NamingManager.hasInitialContextFactoryBuilder()) { > return getDefaultInitCtx(); > } > String scheme = getURLScheme(name); > if (scheme != null) { > Context ctx = NamingManager.getURLContext(scheme, myProps); > if (ctx != null) { > return ctx; > } > } > return getDefaultInitCtx(); > } > {code} > As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2391) Wildfly caches content in exploded mode, breaking developer productivity

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-2391: --------------------------------- Workaround Description: Delete the <buffer-cache> element from the undertow subsystem, and also remove the default-buffer-cache="default" element from the servlet container. (was: Delete the <buffer-cache> element from the undertow subsystem.) > Wildfly caches content in exploded mode, breaking developer productivity > ------------------------------------------------------------------------ > > Key: WFLY-2391 > URL: https://issues.jboss.org/browse/WFLY-2391 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Beta1 > Environment: MacOSX with JBossTools 4.1.1.Beta1 > Reporter: Xavier Coulon > Assignee: Stuart Douglas > Attachments: jboss-as-kitchensink-html5-mobile.war.zip > > > While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools). > > I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-) > I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers. > > I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved. > I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue. > At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1724) GMS: join and immediate leave of coordinator doesn't install new view

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1724?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1724. ---------------------------- Resolution: Done > GMS: join and immediate leave of coordinator doesn't install new view > --------------------------------------------------------------------- > > Key: JGRP-1724 > URL: https://issues.jboss.org/browse/JGRP-1724 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4.1, 3.5 > > > When we have coord A and B, the following can happen: > * A joins: view=A|0 > * B joins: view=A|1 > * A leaves, view B|2 should be multicast by A to B > --> B|2 is never received by B. B has to wait until failure detection detects that A is absent and installs a new view > --> This is not incorrect, but takes more time than A installing the last view B|2 before it leaves > The reason is that CoordGmsImpl.leave() sets {{leaving}} to true, which changes the impl from CoordGmsImpl to ClientGmsImpl. However, the latter doesn't handle the LEAVE request. > SOLUTION: > * Instead of using field {{leaving}}, use a (stack-based) variable {{is_leaving}} in handleMembershipChange(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2276) URI ENCODING does not work in the beta1 version (UTF-8)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-2276: ------------------------------ Fix Version/s: 8.0.0.CR1 > URI ENCODING does not work in the beta1 version (UTF-8) > ------------------------------------------------------- > > Key: WFLY-2276 > URL: https://issues.jboss.org/browse/WFLY-2276 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Beta1 > Environment: Java 7, ubuntu 12.04 > Reporter: alexandre xypas > Assignee: Tomaz Cerar > Labels: encoding, utf-8 > Fix For: 8.0.0.CR1 > > > In standalone.xml, the following is working in Alpha4, but not anymore in Beta1. > <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/> > <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2391) Wildfly caches content in exploded mode, breaking developer productivity

by Chris R. (JIRA)

[ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.... ] Chris R. commented on WFLY-2391: -------------------------------- I removed <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/> I'm unable to deploy my projects now: 11:27:20,808 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "foo_frontend.war")]) - failure description: {"JBAS014879: One or more services were unable to start due to one or more indirect dependencies not being available." => { "Services that were unable to start:" => ["jboss.deployment.unit.\"foo_frontend.war\".INSTALL"], "Services that may be the cause:" => [ "jboss.remoting.remotingConnectorInfoService.http-remoting-connector", "jboss.undertow.bufferCache.default" ] }} > Wildfly caches content in exploded mode, breaking developer productivity > ------------------------------------------------------------------------ > > Key: WFLY-2391 > URL: https://issues.jboss.org/browse/WFLY-2391 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Beta1 > Environment: MacOSX with JBossTools 4.1.1.Beta1 > Reporter: Xavier Coulon > Assignee: Stuart Douglas > Attachments: jboss-as-kitchensink-html5-mobile.war.zip > > > While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools). > > I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-) > I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers. > > I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved. > I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue. > At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2403) Cannot disable Datasource or XADatasource in standalone and domain modes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2403: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=970679 > Cannot disable Datasource or XADatasource in standalone and domain modes > ------------------------------------------------------------------------ > > Key: WFLY-2403 > URL: https://issues.jboss.org/browse/WFLY-2403 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > Description of problem: > Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload. > Version-Release number of selected component (if applicable): > 6.1 > How reproducible: > Always > Steps to Reproduce: > Use the http management interface or the CLI > 1.Create a Datasource of XADatasource > 2.Disable it > 3.The response indicates a server reload is required > 4.Execute the reload operation > Actual results: > The datasource is back to enabled state > Expected results: > The datasource should be in disabled state -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

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 October 2013