August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBMESSAGING-89) Repository reorganization

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-89?page=all ] Ovidiu Feodorov updated JBMESSAGING-89: --------------------------------------- Fix Version/s: 1.2.0.Alpha1 (was: 1.2.1) Assignee: Ovidiu Feodorov > Repository reorganization > ------------------------- > > Key: JBMESSAGING-89 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-89 > Project: JBoss Messaging > Issue Type: Task > Components: Build System > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Fix For: 1.2.0.Alpha1 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The current JBoss Messaging CVS module (jboss-head/jms) contains unused directories and files, byproducts of alpha development and refactoring. > Clean-up the module and keep only what is necessary. > Rename the current "messaging" module "jbossmq", and change "jms" to "messaging" -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-175) Unnecessary junit.timeout2 used by tests/build.xml

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-175?page=all ] Ovidiu Feodorov updated JBMESSAGING-175: ---------------------------------------- Fix Version/s: 1.2.0.Alpha1 (was: 1.2.1) > Unnecessary junit.timeout2 used by tests/build.xml > -------------------------------------------------- > > Key: JBMESSAGING-175 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-175 > Project: JBoss Messaging > Issue Type: Task > Components: Build System > Reporter: Ovidiu Feodorov > Assigned To: Tim Fox > Priority: Minor > Fix For: 1.2.0.Alpha1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Instead of using junit.timeout2 we should figure out why the normal timeout is not picked up in Tim's case. Revert to using junit.timeout. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-319) Enable the Messaging build to use component-info.xml and versioned dependencies

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-319?page=all ] Ovidiu Feodorov updated JBMESSAGING-319: ---------------------------------------- Fix Version/s: 1.2.0.Alpha1 (was: 1.2.1) > Enable the Messaging build to use component-info.xml and versioned dependencies > ------------------------------------------------------------------------------- > > Key: JBMESSAGING-319 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-319 > Project: JBoss Messaging > Issue Type: Task > Components: Build System > Reporter: Ovidiu Feodorov > Assigned To: Ovidiu Feodorov > Fix For: 1.2.0.Alpha1 > > Original Estimate: 3 days > Remaining Estimate: 3 days > -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBESB-65) Tidy-up ESB common structure

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-65?page=all ] Mark Little updated JBESB-65: ----------------------------- Fix Version/s: 4.0 (was: 4.0 Beta 1) > Tidy-up ESB common structure > ---------------------------- > > Key: JBESB-65 > URL: http://jira.jboss.com/jira/browse/JBESB-65 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: ESB Core, Documentation > Affects Versions: 4.0 Alpha 1 > Reporter: Mark Little > Assigned To: Johan Kumps > Priority: Minor > Fix For: 4.0 > > > - common\src\org\jboss\soa\esb\common\EsbSysProps.java > 1) Needs name changing, that could imply we need a generic System/Configuration/Property management component/ > 2) Need to standardise naming and casing: > jbossEsb.mail.smtp.host to (example) jboss.soa.esb.endpoint.email.host this provides a structured / 'packaged' grouped property. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3101) Javassist only client side dependencies for proxy frameworks

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3101?page=all ] Adrian Brock updated JBAS-3101: ------------------------------- Comment: was deleted > Javassist only client side dependencies for proxy frameworks > ------------------------------------------------------------ > > Key: JBAS-3101 > URL: http://jira.jboss.com/jira/browse/JBAS-3101 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web Services, Build System, Hibernate service > Affects Versions: JBossAS-4.0.4.CR2 > Reporter: Scott M Stark > Priority: Critical > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.4.GA > > > With client side proxy factory dependencies showing up, we need to restrict this to a single framework. javassit is the most widely used in terms of overall dependencies, so it should be the default proxy factory framework as well. -- 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, 11 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.5.GA (was: JBossAS-4.0.5.CR1) > 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.5.GA > > > 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

17 years, 11 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.5.GA (was: JBossAS-4.0.5.CR1) > 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.5.GA > > > 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

17 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3371) Replace Sun activation.jar with a source-code friendly licensed implementation

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3371?page=all ] Dimitris Andreadis updated JBAS-3371: ------------------------------------- Summary: Replace Sun activation.jar with a source-code friendly licensed implementation (was: Replace Sun activation.jar with classpathx-jaf.jar v1.0) Fix Version/s: (was: JBossAS-3.2.8.SP2) Assignee: Dimitris Andreadis Priority: Major (was: Critical) > Replace Sun activation.jar with a source-code friendly licensed implementation > ------------------------------------------------------------------------------ > > Key: JBAS-3371 > URL: http://jira.jboss.com/jira/browse/JBAS-3371 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Other > Reporter: Dimitris Andreadis > Assigned To: Dimitris Andreadis > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1 > > > GNU JAF: JavaBeans? Activation Framework, is a drop-in replacement for sun's implementation found in activation.jar > The sources can be downloaded from here: > http://www.gnu.org/software/classpathx/jaf/jaf.html > We need to test to see if there are any issues with replacing this. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3372) Replace Sun javamail (mail.jar) with a source-code friendly licensed implementation

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3372?page=all ] Dimitris Andreadis updated JBAS-3372: ------------------------------------- Summary: Replace Sun javamail (mail.jar) with a source-code friendly licensed implementation (was: Replace Sun javamail (mail.jar) with classpathx-mail.jar v1.0) Fix Version/s: (was: JBossAS-3.2.8.SP2) Assignee: Dimitris Andreadis Priority: Major (was: Critical) > Replace Sun javamail (mail.jar) with a source-code friendly licensed implementation > ----------------------------------------------------------------------------------- > > Key: JBAS-3372 > URL: http://jira.jboss.com/jira/browse/JBAS-3372 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Other > Reporter: Dimitris Andreadis > Assigned To: Dimitris Andreadis > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1 > > > GNU JavaMail is a free implementation of the JavaMail API specification, version 1.3. > We want to use it as a replacement for Sun's mail.jar > The sources can be downloaded from here: > http://www.gnu.org/software/classpathx/javamail/javamail.html > Issues with replacement by classpathx-mail: > jbossws must be patched to use gnu-handlers instead of sun-handlers > +//import com.sun.mail.handlers.multipart_mixed; > +import gnu.mail.handler.MultipartMixed; > +//import com.sun.mail.handlers.text_html; > +import gnu.mail.handler.TextHtml; > +//import com.sun.mail.handlers.text_plain; > +import gnu.mail.handler.TextPlain; > testsuite/src/main/org/jboss/test/classloader/resource/ResourceTest.java > must be patched, because it refers to javamail.default.address.map and javamail.default.providers while in classpathx-mail these are named javamail.address.map and javamail.providers in classpathx-mail This change isn't essential to javamail; those files (+javamail.jar) were chosen because they were supposed to be always there. The real purpose of ResouceTest.java is to check access to resouces, so any adequate resources could be the test objects. But the resource test is executed very often and in different contexts. Therefore the adjustment is important for testsuite. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBESB-35) Create trailmap

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-35?page=comments#action_12340415 ] Mark Little commented on JBESB-35: ---------------------------------- As long as there's a step-by-step approach, it doesn't need to use HTML. A pdf doc, or a txt file would be enough. I mentioned HTML because that's the format I'm used to seeing. > Create trailmap > --------------- > > Key: JBESB-35 > URL: http://jira.jboss.com/jira/browse/JBESB-35 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Examples > Reporter: Mark Little > Assigned To: Daniel Brum > Fix For: 4.0 Beta 1 > > > Add an example and walk through it for developers. -- 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, 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 August 2006