March 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 examples

by ataylor

FYI, the examples don't shutdown correctly when the server is started as there are some threads still hanging about. i'll raise a JIRA for this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222055#4222055 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222055

15 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 examples

by ataylor

Ive added a new jms example template into trunk. There should also be a core one butthat isn't complete yet. The jms template. each example should live in its own directory under examples/jms and should have its own build.xml file and src folder. The example itself will extend JMSExample and implement the runExample() method, See QueueExample or TopicExample. The JMSExample class takes care of starting the server (if needed) and deploying any topics/queues etc. If you look under examples/jms/common/config you'll see the config files that are used by the server. These can be modified if needed. The build file doesnthave to do much since all the compile and run scripts are in the base script. You just have to call a couple of ant targets, again see the queue or topic example and you'll see. The core tests should be the same but found under examples/core. The only difference is how we start the server. The CoreExample base class should just programmatically start the server with the correct configuration. Take a look and if any thing needs change or improving feel free to do it or post suggestion here. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222053#4222053 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222053

15 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Debug Logging

by david.lloyd＠jboss.com

"bradsdavis" wrote : Within that document, they also suggest that the debug level is for: | | anonymous wrote : | | Developer or in depth information required for support is the basis for this priority. | | | | That doesn't suggest that most will have debugging enabled in a production environment. We should be targeting production for efficient business processing. | The suggestion occurs later in the document. This has been discussed to death over several years, so I'm not going to argue about it. It's the policy. "bradsdavis" wrote : I haven't seen that isDebugEnabled is deprecated. Can you shoot me a link to that? Not Apache clogging, JBoss common logging. http://anonsvn.jboss.org/repos/common/common-logging-spi/trunk/src/main/j... "bradsdavis" wrote : Also, putting general debug messages that log full objects can lead to Hibernate lazy loading of objects when there is not necessarily a reason to load the object. This is definitely a place for efficiency bugs to creep up. Sounds like it ought to be a trace message. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222052#4222052 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222052

15 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Debug Logging

by bradsdavis

Within Commons Logging's documentation: http://commons.apache.org/logging/apidocs/index.html[/url] anonymous wrote : | Performance is often a logging concern. By examining the appropriate property, a component can avoid expensive operations (producing information to be logged). | | For example, | | if (log.isDebugEnabled()) { | ... do something expensive ... | log.debug(theResult); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222049#4222049 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222049

15 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Debug Logging

by bradsdavis

Within that document, they also suggest that the debug level is for: anonymous wrote : | Developer or in depth information required for support is the basis for this priority. | That doesn't suggest that most will have debugging enabled in a production environment. We should be targeting production for efficient business processing. I haven't seen that isDebugEnabled is deprecated. Can you shoot me a link to that? Also, putting general debug messages that log full objects can lead to Hibernate lazy loading of objects when there is not necessarily a reason to load the object. This is definitely a place for efficiency bugs to creep up. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222047#4222047 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222047

15 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Debug Logging

by david.lloyd＠jboss.com

Have a look at http://www.jboss.org/community/docs/DOC-11282 - in particular, any logging that's frequent enough to require filtering should be logged at TRACE, not DEBUG (this is why, in JBoss Common Logging, isDebugEnabled() is deprecated). If these logs are infrequent, then there's no need to optimize it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222044#4222044 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222044

15 years

1
0
0 / 0

[Design of OSGi Integration] - Re: Why do we need a Felix integration

by adrian＠jboss.org

anonymous wrote : | Hi Scott/Adrian, | | perhaps you could comment on | | http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222021#4222021 | | I'd like to understand better what an MC based OSGi Framework | implementation may offer over any other OSGi Framwork implementation. | My thoughts can be found in the earlier posts in this forum, e.g. http://www.jboss.org/index.html?module=bb&op=viewtopic&t=103025 http://www.jboss.org/index.html?module=bb&op=viewtopic&t=130500 http://www.jboss.org/index.html?module=bb&op=viewtopic&t=131151 Those + other threads explain how I see it being implemented. Basically all JBoss deployments and services should appear to the OSGi api user as OSGi bundles/services. (Eventually, that includes for example being able to get a service reference on an EJB remote/local interface.) To me this is the key feature since OSGi provides a standard api for controlling deployments and services instead of using a non-spec jboss api. And vice-versa you should be able to inject OSGi services into pojos/mbeans, etc. This should be as seamless as possible. OSGi bundle <-> Deployment ServiceReference <-> MC ControllerContext Somebody deploying a POJO shouldn't have to implement an OSGi api to make it work, that defeats the point of them being POJOs, View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222043#4222043 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222043

15 years

1
0
0 / 0

[Design of JBoss jBPM] - Debug Logging

by bradsdavis

I am going to clean up the trunk today to put isDebugEnabled statements around all log.debug calls. This will improve efficiency when debugging logs are not enabled. Please make sure to include log.isDebugEnabled() { log.debug... } around debug logs. If you dont, any string concatenation contained within the debug will occur even if the log is not set to debug. For example within AbstractTokenBaseCommand, the following statement: | log.debug("executing " + this); | This will result in 1) the to string being called on the object AbstractTokenBaseCommand then 2) the method log.debug being called. In other words, Java is going to resolve all parameters to method invocations before the method is called. The log statement should instead be: | if(log.isDebugEnabled()) | { | log.debug("executing " + this); | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222041#4222041 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222041

15 years

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Server side thread leak?

by rachmato＠redhat.com

Hi Galder The creeping thread count increase has only been observed so far when running the ant target jboss-all-config-tests, which runs a lot of the basic AS tests against a single instance of the 'all' configuration. The little report generator I wrote isn't applicable to a two server configuration, but could be adapted. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222031#4222031 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222031

15 years

1
0
0 / 0

[Design of OSGi Integration] - Why do we need a Felix integration

by thomas.diesler＠jboss.com

Bill asks: anonymous wrote : Why do we need Felix? The reasoning goes like this: JBossAS wants to leverage core concepts from OSGi, (e.g. jboss services want to provide classloader semantics to partially expose code that can then be consumed by other jboss services). This can either be done via jboss proprietary classloading descriptors or via standard OSGi manifest headers. JBossOSGi is about the latter. Ultimately, you can deploy standard OSGi bundles as jboss services. To reach that goal is a parallel effort #1 Provide an OSGi Framework/Runtime #2 Migrate jboss services to OSGi bundles The current idea is that we have an OSGi Facade on top of JBossMC, essentially providing an OSGi Framework based on MC. OSGi bundles should not have a dependency on a particular OSGi implementation, instead they have a dependency on the OSGi core and maybe compendium and other specs. Having an Apache Felix integration allows us to migrate, test, document, etc our current services to OSGi while not (yet) having an OSGi Framework implementation that is optimized for our needs (i.e. JBossMC based) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222021#4222021 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222021

15 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2009