February 2010 - jboss-dev-forums - Jboss List Archives

[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"

by Kabir Khan

JBoss development, A new message was posted in the thread "Profiling the dependency project": http://community.jboss.org/message/525413#525413 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- One thing that is taking a lot of time in the wrong order benchmark is in AbstractDependencyItem.resolve(). Since the dependentState is null we end up doing this: public boolean resolve(Controller controller) { boolean previous = resolved; ControllerContext context; if (dependentState == null) context = controller.getInstalledContext(iDependOn); else { context = controller.getContext(iDependOn, dependentState); //<<<< Here if (context == null) { if (ControllerState.INSTALLED.equals(dependentState)) context = controller.getInstalledContext(iDependOn); //<<<< Here } } if (context == null) { resolved = false; ControllerContext unresolvedContext = controller.getContext(iDependOn, null); //<<<< Here if (unresolvedContext != null && ControllerMode.ON_DEMAND.equals(unresolvedContext.getMode())) { try { controller.enableOnDemand(unresolvedContext); } catch (Throwable ignored) { if (log.isTraceEnabled()) log.trace("Unexpected error", ignored); } } } else { addDependsOnMe(controller, context); resolved = true; } These calls account for about 50% of the time spent. Changing to: context = controller.getContext(iDependOn, dependentState); //<<<< Here //if (context == null) //{ // if (ControllerState.INSTALLED.equals(dependentState)) // context = controller.getInstalledContext(iDependOn); //<<<< Here //} Gives a perfomance boost to the wrong order test of about 15%. I have committed this. What I would really like is to be able to is somehow roll the getting of the context and the on demand context into one, something along the lines of public boolean resolve(Controller controller) { boolean previous = resolved; ControllerState state = dependentState == null ? ControllerState.INSTALLED : dependentState; ControllerContext context = controller.getContextAtStateOrEnableOnDemand(iDependOn, state); if (context == null) { resolved = false; } else { addDependsOnMe(controller, context); resolved = true; } } That way we only query for the context once instead of twice (three times before my last change) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525413#525413

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"

by Kabir Khan

JBoss development, A new message was posted in the thread "Profiling the dependency project": http://community.jboss.org/message/525378#525378 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I created a FastCopyOnWriteSet implementation, unfortunately its performance degrades a lot with performance as well: prefill 0: 7634ms prefill 10: 9127ms prefill 100: 27898ms I have attached the source, but I guess it is the copying upon modification that is the main overhead of the FCOWS and COWAS? Putting this into the contextsByState I see a slight worsening in performance. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525378#525378

16 years, 1 month

1
0
0 / 0

[jBPM Development] New message: "Re: Description elements in jPDL schema"

by Alejandro Guizar

JBoss development, A new message was posted in the thread "Description elements in jPDL schema": http://community.jboss.org/message/525350#525350 Author : Alejandro Guizar Profile : http://community.jboss.org/people/alex.guizar@jboss.com Message: -------------------------------------------------------------- > sebastian.s: > For my part I don't agree fully. I'd like to see them parsed in (2), > too. This could be valueable information at runtime which could be > retrieved via the API to use it in your own application. It would also > allow you to use short names for transititions while having long > descriptions available in case you need them. I believe that transition descriptions would be useful too, but the description element as it appears in the current schema does not seem to fit that purpose. The transitionType definition appears below. Annotations have been removed for brevity. <complexType name="transitionType"> <sequence> <element name="description" minOccurs="0" maxOccurs="unbounded" type="string" /> <group ref="tns:eventListenerGroup" minOccurs="0" maxOccurs="unbounded" /> </sequence> <attribute name="name" type="string"/> <attribute name="to" type="string"/> <attribute name="g" type="string"/> </complexType> Note that: * in the description element, maxOccurs is set to unbounded. The contents of which description element should be set as the transition description? The first? The concatenation of all of them? Why are multiple descriptions allowed in the first place? * multiple event listeners may occur after the description(s). In my original comment I thought the intent was to allow each event listener to be preceded by a description, but the schema as it currently stands does not allow that. In sum it all comes down to intent. Is the description intended to apply to the transition (in which case maxOccurs should be set to one) or to optionally precede each event listener (in which case the unbounded maxOccurs should be moved from the description and the eventListenerGroup to the sequence)? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525350#525350

16 years, 1 month

1
0
0 / 0

[jBPM Development] New message: "Description elements in jPDL schema"

by Alejandro Guizar

JBoss development, A new message was posted in the thread "Description elements in jPDL schema": http://community.jboss.org/message/525341#525341 Author : Alejandro Guizar Profile : http://community.jboss.org/people/alex.guizar@jboss.com Message: -------------------------------------------------------------- This topic is a https://jira.jboss.org/jira/browse/JBPM-2560 offshot. Elements having a description in the schema that is either not parsed, not exposed in the API, or both. 1. swimlane description is parsed but not exposed in the API. 2. transition and timer allow unlimited description elements preceding event listeners. The descriptions are not parsed. 3. wireObjectType, javaType, scriptType, qlType and mailType allow unlimited description elements preceding various other elements. Again, the descriptions are not parsed. To me, only (1) should be acted upon, in (2) and (3) the description only appears to serve documentation purposes. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525341#525341

16 years, 1 month

1
0
0 / 0

[EJB 3.0 Development] New message: "Re: How to get all session beans from JBoss server"

by Thomas Bartsch

JBoss development, A new message was posted in the thread "How to get all session beans from JBoss server": http://community.jboss.org/message/525331#525331 Author : Thomas Bartsch Profile : http://community.jboss.org/people/tbar0711 Message: -------------------------------------------------------------- I'm very interested. It would be great to hear from you. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525331#525331

16 years, 1 month

1
0
0 / 0

[JBoss Build System Development] New message: "AS trunk, jbossall-client.jar MANIFEST.MF - Property values not being set"

by jaikiran pai

JBoss development, A new message was posted in the thread "AS trunk, jbossall-client.jar MANIFEST.MF - Property values not being set": http://community.jboss.org/message/525321#525321 Author : jaikiran pai Profile : http://community.jboss.org/people/jaikiran Message: -------------------------------------------------------------- The latest AS trunk build is generating the JBOSS_HOME/client/jbossall-client.jar MANIFEST.MF with unsubstituted property values: ... Specification-Title: ${specification.title} Specification-Version: ${specification.version} Specification-Vendor: ${specification.vendor} Implementation-Title: ${implementation.title} Implementation-Version: ${implementation.version} Implementation-Vendor: ${implementation.vendor} Implementation-Vendor-Id: ${implementation.vendor.id} ...//rest of it Looking at the build/build.xml i don't see where the values for these properties are being set (i haven't looked into much details, though). On a related note, the Classpath entries in that MANIFEST.MF - is it expected to contain entries of all jars that's present in JBOSS_HOME/client folder? Or what's the criteria of adding a Classpath entry in MANIFEST.MF? I see that many jars present in JBOSS_HOME/client are missing from that list. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525321#525321

16 years, 1 month

1
0
0 / 0

[EJB 3.0 Development] New message: "Re: EJBTHREE-1998: TestSuite Client Dependencies from JBOSS_HOME"

by jaikiran pai

JBoss development, A new message was posted in the thread "EJBTHREE-1998: TestSuite Client Dependencies from JBOSS_HOME": http://community.jboss.org/message/525315#525315 Author : jaikiran pai Profile : http://community.jboss.org/people/jaikiran Message: -------------------------------------------------------------- Any specific reason why we are adding individual jars from the JBOSS_HOME to the classpath, instead of just adding the JBOSS_HOME/client folder to the classpath. Something like this, which i did to get the testcases passing: [jpai@localhost testsuite]$ svn diff build-test.xml Index: build-test.xml =================================================================== --- build-test.xml (revision 100789) +++ build-test.xml (working copy) @@ -325,6 +325,7 @@ <path id="client.classpath">  + <fileset dir="${location.client.lib}" includes="*.jar"/> <pathelement path="${location.client.lib.commons-logging}" /> <pathelement path="${location.client.lib.jbossall}" /> <pathelement path="${location.client.lib.jbossxb}" /> Ideally, it should have been just JBOSS_HOME/client/jbossall-client.jar. But i see that the MANIFEST.MF of that jar is incomplete. So why not just JBOSS_HOME/client/*.jar. That way, we don't have to keep changing our build file if the jar file names changes (like in this SNAPSHOT case). If there are no objections, then i'll commit this patch (and also remove any subsequent, redundant pathelements from the classpath). -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525315#525315

16 years, 1 month

1
0
0 / 0

[EJB 3.0 Development] New message: "Re: How to get all session beans from JBoss server"

by jaikiran pai

JBoss development, A new message was posted in the thread "How to get all session beans from JBoss server": http://community.jboss.org/message/525294#525294 Author : jaikiran pai Profile : http://community.jboss.org/people/jaikiran Message: -------------------------------------------------------------- I am not much familiar with how this can be done in JBoss AS 4.2.3. However, if you are willing to use JBoss AS 5.1.0, then we can point you to some of our EJB3 project code on how this can be done. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525294#525294

16 years, 1 month

1
0
0 / 0

[EJB 3.0 Development] New message: "Re: EJBTHREE-1998: TestSuite Client Dependencies from JBOSS_HOME"

by jaikiran pai

JBoss development, A new message was posted in the thread "EJBTHREE-1998: TestSuite Client Dependencies from JBOSS_HOME": http://community.jboss.org/message/525293#525293 Author : jaikiran pai Profile : http://community.jboss.org/people/jaikiran Message: -------------------------------------------------------------- > ALRubinger wrote: > > > For now the tests are coming back mostly OK I think, though the view is clouded due to CNFE on some stuff from Hibernate Core. This should be temporary; the mapper responsible for removing version numbers from JAR names in the AS build is not handling "SNAPSHOT" properly, and Hibernate in AS is now a snapshot. > I'll take a look at this today. I remember seeing something like this locally around a month back, but hadn't spent much time on it. One of the reasons why AS is using the hibernate SNAPSHOT is to run our EJB3 testsuite and the AS testsuite to identify any genuine regressions, before going for a Hibernate release. So getting a clean EJB3 testsuite run is going to help The other reason why the mapper has to be fixed is because, even though the AS doesn't allow SNAPSHOT version to be included in the component-matrix, i keep using SNAPSHOT on my local checkout of AS trunk (and i believe others do too). So if there's a bug around that, then fixing it will help. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525293#525293

16 years, 1 month

1
0
0 / 0

[jBPM Development] New message: "Re: timer attribute names"

by Alejandro Guizar

JBoss development, A new message was posted in the thread "timer attribute names": http://community.jboss.org/message/525278#525278 Author : Alejandro Guizar Profile : http://community.jboss.org/people/alex.guizar@jboss.com Message: -------------------------------------------------------------- > Hmmm delay is also not quite right. Since with EL you can have fixed dates. Since the 'delay' in (business) time always results in a (due) date. So I'm kind of ambivalent. Right. Maybe the problem is mixing date and duration in the same attribute. I looked at java.util.Timer and I'd like to have the same kind of clean, concise parameters. What if: * *duedate* was a string literal or EL expression that returned either Date or String. If the result is a String, parse a Date based on the configured date-time format. * *delay* was a duration literal, calculated from the Date obtained from the *duedate* attribute or the current time if duedate is absent. * *duedatetime* was phased out instead, since *duedate* would now permit string literals. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525278#525278

16 years, 1 month

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-dev-forums February 2010