February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBXB-89) JBossXB automatically unzips gzipped content when decoding base64 data.

by Darran Lofthouse (JIRA)

JBossXB automatically unzips gzipped content when decoding base64 data. ----------------------------------------------------------------------- Key: JBXB-89 URL: http://jira.jboss.com/jira/browse/JBXB-89 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-1.0.0.CR7 Reporter: Darran Lofthouse Fix For: JBossXB-1.0 JBossXB automatically unzips gzipped content when decoding base64 data. The reason why it is automatically unzipped is becuase the method unmarshalBase64 in org.jboss.xb.binding.SimpleTypeBindings is calling the method decode in org.jboss.util.Base64, this decode method after converting from Base64 detects that it is gzipped so unzippes it. If we do not need to unzip the data we could call the decode method that takes the byte array instead of a String as this does not perform any unzipping. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-383) XML Marshaling/Unmarshling code performs no normalisation on name values used to create XML/DOM element nodes.

by Tom Fennelly (JIRA)

XML Marshaling/Unmarshling code performs no normalisation on name values used to create XML/DOM element nodes. -------------------------------------------------------------------------------------------------------------- Key: JBESB-383 URL: http://jira.jboss.com/jira/browse/JBESB-383 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 CR2 Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 4.0 Maintenance Pack 1 An example of this can be seen in org.jboss.internal.soa.esb.message.format.xml.BodyImpl.toXML(Element) where the body attachment keys are used as the container element name. What if someone saves an attachment that contains special/unsupported chars?? This is very possible! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
5
0 / 0

[JBoss JIRA] Commented: (JGRP-130) Problems with reincarnation

by Anton Melser (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12352399 ] Anton Melser commented on JGRP-130: ----------------------------------- Is there an ETA on this functionality/2.6? > Problems with reincarnation > --------------------------- > > Key: JGRP-130 > URL: http://jira.jboss.com/jira/browse/JGRP-130 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.6 > > > Problems with reincarnation > =========================== > Author: Bela Ban > Version: $Id$ > The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless > bind_port is set (not set by default). > Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a > higher port, say 5002. This depends on how many other processes requested a port in between the start and restart > of the member. > JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically) > *increasing* across a single machine. If this is not the case, then the following problems can occur: > 1. Restart: > When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded, > then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table), > retransmission requests sent to the new P will fail. > 2. Shunning: > Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of > those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have > processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time, > when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so > they could assume each other's identity ! > Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a > new process and in case #2, the list is process-wide, but not machine-wide. > Again, these problems occur *only* when the OS reuses previously assigned ports. > SOLUTION: > A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we > don't reuse previous addresses > B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host. > Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity. > The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBAS-3265) Problem with empty classname in classloader

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3265?page=all ] Scott M Stark resolved JBAS-3265. --------------------------------- Fix Version/s: JBossAS-5.0.0.Beta2 Resolution: Done Reject null or empty class names with a CNFE > Problem with empty classname in classloader > ------------------------------------------- > > Key: JBAS-3265 > URL: http://jira.jboss.com/jira/browse/JBAS-3265 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX > Affects Versions: JBossAS-4.0.4.GA > Reporter: Adrian Brock > Assigned To: Scott M Stark > Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1 > > > The RepositoryClassLoader doesn't handle empty classnames correctly. > It eventually breaks when it tries to do the array name handling here: > // If this is an array class, use Class.forName to resolve it > if( name.charAt(0) == '[' ) > { > result = Class.forName(name, true, this); > removeFromClassBlackList(name); > return result; > } > 17:04:42,858 ERROR [STDERR] java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > 17:04:42,860 ERROR [STDERR] at java.lang.String.charAt(String.java:444) > 17:04:42,861 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassLocally(RepositoryClassLoader.java:169) > 17:04:42,862 ERROR [STDERR] at org.jboss.mx.loading.UnifiedLoaderRepository3.loadClassFromClassLoader(UnifiedLoaderRepository3.java:263) > 17:04:42,862 ERROR [STDERR] at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:270) > 17:04:42,864 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:475) > 17:04:42,865 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:377) > 17:04:42,865 ERROR [STDERR] at java.lang.ClassLoader.loadClass(ClassLoader.java:235) > The classloader should just reject a null or empty ("") classname in loadClass() > with a meaningful error message. > I suspect the null is handled by the cache since the cache is a Concurrent HashMap > which won't accept null as a key. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBAS-2249) Cleanup the org.jboss.naming packaging

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2249?page=all ] Scott M Stark resolved JBAS-2249. --------------------------------- Resolution: Done The NamingService is no longer needed. A protocol independent service can be created using just the NamingBeanImpl: <mbean code="org.jnp.server.NamingBeanImpl" name="jboss:service=NamingBeanImpl" xmbean-dd="resource:xmdesc/NamingBean-xmbean.xml"> </mbean> > Cleanup the org.jboss.naming packaging > -------------------------------------- > > Key: JBAS-2249 > URL: http://jira.jboss.com/jira/browse/JBAS-2249 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build System, Naming > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-4.2.0.CR1 > > > Trying to use the jndi naming service in a minimal configuration requires the full jboss.jar. The naming classes should just be merged into the naming module and jnpserver.jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBAS-2523) Add a multi-thread option to JndiLoginInitialContextFactory.

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2523?page=all ] Scott M Stark resolved JBAS-2523. --------------------------------- Resolution: Done jnp.multi-threaded and jnp.restoreLoginIdentity options have been added. The more general approach needs to be looked at for jboss5. > Add a multi-thread option to JndiLoginInitialContextFactory. > ------------------------------------------------------------ > > Key: JBAS-2523 > URL: http://jira.jboss.com/jira/browse/JBAS-2523 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-4.2.0.CR1 > > > The JndiLoginInitialContextFactory just uses the SecurityAssociation in whatever threading mode its configured for and has no multi-threaded option like the ClientLoginModule does. One should be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4030) make standard containers extend IPT

by Alexey Loubyansky (JIRA)

make standard containers extend IPT ----------------------------------- Key: JBAS-4030 URL: http://jira.jboss.com/jira/browse/JBAS-4030 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: CMP service Affects Versions: JBossAS-5.0.0.Beta1 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossAS-5.0.0.Beta2 This issue is related to CTS. Standard containers should be based on IPT to avoid self-deadlocking in some of the CTS tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
1
0 / 0

Vacaciones con muchos gastos?

by FonoIP

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-382) XML Marshaling/Unmarshling code uses the namespace prefix for performing namespace checking.

by Tom Fennelly (JIRA)

XML Marshaling/Unmarshling code uses the namespace prefix for performing namespace checking. -------------------------------------------------------------------------------------------- Key: JBESB-382 URL: http://jira.jboss.com/jira/browse/JBESB-382 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 CR2 Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 4.0 Maintenance Pack 1 Parsers and serialisers need to be namespace aware and check against the full namespace URI. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4051) Support the org.jboss.cache.aop marker interfaces for FIELD granularity pojos

by Brian Stansberry (JIRA)

Support the org.jboss.cache.aop marker interfaces for FIELD granularity pojos ----------------------------------------------------------------------------- Key: JBAS-4051 URL: http://jira.jboss.com/jira/browse/JBAS-4051 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-4.2.0.CR1 The PojoCache examples use these; we should support them to be consistent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
1
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 February 2007