October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1741) PortalURL security not honoured

by Julien Viet (JIRA)

PortalURL security not honoured ------------------------------- Key: JBPORTAL-1741 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1741 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.2 Final, 2.6.1 Final, 2.6 Final, 2.6.3 Final Reporter: Julien Viet Assigned To: Julien Viet Fix For: 2.6.3 Final Attachments: PortalURLSecurity.zip PortalURL security is not honoured, here is a patch for it. I am not commiting directly to SVN since I need that someone validates the patch and also create a portlet sample that will be a use case so it can be validated through this portlet. -- 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

17 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-815) allow user to set content-type for http responses (CLONE of JBREM-653)

by Ron Sigal (JIRA)

allow user to set content-type for http responses (CLONE of JBREM-653) ---------------------------------------------------------------------- Key: JBREM-815 URL: http://jira.jboss.com/jira/browse/JBREM-815 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.GA Reporter: Tom Elrod Assigned To: Ron Sigal Fix For: 2.2.2.SP1 Currently the CoyoteInvoker.versionedWrite() method will set the content type of the http response by using WebUtil.getContentType(responseObject) to identify the content type based on the response object type being sent back to client. Should allow this to be overriden by the user in the same way the response code/message can be (using the response map). -- 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

17 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-814) CLONE -Logger in HTTPClientInvoker should be static.

by Ron Sigal (JIRA)

CLONE -Logger in HTTPClientInvoker should be static. ---------------------------------------------------- Key: JBREM-814 URL: http://jira.jboss.com/jira/browse/JBREM-814 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.GA Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP1, 2.2.2.GA_CP01 When org.jboss.remoting.transport.http.ssl.HTTPSClientInvoker.createSocketFactory() (which is called from the RemoteClientInvoker() constructor) tries to log an error, it throws a NullPointerException because the log variable has not been initialized. The log variable should be static. -- 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

17 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-687) allow binding to 0.0.0.0

by Tom Elrod (JIRA)

allow binding to 0.0.0.0 ------------------------ Key: JBREM-687 URL: http://jira.jboss.com/jira/browse/JBREM-687 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.6.GA, 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta2 (Boon) Need to be able to really bind to 0.0.0.0. Currently, remoting will swap out 0.0.0.0 with local host name or address. Although this is about only way to be able to provide an invoker locator url that can be used by anyone else externally, means that only one network interface can ever be used. For things such as JNDI, may want to use all interfaces and need to add back in ability to do 0.0.0.0 binding. -- 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

17 years, 1 month

2
9
0 / 0

[JBoss JIRA] Created: (JBREM-811) Privileged Block to create Class Loader

by Anil Saldhana (JIRA)

Privileged Block to create Class Loader --------------------------------------- Key: JBREM-811 URL: http://jira.jboss.com/jira/browse/JBREM-811 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: security Affects Versions: 2.2.2.GA Reporter: Anil Saldhana Assigned To: Trustin Lee Fix For: 2.2.2.SP1 Please add a Privileged Block to create the class loader. =================================== Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:594) at java.lang.ClassLoader.<init>(ClassLoader.java:201) at org.jboss.remoting.loading.ClassByteClassLoader.<init>(ClassByteClassLoader.java:62) at org.jboss.remoting.AbstractInvoker.<init>(AbstractInvoker.java:76) at org.jboss.remoting.transport.local.LocalClientInvoker.<init>(LocalClientInvoker.java:71) at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:304) at org.jboss.remoting.Client.connect(Client.java:459) ==================================== -- 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

17 years, 1 month

3
12
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1049) wrong insert/delete order when updating record-set

by Imran Pariyani (JIRA)

wrong insert/delete order when updating record-set -------------------------------------------------- Key: EJBTHREE-1049 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1049 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.1.GA Environment: jboss-4.2.1.GA , Fedora 6 Reporter: Imran Pariyani Overview: I have a record with a OneToMany association. From this associated record-set a record is removed and added again, both records identified with the same key. When doing a merge, I get a Unique constraint violation, because EJB first tries to insert the new record. It should first delete the old record, and after this insert the new record, avoiding the unique constraint violation. Detailed description: I have the following entities: Location and LocationI18n. Location has onetomany mapping with locationi18n as follows @OneToMany(cascade = CascadeType.ALL, mappedBy = "location", fetch = FetchType.EAGER) private List<LocationI18n> translations; And the mapping in the locationi18n is : @ManyToOne(cascade = {CascadeType.MERGE, CascadeType.PERSIST },fetch = FetchType.LAZY, optional = false) @JoinColumn(name = "loc_id", referencedColumnName = "id", nullable = false, columnDefinition = "loc_id INT NOT NULL") private Location location; In the locationI18n table i have a unique key UNIQUE KEY (language, loc_id), So now if i get a location and inside the location i have the collection of locationi18n .. if from that collection i remove one object with language lets say 'EN' and insert a new locationi18n object with the same language 'EN' then it first inserts the new record and then delets the records which has been removed from the collection Below is the stack trace: 2007-09-07 02:17:24,847 DEBUG [org.hibernate.SQL] insert into location_i18n (loc_id, language, date_created, date_updated, province, city, worldregion, region, subregion, quarter) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) 2007-09-07 02:17:24,848 TRACE [org.hibernate.type.IntegerType] binding '1' to parameter: 1 2007-09-07 02:17:24,848 DEBUG [org.hibernate.type.EnumType] Binding 'EN' to parameter: 2 2007-09-07 02:17:24,848 TRACE [org.hibernate.type.TimestampType] binding '2007-09-07 02:17:24' to parameter: 3 2007-09-07 02:17:24,848 TRACE [org.hibernate.type.TimestampType] binding '2007-09-07 02:17:24' to parameter: 4 2007-09-07 02:17:24,848 TRACE [org.hibernate.type.StringType] binding null to parameter: 5 2007-09-07 02:17:24,848 TRACE [org.hibernate.type.StringType] binding null to parameter: 6 2007-09-07 02:17:24,849 TRACE [org.hibernate.type.StringType] binding null to parameter: 7 2007-09-07 02:17:24,849 TRACE [org.hibernate.type.StringType] binding 'afsdfa' to parameter: 8 2007-09-07 02:17:24,849 TRACE [org.hibernate.type.StringType] binding null to parameter: 9 2007-09-07 02:17:24,849 TRACE [org.hibernate.type.StringType] binding null to parameter: 10 2007-09-07 02:17:24,873 WARN [org.hibernate.util.JDBCExceptionReporter] SQL Error: 1062, SQLState: 23000 2007-09-07 02:17:24,874 ERROR [org.hibernate.util.JDBCExceptionReporter] Duplicate entry 'EN-1' for key 2 2007-09-07 02:17:24,874 ERROR [STDERR] javax.persistence.EntityExistsException: org.hibernate.exception.ConstraintViolationException: could not insert: [com.triple.LocationI18n] 2007-09-07 02:17:24,874 ERROR [STDERR] at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:604) 2007-09-07 02:17:24,874 ERROR [STDERR] at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:236) 2007-09-07 02:17:24,874 ERROR [STDERR] at org.jboss.ejb3.entity.TransactionScopedEntityManager.merge(TransactionScopedEntityManager.java:188) 2007-09-07 02:17:24,874 ERROR [STDERR] at com.triple.LocationBean.updateLocation(LocationBean.java:83) 2007-09-07 02:17:24,874 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 2007-09-07 02:17:24,874 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 2007-09-07 02:17:24,875 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Test case of the same is present at http://opensource.atlassian.com/projects/hibernate/secure/attachment/1346... -- 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

17 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1267) Allow predicates to be nested inside a field constraint

by Edson Tirelli (JIRA)

Allow predicates to be nested inside a field constraint ------------------------------------------------------- Key: JBRULES-1267 URL: http://jira.jboss.com/jira/browse/JBRULES-1267 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Edson Tirelli Assigned To: Edson Tirelli Fix For: 4.1.0 Allow predicates to be nested inside a field constraint -- 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

17 years, 1 month

1
1
0 / 0

[JBoss JIRA] Updated: (JBCACHE-295) Add unit tests for ReplicationQueue

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-295?page=all ] Manik Surtani updated JBCACHE-295: ---------------------------------- Fix Version/s: 2.1.0.CR1 > Add unit tests for ReplicationQueue > ----------------------------------- > > Key: JBCACHE-295 > URL: http://jira.jboss.com/jira/browse/JBCACHE-295 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Minor > Fix For: 2.1.0.GA, 2.1.0.CR1 > > -- 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

17 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-315) Break locks for state transfer

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ] Manik Surtani updated JBCACHE-315: ---------------------------------- Fix Version/s: 2.1.0.CR1 > Break locks for state transfer > ------------------------------ > > Key: JBCACHE-315 > URL: http://jira.jboss.com/jira/browse/JBCACHE-315 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Vladimir Blagojevic > Priority: Critical > Fix For: 2.1.0.GA, 2.1.0.CR1 > > > State transfer needs to acquire a lock on the root to make sure all existing TXs have been completed. However, when a TX takes more time than the lock acquisition timeout, state transfer will fail. > Therefore, we need to forcefully acquire the locks for the state transfer by force-releasing the existing locks, and rolling back all TXs that held those locks. > This will ensure that state transfer always succeeds, at the expense of some rolled back TXs. > We need to investigate how this works with optimistic locking -- 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

17 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1167) Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly

by Galder Zamarreno (JIRA)

Heuristic outcome (STATUS_UNKNOWN) of transaction not handled properly ---------------------------------------------------------------------- Key: JBCACHE-1167 URL: http://jira.jboss.com/jira/browse/JBCACHE-1167 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP4, 2.0.0.GA Reporter: Galder Zamarreno Assigned To: Manik Surtani Fix For: 1.4.1.SP5 Where an XA transaction has a heuristic outcome, the status reported to the afterCompletion synchronization is STATUS_UNKNOWN (5), since JTA does not handle heuristics. In this case, the cache Synchronization fails to rollback the cache tx. This leaves the app server in a bad (i.e. locked) state even though the XA transaction has been resolved. At first glance it looks like the afterCompletion synchronization should treat a STATUS_UNKNOWN as a cause for rollback as well as logging the error as they currently do. Unfortunately the fix may be more complex than that, since the db may have committed rather than rolled back, meaning the cache would be out of sync with the db if you rolled it back. -- 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

17 years, 1 month

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007