September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBESB-58) Add back EPR functionality

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-58?page=all ] Mark Little closed JBESB-58. ---------------------------- Resolution: Done > Add back EPR functionality > -------------------------- > > Key: JBESB-58 > URL: http://jira.jboss.com/jira/browse/JBESB-58 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: ESB Core > Affects Versions: 4.0 Alpha 1 > Reporter: Mark Little > Assigned To: Mark Little > Priority: Critical > Fix For: 4.0 > > Time Spent: 6 hours > Remaining Estimate: 0 minutes > > Prior to Rosetta, the Alpha 1 codebase has the EPR capabilities. Add this 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2193) abstract schema name with word limit in name

by Alexey Loubyansky (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2193?page=all ] Alexey Loubyansky closed JBAS-2193. ----------------------------------- Fix Version/s: (was: JBossAS-4.0.6.CR1) Resolution: Out of Date This one was probably fixed as a side effect of some other issue. It's working against the current Branch_4_0. 15:42:00,685 INFO [FacadeSessionBean] RUN> 15:42:00,685 DEBUG [A#ejbSelectSelect] DYNAMIC-QL: select count(limit_a.id) from limita limit_a 15:42:00,685 DEBUG [A#ejbSelectSelect] Executing SQL: SELECT count( t0_limit_a.id) FROM A t0_limit_a 15:42:00,685 INFO [STDOUT] [1] > abstract schema name with word limit in name > -------------------------------------------- > > Key: JBAS-2193 > URL: http://jira.jboss.com/jira/browse/JBAS-2193 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.3RC1 > Environment: OS: Windows XP and FreeBsd > Database: PostgreSQL 7.4 > Reporter: Yura Kravchuk > Assigned To: Alexey Loubyansky > Priority: Minor > > We have few CMP entity beans with abstract schema name with word "limit", e.g. limitation_categories, limitation_durations, etc. We using dynamiq QL. It seems that query parser confused by word "limit" in schema name and thinks that it's clause LIMIT which placed before FROM clause. I changed schema name to lim_categories for entity bean and all works perfectly. > Herewith exception: > 17:02:28,671 INFO [STDOUT] javax.ejb.EJBException: SELECT COUNT($limit_category.id) FROM limit_category AS $limit_categ > ory; CausedByException is: > Can't count entities by expression and parameters; CausedByException is: > Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71. > Was expecting: > "FROM" ... > ; CausedByException is: > Can't count entities by expression and parameters; CausedByException is: > Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAOP-285) overloaded method super calls do not get intercepted with generated advisors

by Kabir Khan (JIRA)

overloaded method super calls do not get intercepted with generated advisors ---------------------------------------------------------------------------- Key: JBAOP-285 URL: http://jira.jboss.com/jira/browse/JBAOP-285 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha class Base{ void superCall(){} } class Sub extends Base{ void superCall(){super.superCall();} } <bind pointcut="execution(* $instanceof{Base}->superCall())"> <interceptor class="X"/> </bind> Sub sub = new Sub(); sub.superCall(); We only get intercepted when calling sub.superCall(), the call to base.superCall() does not get intercepted. I added a failing test to org.jboss.test.aop.extender.ExtenderTestCase -- 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, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-3625) Update

by Dimitris Andreadis (JIRA)

Update ------- Key: JBAS-3625 URL: http://jira.jboss.com/jira/browse/JBAS-3625 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Dimitris Andreadis -- 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, 10 months

1
2
0 / 0

[JBoss JIRA] Resolved: (JBAS-1941) JBoss-4.0.1Sp1 startup slow (server hangs in SQLUtil.tableExists() method)

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1941?page=all ] Dimitris Andreadis resolved JBAS-1941. -------------------------------------- Fix Version/s: (was: JBossAS-4.0.5.GA) Resolution: Cannot Reproduce Bug I've closing this, if it cannot be reproduced by Alexey. > JBoss-4.0.1Sp1 startup slow (server hangs in SQLUtil.tableExists() method) > -------------------------------------------------------------------------- > > Key: JBAS-1941 > URL: http://jira.jboss.com/jira/browse/JBAS-1941 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.1 SP1 > Environment: Effect takes place on the Solaris (SunOS Release 5.8) as well as the Windows (XP) Platform. The System uses a DB2 Database (UDB Runtime Client V8.1 connects via DB2Connect to DB2 Server V7.0 running on OS390) > I observed the same Effect on other JBoss releases (JBoss-3.2.5, JBoss-4.0.2) > Reporter: helly15 > Assigned To: Alexey Loubyansky > Attachments: JBoss4_Startup 2005-06-21 17-59-35.profile > > > I am moving from JBoss-3.2.1 to JBoss-4.0.1Sp1. The problem I am facing is that it takes JBoss-4.0.1 over 10 minutes to start, while JBoss-3.2.1 started up in under 3 minutes. > I did a profiling of the startup process using the Eclipse Profiler. The profiling revealed that the server spends nearly 10 seconds in the method SQLUtil.tableExists() every time the method is called during the startup process. This method is called once for every table that exists in the application (32 tables). This leads to the lengthy startup time. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2057) Need an EJB3 mbean JSR-77 mapping

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2057?page=all ] Dimitris Andreadis updated JBAS-2057: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.GA) > Need an EJB3 mbean JSR-77 mapping > --------------------------------- > > Key: JBAS-2057 > URL: http://jira.jboss.com/jira/browse/JBAS-2057 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Management services, EJB3 > Reporter: Scott M Stark > Assigned To: Bill Burke > Priority: Critical > Fix For: JBossAS-4.0.6.CR1 > > > Deployment of an ejb3 component should result in an jsr-77 ejb mbean for integration into the management tools. I don't know if an ejb3 deployment can just be treated as an ejb2.1 deployment by the LocalJBossServerDomain and this will just 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1182) Thread creation during deactivate_object

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1182?page=all ] Dimitris Andreadis updated JBAS-1182: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.GA) I still don't see any progress in the jacorb bugzilla > Thread creation during deactivate_object > ---------------------------------------- > > Key: JBAS-1182 > URL: http://jira.jboss.com/jira/browse/JBAS-1182 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: IIOP service > Reporter: SourceForge User > Assigned To: Francisco Reverbel > Fix For: JBossAS-4.0.6.CR1 > > > SourceForge Submitter: kevinconner . > This is a duplicate of bug 527 in the JacORB database. > It is being submitted here so that a patch may be > applied to the JBoss patched version of JacORB. > http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=527 > The deactiviation of an object causes Thread creation > in AOM.remove. Would it > be possible to use a thread pool instead of creating > new threads? > A possible solution could be to have the > RequestController provide a > notification mechanism (instead of a thread waiting on > object completion) and > have the notification request work from the thread pool. > The attached patch uses a threadpool to prevent the > thread creation but I don't > believe it is the best solution. > Index: AOM.java > =================================================================== > RCS file: > /cvsroot/jacorb/JacORB/src/org/jacorb/poa/AOM.java,v > retrieving revision 1.29 > diff -u -r1.29 AOM.java > --- AOM.java 6 May 2004 12:40:00 -0000 1.29 > +++ AOM.java 21 Oct 2004 14:38:11 -0000 > @@ -27,6 +27,9 @@ > import org.jacorb.poa.util.ByteArrayKey; > import org.jacorb.poa.util.POAUtil; > import org.jacorb.poa.util.StringPair; > +import org.jacorb.util.threadpool.Consumer; > +import org.jacorb.util.threadpool.ConsumerFactory; > +import org.jacorb.util.threadpool.ThreadPool; > > import > org.omg.PortableServer.POAPackage.ObjectAlreadyActive; > import org.omg.PortableServer.POAPackage.ObjectNotActive; > @@ -69,6 +72,23 @@ > /** a lock to protect two consecutive operations > on the list, used > in remove() */ > private Object deactivationListLock = > new Object(); > + > + private Consumer deactivationConsumer = new > Consumer() { > + public void doWork(final Object job) { > + try { > + ((Runnable)job).run() ; > + } catch (final Throwable th) { > + logger.info("Unhandled exception > during deactivation", th); > + } > + } > + } ; > + private ConsumerFactory > deactivationConsumerFactory = new ConsumerFactory() { > + public Consumer create() { > + return deactivationConsumer ; > + } > + } ; > + > + private ThreadPool deactivationPool = new > ThreadPool(deactivationConsumerFactory) ; > > private AOM() > { > @@ -348,8 +368,7 @@ > final POA poa_ = poa; > final boolean cleanupInProgress_ = > cleanupInProgress; > > - Thread thread = new Thread("AOM_RemovalThread") > - { > + final Runnable job = new Runnable() { > public void run() > { > _remove( > @@ -361,8 +380,8 @@ > ); > } > }; > - > - thread.start(); > + > + deactivationPool.putJob(job) ; > } -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1180) bi-pass JacORB interceptors for purely local invocations

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1180?page=all ] Dimitris Andreadis updated JBAS-1180: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.GA) I still don't see any progress in the jacorb bugzilla > bi-pass JacORB interceptors for purely local invocations > -------------------------------------------------------- > > Key: JBAS-1180 > URL: http://jira.jboss.com/jira/browse/JBAS-1180 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: IIOP service > Affects Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > Assigned To: Francisco Reverbel > Fix For: JBossAS-4.0.6.CR1 > > > SourceForge Submitter: marklittle . > I registered the following issue > (http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi? > id=526) with JacORB bugzilla a couple of weeks ago, but > no response so far. I think it's sufficiently important to > register here too in case you are able to do something > for JBoss. > In the current implementation of JacORB (2.2), if I > register an interceptor with the ORB, then > it appears that all invocations to all objects go through > that interceptor, > even if they are co-located with the invoker. I > understand that rational given > the PI specification and the original intention behind > that work: to make > local invocations and remote invocations similar. > However, most ORBs provide a way of doing a local, no- > interceptor > optimization. The JDK 1.4 ORB is one example (though > that takes the other > extreme and won't invoke interceptors on any local > object). > Orbix 2000, for example, supports multiple ORBs and > POAs within the same VM, > and interceptors are registered on a per-ORB basis, not > a per VM basis as > appears to be the case with JacORB. You can also turn > on local optimizations > for the individual ORBs. > The reason for asking for this optimization is > performance. With a very simple > test, where the interceptor does nothing, we see a 66% > degredation in > performance for local calls. For example, with no > interceptors we can get > 3000 invocations, whereas > with a "null" interceptor this is around 1000. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3272) update JBossRemoting to version 2.0.0

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3272?page=all ] Dimitris Andreadis updated JBAS-3272: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.GA) We won't upgrade remoting for jboss 4.0.5.GA, since jbossws-1.0.4 (that work with remoting 2) will be release in Oct. > update JBossRemoting to version 2.0.0 > ------------------------------------- > > Key: JBAS-3272 > URL: http://jira.jboss.com/jira/browse/JBAS-3272 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Remoting > Reporter: Tom Elrod > Assigned To: Tom Elrod > Fix For: JBossAS-4.0.6.CR1 > > > Need to update JBossAS to include jboss-remoting.jar for version 2.0.0.GA of JBossRemoting. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2193) abstract schema name with word limit in name

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2193?page=all ] Dimitris Andreadis updated JBAS-2193: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.GA) > abstract schema name with word limit in name > -------------------------------------------- > > Key: JBAS-2193 > URL: http://jira.jboss.com/jira/browse/JBAS-2193 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.3RC1 > Environment: OS: Windows XP and FreeBsd > Database: PostgreSQL 7.4 > Reporter: Yura Kravchuk > Assigned To: Alexey Loubyansky > Priority: Minor > Fix For: JBossAS-4.0.6.CR1 > > > We have few CMP entity beans with abstract schema name with word "limit", e.g. limitation_categories, limitation_durations, etc. We using dynamiq QL. It seems that query parser confused by word "limit" in schema name and thinks that it's clause LIMIT which placed before FROM clause. I changed schema name to lim_categories for entity bean and all works perfectly. > Herewith exception: > 17:02:28,671 INFO [STDOUT] javax.ejb.EJBException: SELECT COUNT($limit_category.id) FROM limit_category AS $limit_categ > ory; CausedByException is: > Can't count entities by expression and parameters; CausedByException is: > Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71. > Was expecting: > "FROM" ... > ; CausedByException is: > Can't count entities by expression and parameters; CausedByException is: > Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71. -- 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, 10 months

1
0
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 September 2006