November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-3258) JDBC artificats should throw SQLException when already closed

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3258?page=all ] Adrian Brock updated JBAS-3258: ------------------------------- Comment: was deleted > JDBC artificats should throw SQLException when already closed > ------------------------------------------------------------- > > Key: JBAS-3258 > URL: http://jira.jboss.com/jira/browse/JBAS-3258 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.4.GA > Reporter: Adrian Brock > Assigned To: Weston Price > Fix For: JBossAS-4.0.5.CR1, JBossAS-4.0.4.SP1 > > > In the change to fix JBAS-2741 I mistakenly made the JDBC wrappers throw an SQL > exception if the artifact is already closed. They should just return with an exception. > From the Javadoc: > "Calling the method close on a Statement object that is already closed has no effect." > e.g. In WrappedStatement > public void close() throws SQLException > { > synchronized (lock) > { > if (closed) > throw new SQLException("Already closed"); > closed = true; > } > lc.unregisterStatement(this); > internalClose(); > } > this should be: > public void close() throws SQLException > { > synchronized (lock) > { > if (closed) > return; > closed = true; > } > lc.unregisterStatement(this); > internalClose(); > } -- 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

18 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3258) JDBC artificats should throw SQLException when already closed

by Edoardo Causarano (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3258?page=comments#action_12389842 ] Edoardo Causarano commented on JBAS-3258: ----------------------------------------- Hi, we're having the same problem on our servers but I expected that the "jboss-4.0.4.GA-Patch1-installer.jar" contained the fix to this issue. Unfortunately the installer doesn't seem to contain said patch so we're a bit stuck; does it mean that we have to upgrade to 4.0.5? > JDBC artificats should throw SQLException when already closed > ------------------------------------------------------------- > > Key: JBAS-3258 > URL: http://jira.jboss.com/jira/browse/JBAS-3258 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.4.GA > Reporter: Adrian Brock > Assigned To: Weston Price > Fix For: JBossAS-4.0.5.CR1, JBossAS-4.0.4.SP1 > > > In the change to fix JBAS-2741 I mistakenly made the JDBC wrappers throw an SQL > exception if the artifact is already closed. They should just return with an exception. > From the Javadoc: > "Calling the method close on a Statement object that is already closed has no effect." > e.g. In WrappedStatement > public void close() throws SQLException > { > synchronized (lock) > { > if (closed) > throw new SQLException("Already closed"); > closed = true; > } > lc.unregisterStatement(this); > internalClose(); > } > this should be: > public void close() throws SQLException > { > synchronized (lock) > { > if (closed) > return; > closed = true; > } > lc.unregisterStatement(this); > internalClose(); > } -- 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

18 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1227) Data gravitation RspFilter makes cache misses very slow

by Brian Stansberry (JIRA)

Data gravitation RspFilter makes cache misses very slow ------------------------------------------------------- Key: JBCACHE-1227 URL: http://jira.jboss.com/jira/browse/JBCACHE-1227 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR2 Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Critical Fix For: 2.1.0.GA DataGravitatorInterceptor.ResponseValidityFilter will make all gravitation attempts take buddyCommunicationTimeout ms if the data is not available (i.e. if its a cluster-wide cache miss). Logging showing what happens with a 2 second buddyCommunicationTimeout : 2007-11-28 14:24:49,634 DEBUG [org.jboss.cache.interceptors.DataGravitatorInterceptor] cache=192.168.1.164:1621; requesting data gravitation for Fqn /JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID 2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.CacheImpl.DefaultPartition-TomcatCache] callRemoteMethods(): valid members are [192.168.1.165:1674] methods: /JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID 2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher] dests=[192.168.1.165:1674], method_call=MethodName: gravitateData; MethodIdInteger: 35; Args: (/JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID, true), mode=1, timeout=2000 2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 21 2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.AbstractMarshaller] extract(): received MethodName: gravitateData; MethodIdInteger: 35; Args: (/JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID, true)extracted fqn: /JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID 2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call. Using region /JSESSION/localhost/http-field-pass 2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object MethodName: gravitateData; MethodIdInteger: 35; Args: (/JSESSION/localhost/http-field-pass/SfrkE9Utsz-EfMjYpItWEA__/ATTRIBUTE/TEST_ID, true) 2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field-pass to stream 2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher] real_dests=[192.168.1.165:1674] 2007-11-28 14:24:49,743 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Read version 21 2007-11-28 14:24:49,759 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Unmarshalled regionFqn /JSESSION/localhost/http-field-pass from stream 2007-11-28 14:24:49,759 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Unmarshalled object Result dataFound=false nodeData=null fqn=null 2007-11-28 14:24:51,759 DEBUG [org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher] responses: [sender=192.168.1.165:1674, retval=null, received=false, suspected=false] The 2nd to last line shows the response being unmarshalled, yet 2 secs later the RpcDispatcher reports no response was received from the node that sent the response. Cause is DataGravitatorInterceptor.ResponseValidityFilter.needMoreResponses() which will always return true until it gets a response where GravitateResult.isDataFound() is true. That response will never arrive if the data doesn't exist. So RpcDispatcher will keep waiting for more responses until it times out. I think the solution is to pass the vector of members being called to ResponseValidityFilter, which keeps a copy. In isAcceptable, remove the member that sent the response. In needMoreResponses, return false if all members have sent responses. I'll attach a patch implementing the above in a minute. -- 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

18 years, 7 months

2
12
0 / 0

[JBoss JIRA] Resolved: (JBFORUMS-14) Forum posts can become unusable due to width of content

by Ryszard Kozmik (JIRA)

[ http://jira.jboss.com/jira/browse/JBFORUMS-14?page=all ] Ryszard Kozmik resolved JBFORUMS-14. ------------------------------------ Resolution: Done > Forum posts can become unusable due to width of content > ------------------------------------------------------- > > Key: JBFORUMS-14 > URL: http://jira.jboss.com/jira/browse/JBFORUMS-14 > Project: JBoss Forums > Issue Type: Patch > Reporter: Scott M Stark > Assigned To: Ryszard Kozmik > Priority: Minor > Fix For: 1.0.1 RC > > > I'm seeing problems with the size of forum posts using the [code][/code] tags. There needs to be some fixed size to the text fields with scrolling instead of what is seen here: > > http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857964 > http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3858023 -- 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

18 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (EJBTHREE-647) SecondaryTable

by jBossTester jBossTester (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-647?page=comments#action_12389828 ] jBossTester jBossTester commented on EJBTHREE-647: -------------------------------------------------- You can explain the workaround? Maybe with the same example.Thanks > SecondaryTable > -------------- > > Key: EJBTHREE-647 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-647 > Project: EJB 3.0 > Issue Type: Bug > Components: EJB3 Extensions > Affects Versions: EJB 3.0 RC8 - FD > Environment: PC Intel 2.8GHz, 1G RAM, OpenSuSE 10.0, Eclipse 3.1.2, JBoss-IDE 1.5.1.GS, AS JBoss-4.0.4.GA > Reporter: Jose Jesus > Assigned To: Emmanuel Bernard > > I'm using @SecondaryTable annoration and at deploy moment an exception occurs: > 10:10:46,141 ERROR [AssertionFailure] an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session) > org.hibernate.AssertionFailure: Table PERSON not found > at org.hibernate.persister.entity.JoinedSubclassEntityPersister.getTableId(JoinedSubclassEntityPersister.java:444) > at org.hibernate.persister.entity.JoinedSubclassEntityPersister.<init>(JoinedSubclassEntityPersister.java:225) > at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:58) > at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:223) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1213) > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:631) > at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:760) > at org.hibernate.ejb.Ejb3Configuration.createContainerEntityManagerFactory(Ejb3Configuration.java:350) > at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:119) > at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:264) > : > : > 10:10:46,189 WARN [ServiceController] Problem starting service persistence.units:jar=sgscore-ejb3.jar,unitName=sgscore > org.hibernate.AssertionFailure: Table PERSON not found > at org.hibernate.persister.entity.JoinedSubclassEntityPersister.getTableId(JoinedSubclassEntityPersister.java:444) > at org.hibernate.persister.entity.JoinedSubclassEntityPersister.<init>(JoinedSubclassEntityPersister.java:225) > at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:58) > at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:223) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1213) > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:631) > at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:760) > at org.hibernate.ejb.Ejb3Configuration.createContainerEntityManagerFactory(Ejb3Configuration.java:350) > at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:119) > at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:264) > : > : > my code and annotations are: > @Entity > @Table(name="USER") > @Inheritance(strategy = InheritanceType.JOINED) > @SecondaryTable(name = "PERSON", pkJoinColumns = { > @PrimaryKeyJoinColumn(name = "PERSON_ID", referencedColumnName = "ID") > } > ) > public class User extends Participant { > private String firstName; > : > : > @Column(name="FIRST_NAME", table="PERSON") > public String getFirstName(){ > return firstName; > } > public void setFirstName(String firstName) { > this.firstName = firstName; > } > : > : > } > @Entity > @Table(name="PERSON") > public class Person { > private String firstName; > : > : > @Column(name="FIRST_NAME") > public String getFirstName() { > return firstName; > } > public void setFirstName(String firstName) { > this.firstName = firstName; > } > : > : > } > @Entity > @Table(name="PARTICIPANT") > @Inheritance(strategy = InheritanceType.JOINED) > public class Participant { > private String id; > : > : > @Id > public String getId() { > return id; > } > public void setId(String id) { > this.id = id; > } > : > : > } > Another observation is that in User class SecondaryTable annotation I already try: > @SecondaryTable(name="PERSON") > AND > @SecondaryTables({ > @SecondaryTable(name = "PERSON", pkJoinColumns = { > @PrimaryKeyJoinColumn(name = "PERSON_ID", referencedColumnName = "ID") > } > ) > } > ) > AND > @SecondaryTables({ > @SecondaryTable(name = "PERSON") > } > ) > the same exception occurs. > What's the problem with implementation code or annotations??? > Thank's. -- 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

18 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4927) Code added in 4.2.1 breaks web app that works in 4.2.0

by Greg Bridges (JIRA)

Code added in 4.2.1 breaks web app that works in 4.2.0 ------------------------------------------------------ Key: JBAS-4927 URL: http://jira.jboss.com/jira/browse/JBAS-4927 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA Environment: linux, java5 Reporter: Greg Bridges Assigned To: Remy Maucherat Code was added in version 4.2.1 to the WebAppClassLoader class to override the findClass() operation. I have a web app that uses the sun rmi-iiop to connect to remote applications (which worked fine before). The stubs for my code are located in my deployed jars in the war. At line 98 in WebAppClassLoader.java, a call is made to attempt to run the iiopstubcompiler. It gets a ClassDefNotFound on the IIOPStubCompiler class, which then bypasses the catch block (which is looking for a RuntimeException). It looks like the intent was to run the super.findClass() if there is any trouble, but that doesn't happen due to the catch block being bypassed. If I change the code to catch Throwable or add a catch for ClassDefNotFound which runs super.findClass(), the app works as it did before. -- 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

18 years, 7 months

5
11
0 / 0

[JBoss JIRA] Created: (JBCACHE-802) NonManagedConnectionFactory does not place new connections in ThreadLocal (JDBCCacheLoader)

by Manik Surtani (JIRA)

NonManagedConnectionFactory does not place new connections in ThreadLocal (JDBCCacheLoader) ------------------------------------------------------------------------------------------- Key: JBCACHE-802 URL: http://jira.jboss.com/jira/browse/JBCACHE-802 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0.SP1 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 1.4.0.SP2, 2.0.0 In NonManagedConnectionFactory.getConnection(): public Connection getConnection() { Connection con = (Connection) connection.get(); if(con == null) { try { con = DriverManager.getConnection(url, usr, pwd); // CODE ADDED HERE connection.set(con); // END CODE MODIFICATION } catch(SQLException e) ... -- 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

18 years, 7 months

4
13
0 / 0

[JBoss JIRA] Created: (JBAS-4264) war context.xml is not being read

by Scott M Stark (JIRA)

war context.xml is not being read --------------------------------- Key: JBAS-4264 URL: http://jira.jboss.com/jira/browse/JBAS-4264 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Reporter: Scott M Stark Assigned To: Remy Maucherat Fix For: JBossAS-5.0.0.Beta3 The logic in the private String findConfig(URL warURL) to obtain an absolute file name is broken since the change to the vfs. This needs to either be a vfs path or the full input stream to the context.xml since there is no guarentee that a java.io.File to the context.xml exists. -- 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

18 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAOP-473) Add 1.5.6 artifacts to the JBoss Maven respository

by Anders Hammar (JIRA)

Add 1.5.6 artifacts to the JBoss Maven respository -------------------------------------------------- Key: JBAOP-473 URL: http://jira.jboss.com/jira/browse/JBAOP-473 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 1.5.6.GA Environment: n/a Reporter: Anders Hammar Attachments: jboss-aop-1.5.6.GA.pom, jboss-aop-jdk50-1.5.6.GA.pom Please add the jdk1.4 and jdk5.0 artifacts of jboss-aop 1.5.6.GA to the maven repository. I've attached the pom files for both artifacts. To be consistent with the deployed 1.5.0.GA artifact, I've keept the "jboss.jboss-aop" groupId and I also kept the "jboss-aop" artifactId for the jdk1.4 artifact. The jdk5.0 artifact uses the "jboss-aop-jdk50" artifactId to be consistent with the jar file in the distribution zip. (While this is not artifact naming standard used in 2.0.0.beta1.) -- 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

18 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (SECURITY-97) TransactionManagerLocator needs update to use the locator in JBossAS

by Anil Saldhana (JIRA)

TransactionManagerLocator needs update to use the locator in JBossAS -------------------------------------------------------------------- Key: SECURITY-97 URL: http://jira.jboss.com/jira/browse/SECURITY-97 Project: JBoss Security and Identity Management Issue Type: Bug Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: 2.0.1.GA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2-BETA The DatabaseLoginModule has a feature of suspending a JTA transaction for DB access and then resume. The TransactionManagerLocator that uses reflection needs to be updated to TML from JBossAS integration. -- 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

18 years, 7 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 November 2007