January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBJPA-32) Hibernate logs warning for PersistenceUnitInfo.newTempClassLoader() == null, which it always is in EJB3

by Brad Maxwell (JIRA)

Hibernate logs warning for PersistenceUnitInfo.newTempClassLoader() == null, which it always is in EJB3 ------------------------------------------------------------------------------------------------------- Key: JBJPA-32 URL: https://jira.jboss.org/browse/JBJPA-32 Project: JBoss JPA Issue Type: Bug Components: mcint Affects Versions: 1.0.0 Environment: JBoss Enterprise Application Platform 5.0.1 Reporter: Brad Maxwell Assignee: Carlo de Wolf Looks like https://jira.jboss.org/browse/EJBTHREE-982 did not make it into JBoss 5 WARN [Ejb3Configuration] Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getN ewTempClassLoader() is null. Coming from org.hibernate.ejb.Ejb3Configuration private void addXMLEntities(List<String> xmlFiles, PersistenceUnitInfo info, List<String> entities) { //TODO handle inputstream related hbm files ClassLoader newTempClassLoader = info.getNewTempClassLoader(); if (newTempClassLoader == null) { log.warn( "Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null." ); return; } However, implementation of org.jboss.ejb3.entity.PersistenceUnitInfoImpl has: public ClassLoader getNewTempClassLoader() { return null; } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (HIBERNATE-124) Superfluous event listener in Hibernate code

by Tom Ross (JIRA)

Superfluous event listener in Hibernate code -------------------------------------------- Key: HIBERNATE-124 URL: https://issues.jboss.org/browse/HIBERNATE-124 Project: Hibernate Integration Issue Type: Bug Environment: JBoss EAP 5.1 Reporter: Tom Ross Assignee: Steve Ebersole Priority: Minor When Hibernate initialises it prints a warning message "InitialContext did not implement EventContext". This is a result of a cast in the SessionFactoryObjectFactory.addInstance() method which is trying to cast javax.naming.InitialContext object to EventContext while trying to add an event listener to it. javax.naming does not implement the interface EventContext so the cast fails and the listener is never register. As it stands this code is completely superfluous at the moment since it is never used. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1129) Ergonomics: size max_bundle_size and max_bundle_timeout (in TP) dynamically

by Bela Ban (JIRA)

Ergonomics: size max_bundle_size and max_bundle_timeout (in TP) dynamically --------------------------------------------------------------------------- Key: JGRP-1129 URL: https://jira.jboss.org/jira/browse/JGRP-1129 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.10 When we have max_bundle_timeout="30" and max_bundle_size="64000", then we will always run into the timeout when sending (for example) synchronous 1000 byte messages. Investigate whether it makes sense to keep track of (1) when the timeout and/or (2) the max bundle size is exceeded and adjust the max_bundle_timeout / max_bundle_size accordingly. E.g. if the max_timeout is always reached because we're only sending 1000 byte messages, set the max_bundle_size to 1000 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2874) Converting .brl to .drl

by kamal thiyagu (JIRA)

Converting .brl to .drl ----------------------- Key: JBRULES-2874 URL: https://issues.jboss.org/browse/JBRULES-2874 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.1.FINAL Environment: converting .brl to .drl Reporter: kamal thiyagu Assignee: Mark Proctor Priority: Critical i cant convert .brl file to .drl file -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-1259) Reduce size of large headers: place data into message itself

by Bela Ban (JIRA)

Reduce size of large headers: place data into message itself ------------------------------------------------------------ Key: JGRP-1259 URL: https://jira.jboss.org/browse/JGRP-1259 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12 When we send a view around, we essentially create an empty Message and attach a GmsHeader.VIEW with the new view. If the view consists of 200 members, the view header will be very big and the message is still empty (null buffer). The issue here is that FRAG2 only fragments the message's buffer (this is faster), and so a huge header might add so much to the size of a serialized message that the transport (UDP) won't be able to send it ! SOLUTION: still use the header (e.g. GmsHeader.VIEW), but place potentially large payloads into the message. This will allow FRAG2 to fragment the message very efficiently. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2674) Add support for KBaseConfiguration's ConsequenceExceptionHandlerOption when setting up a kbase using spring

by Esteban Aliverti (JIRA)

Add support for KBaseConfiguration's ConsequenceExceptionHandlerOption when setting up a kbase using spring ----------------------------------------------------------------------------------------------------------- Key: JBRULES-2674 URL: https://jira.jboss.org/browse/JBRULES-2674 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Esteban Aliverti Assignee: Esteban Aliverti Priority: Minor Fix For: 5.2.0.M1 When configuring a kbase using spring, it would be good to have support for ConsequenceExceptionHandlerOption confguration. i.e: <drools:kbase id="kbase1"> <drools:resources> ... </drools:resources> <drools:configuration> <drools:consequenceExceptionHandler handler="some.custom.ConsequenceExceptionHandler" /> </drools:configuration> </drools:kbase> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-1276) JGroups ignores my custom SocketFactory

by Adrian Tarau (JIRA)

JGroups ignores my custom SocketFactory --------------------------------------- Key: JGRP-1276 URL: https://issues.jboss.org/browse/JGRP-1276 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Environment: All Reporter: Adrian Tarau Assignee: Bela Ban I was trying to replace the default socket factory with my own socket factory so I can decide if MulticaseSocket is created with InetSocketAddress or to use just the port(to experiment this "Invalid argument") and it doesn't use my socket factory. Looking in the code, the way(the call order) how the socket factory is forwarded to the protocols is wrong(I think) because the protocols are started with the default stack instead of my stack. prot_stack.getTopProtocol().setSocketFactory(socket_factory) should be called before the stack is started and not after. private void startStack(String cluster_name) throws ChannelException { ..... try { prot_stack.startStack(cluster_name, local_addr); // calls start() in all protocols, from top to bottom } catch(Throwable e) { throw new ChannelException("failed to start protocol stack", e); } if(socket_factory != null) { prot_stack.getTopProtocol().setSocketFactory(socket_factory); } .... } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-1278) LockService lock, tryLock methods don't work well with interrupt

by William Burns (JIRA)

LockService lock, tryLock methods don't work well with interrupt ---------------------------------------------------------------- Key: JGRP-1278 URL: https://issues.jboss.org/browse/JGRP-1278 Project: JGroups Issue Type: Bug Affects Versions: 2.12 Reporter: William Burns Assignee: Bela Ban I have been trying out the new LockService class, which has been great to use. However I began looking into stuff around interrupts, and while glancing at the actual protocol code I became a little confused as to how the lock method would ignore an interrupt and still acquire the lock. So I wrote up a simple test case, which can be found in the Reproduce section. Needless to say the lock method behaves completely differently than how I would have expected if an interrupt was encountered. If the interrupt flag is set the lock method would return immediately, making the caller think the lock was retrieved. However the lock was not retrieved! Also not to mention the interrupt status was lost completely, further preventing the interrupt from being checked in a later part of code. Also the tryLock() method behaves somewhat in a similar fashion as lock. If the interrupt status is set it will return false immediately and clear the interrupt status. I would expect the code to still retrieve the lock if possible and leave the interrupt flag set afterwards just like I would in the case of lock. I did also test the lockInterruptibly, tryLock(long, TimeUnit) and those worked if the interrupt flag was set before invoking it, by throwing an InterruptedException as expected. I didn't test any of the methods in regards to an interrupt being done in the middle of waiting to acquire a lock. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
8
0 / 0

[JBoss JIRA] Created: (JGRP-1277) Usage of TimeUnit class is inverted, causing incorrect conversions between time units

by William Burns (JIRA)

Usage of TimeUnit class is inverted, causing incorrect conversions between time units ------------------------------------------------------------------------------------- Key: JGRP-1277 URL: https://issues.jboss.org/browse/JGRP-1277 Project: JGroups Issue Type: Bug Affects Versions: 2.12 Reporter: William Burns Assignee: Bela Ban Priority: Minor I have tried posting something to the blog at http://belaban.blogspot.com/2011/01/new-distributed-locking-service-in.html but it hasn't put up my comment yet, so I decided to create a JIRA as well. I have taken the latest 2.12 build of Beta1 which includes the new LockService class. This class is so much of an improvement how the DistributedLockManager was; great work! But anyways I found that when you try to acquire a lock with a wait, it is not converting the timeunits correctly unless it is in MILLISECONDS. This cannot be reproduced with the demo class since it always uses MILLISECONDS. The code in question is found on the Locking$ClientLock inner class. {code} public boolean tryLock(long time, TimeUnit unit) throws InterruptedException { return acquireTryLock(unit.convert(time, TimeUnit.MILLISECONDS), true); } {code} The way this is, the code will convert the time value passed in as MILLISECONDS to the passed in TimeUnit. This simply needs to change to make the TimeUnit.MILLISECONDS the object of which the convert method is being called on and having unit as the second argument. {code} public boolean tryLock(long time, TimeUnit unit) throws InterruptedException { return acquireTryLock(TimeUnit.MILLISECONDS.convert(time, unit), true); } {code} This obviously has a simple workaround of _always_ passing in a TimeUnit of MILLISECONDS and having the time value already adjusted. And again this new feature looks to be very promising. Also when just checking the jgroups code base there are 3 other references to convert, 2 of which are also broken in this fashion. {quote} HashedTimingWheel.schedule TimeScheduler2.schedule {quote} Both of these references in the jgroup code base are always passed MILLISECONDS, so it would only be seen if client code were to interact with them somehow. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
0 / 0

[JBoss JIRA] Resolved: (JBREM-159) Patch to enable JRockit 5.0 to work with JBoss Remoting

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-159?page=com.atlassian.jira.plugin.... ] Ron Sigal resolved JBREM-159. ----------------------------- Resolution: Out of Date > Patch to enable JRockit 5.0 to work with JBoss Remoting > ------------------------------------------------------- > > Key: JBREM-159 > URL: https://issues.jboss.org/browse/JBREM-159 > Project: JBoss Remoting > Issue Type: Patch > Components: general > Affects Versions: 2.2.2.GA > Reporter: Jeff Haynie > Priority: Minor > > org.jboss.remoting.detection.multicast.MulticaseDetector$Listener.run, changed: > try > { > listen(p, buf); > } > catch (Exception ex) > to: > try > { > listen(p, buf); > p.setLength(buf.length); > } > catch (Exception ex) > org.jboss.remoting.loading.ClassUtil.serialize, changed body of the method from: > java.io.ByteArrayOutputStream bos=new java.io.ByteArrayOutputStream(); > java.io.ObjectOutputStream oos=new java.io.ObjectOutputStream(bos); > oos.writeObject(obj); > oos.flush(); > bos.flush(); > byte buf[]=bos.toByteArray(); > bos=null; > oos=null; > return buf; > to: > java.io.ByteArrayOutputStream bos=new java.io.ByteArrayOutputStream(); > java.io.ObjectOutputStream oos=new java.io.ObjectOutputStream(bos); > oos.writeObject(obj); > oos.flush(); > bos.flush(); > oos.close(); > bos.close(); > byte buf[]=bos.toByteArray(); > bos=null; > oos=null; > return buf; -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2011