November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-743) Remove Multiplexer, MuxChannel

by Bela Ban (JIRA)

Remove Multiplexer, MuxChannel ------------------------------ Key: JGRP-743 URL: http://jira.jboss.com/jira/browse/JGRP-743 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 3.0 Replaced by shared transport -- 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

13 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-513) Remove deprecated system properties (non 'jboss' namespace)

by Brian Stansberry (JIRA)

Remove deprecated system properties (non 'jboss' namespace) ----------------------------------------------------------- Key: JGRP-513 URL: http://jira.jboss.com/jira/browse/JGRP-513 Project: JGroups Issue Type: Task Reporter: Brian Stansberry Assigned To: Bela Ban Priority: Minor As discussed on http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps there are a number of deprecated, 'legacy' system properties. This is just a JIRA entry to track remembering to clean them up. This JIRA is for the non-'jboss' namespaced properties, which perhaps we would keep around longer than the 'jboss' ones. -- 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

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-512) Remove support for deprecated 'jboss' namespaced system properties

by Brian Stansberry (JIRA)

Remove support for deprecated 'jboss' namespaced system properties ------------------------------------------------------------------ Key: JGRP-512 URL: http://jira.jboss.com/jira/browse/JGRP-512 Project: JGroups Issue Type: Task Reporter: Brian Stansberry Assigned To: Bela Ban Priority: Minor As discussed on http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps there are a number of deprecated, 'legacy' system properties. This is just a JIRA entry to track remembering to clean them up. I'm creating a separate JIRA for the non-'jboss' namespaced properties. Use of the 'jboss' namespace isn't too good, so it might be justified removing those earlier, e.g. 2.5, so users won't use them in AS 5.x and expect them to work. -- 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

13 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JGRP-694) Convert documentation to new DocBook format

by Richard Achmatowicz (JIRA)

Convert documentation to new DocBook format ------------------------------------------- Key: JGRP-694 URL: http://jira.jboss.com/jira/browse/JGRP-694 Project: JGroups Issue Type: Task Reporter: Richard Achmatowicz Assigned To: Bela Ban Fix For: 2.7 Convert existing JGroups documentation shipped with the release to the new DocBook format. -- 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

13 years, 9 months

3
4
0 / 0

[JBoss JIRA] Created: (JGRP-563) Consolidate state transfer API to use streams

by Vladimir Blagojevic (JIRA)

Consolidate state transfer API to use streams --------------------------------------------- Key: JGRP-563 URL: http://jira.jboss.com/jira/browse/JGRP-563 Project: JGroups Issue Type: Task Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 3.0 Although streaming state transfer has its advantages over byte based state transfer, byte based state transfer is absolutely necessary since streaming based transfer relies on plain sockets that are not firewall friendly. However, that does not mean that we cannot consolidate state transfer API at application level and mask byte based transfer with streams. We have already done this in JBC 2.0 so there is no reason not to do it on JGroups level as well. Advantages: - simpler state transfer API - interchangeable state transfer mechanism without affect on application - simplification of client application Disadvantages: - we break current API by eliminating getState(byte[]) and setState(byte []) -- 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

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-567) Add one shot state transfer for multiple substates

by Vladimir Blagojevic (JIRA)

Add one shot state transfer for multiple substates -------------------------------------------------- Key: JGRP-567 URL: http://jira.jboss.com/jira/browse/JGRP-567 Project: JGroups Issue Type: Feature Request Affects Versions: 2.x Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Currently (2.5) each sub state transfer requires separate state transfer invocation for each sub state. It would be very convenient if we could transfer a list of substates all in one underlying state transfer. This would require introduction of a new method in JChannel API, however we should avoid additional callbacks on application level. Proposed API for additional JChannel method is: public boolean getState(Address target, List<String> state_ids, long timeout) throws ChannelNotConnectedException, ChannelClosedException; -- 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

13 years, 9 months

2
9
0 / 0

[JBoss JIRA] Created: (JBWEB-107) Cross Domain JSESSIONID Cookie

by Mike Millson (JIRA)

Cross Domain JSESSIONID Cookie ------------------------------ Key: JBWEB-107 URL: http://jira.jboss.com/jira/browse/JBWEB-107 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tomcat Module Reporter: Mike Millson Assigned To: Mladen Turk Currently the JSESSIONID cookie domain is set to the domain name of the Host that emits the cookie (e.g. www.domain.com). This is an issue with customers using Aliases (e.g. secure.domain.com, zzz.domain.com, etc.), as the session is lost when switching between the main domain and any aliases. In these cases, it would be useful to be able to specify the domain to be "domain.com" so the same JSESSIONID cookie is used across the aliases and converges to the same session. -- 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

13 years, 9 months

3
9
0 / 0

[JBoss JIRA] Created: (SECURITY-31) White Paper on JMX Security

by Anil Saldhana (JIRA)

White Paper on JMX Security --------------------------- Key: SECURITY-31 URL: http://jira.jboss.com/jira/browse/SECURITY-31 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: White Papers Reporter: Anil Saldhana Assigned To: Anil Saldhana There is a need for a simple technical white paper that talks about the various scenarios involved in security jmx in JBoss. This includes the jmx consoles as well as the invokers. -- 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

13 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBWEB-95) Provide a com.sun.net.httpserver.HttpServerProvider implementation

by Scott M Stark (JIRA)

Provide a com.sun.net.httpserver.HttpServerProvider implementation ------------------------------------------------------------------ Key: JBWEB-95 URL: http://jira.jboss.com/jira/browse/JBWEB-95 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tomcat Module Reporter: Scott M Stark Assigned To: Mladen Turk To plug jbossweb into jdk6, we need a com.sun.net.httpserver.HttpServerProvider implementation http://java.sun.com/javase/6/docs/jre/api/net/httpserver/spec/com/sun/net... -- 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

13 years, 9 months

2
12
0 / 0

[JBoss JIRA] Created: (JBAS-5474) @PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER

by Stefan Lindner (JIRA)

@PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER -------------------------------------------------------------------------------------------------------------------- Key: JBAS-5474 URL: http://jira.jboss.com/jira/browse/JBAS-5474 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.2.GA Environment: Win XP SP2, Java 1.5.0_15-b04 Reporter: Stefan Lindner Assigned To: Carlo de Wolf Fix For: JBossAS-4.2.3.GA I have a bean with a @OneToMany relation mapping like private List<TherapieeinheitBean> therapieeinheiten; @OneToMany( cascade = {CascadeType.REFRESH}, fetch = FetchType.EAGER, mappedBy="therapiekatalog" ) with FetchType.EAGER and a simnple @PostLoad like @PostLoad public void postLoad() { System.out.println("!!!!!!!!!! postLoad !!!!!!!!!!"); System.out.print("size: " + therapieeinheiten.size()); } When an entity of this bean is loaded JBoss trows org.hibernate.LazyInitializationException: illegal access to loading collection at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:341) at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) at org.hibernate.collection.PersistentBag.iterator(PersistentBag.java:249) at de.visiodesk.therapiekatalog.TherapiekatalogBean.postLoad(TherapiekatalogBean.java:170) . . . and prints the messages WARN [LoadContexts] fail-safe cleanup (collections) : org.hibernate.engine.loading.CollectionLoadContext@2c8ce9<rs=Ingres-ResultSet[18523]> WARN [CollectionLoadContext] On CollectionLoadContext#cleanup, localLoadingCollectionKeys contained [206] entries afterwards. The PostLoad method should be called after the data was completely loaded. Is there a workaround for this Problem? I found some other ressources on the net where peole had the same problem, but I saw no resolution, no hint, no workaround. -- 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

13 years, 9 months

9
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008