[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, 9 months
[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, 9 months
[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, 9 months