[Design of JBoss ESB] - Logging of Exceptions in ActionProcessingPipeline
by beve
Currently, if an exception if thrown from an action in the action pipeline it will be logged with a debug level to server.log. If there is no fault to you might simply get something like this in the server console:
10:16:30,448 WARN [ActionProcessingPipeline] No fault address defined for fault message! To: JMSEpr [ PortReference < <wsa:Address j...
|
I find it useful to have the exception logged to the console at an error level as well which makes testing much easier and faster as you don't need to look through the server.log which is filled up with other perhaps unrelated log statements.
I'm suggesting that we add the following to the ActionProcessingPipeline:
| else if (!throwRuntime)
| {
| LOGGER.error("Exception caught while processing the action pipeline: ", ex);
| faultTo(callDetails, Factory.createErrorMessage(Factory.UNEXPECTED_ERROR, message, ex));
| }
|
This will not log the message header but this is not always that useful, at least I don't find it useful and if I need to inspect it I can look in the server.log.
While I'm on the subject of logging I really don't like that by default our jbossesb-server is configured with log level of debug for most packages if not all. I'd much rather have error or info logging as the default and let user configure what ever they want. This would in my opinion improve the users experience.
Any thoughts on this?
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233498#4233498
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233498
15 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - JBM 2 and logging
by ataylor
Ive been looking at removing log4j as a dependency for the user and i have come unstuck.
I'll explain how our logging currently works so everyone understands the problem
All JBM classes use JUL as their logger. When running within the AS this is fine as the AS takes care of redirecting these log calls through the jboss logger which uses log4j by default.
When we run standalone we depend on the Microcontainer and its dependencies. These dependencies use jboss logging which redirects its logging to what ever logging plugin class is set. If this is the null plugin class then the MC (or one of its dependencies) sets a plugin that redirects to system.out which is horrible. Because of this we provide our own plugin class JBMLoggerPlugin which currently uses log4j.
So any logging by the MC currently does this
jboss logging -> JBMLoggerPlugin -> log4j
and any JUL logging (JBM) either does
JUL -> jboss logging -> JBMLoggerPlugin -> log4j
if the jboss JUL handler is set or
JUL -> log4j
if the log4j handler is set.
Hope that makes sens, anyway, this means that our clients and server always have a dependency on log4j.
Changing the JBMLoggerPlugin to log somewhere else would solve this but it can't be JUL as you would end up with
JUL -> jboss logging -> JBMLoggerPlugin -> JUL -> etc etc
maybe we could leave the standalone server as is and provide something else for the client, maybe no handlers and just JUL, wdyt?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233490#4233490
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233490
15 years, 1 month
[Design of EJB 3.0] - Re: Injecting into the Containers
by ALRubinger
"ALRubinger" wrote : * New Deployer to Create a Metrics POJO, then attach it to the DeploymentUnit
| * Ejb3Deployer picks up the attachment and sets it upon the Ejb3JBoss5Deployment.
| * Containers get at the Metrics POJO via getDeployment().
Alternatively I can:
* Have Ejb3MetricsDeployer come along *after* Ejb3Deployer
* Pick out all Containers created from the Deployment
* Inject Metrics POJOs into each of them
...thus adding metrics becomes a concern atop EJB3. ejb3-core then relies only upon ejb3-metrics-spi, and ejb3-metrics-impl can be a JAR which includes the Ejb3MetricsDeployer definition in a jboss-beans.xml.
But ejb3-core still needs to make the calls to the underlying metrics collectors, so we still mix concerns unless we start intercepting things like createSession and destroySession via AOP.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233435#4233435
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233435
15 years, 1 month
[Design of EJB 3.0] - Injecting into the Containers
by ALRubinger
Are we still without a mechanism to inject into the Containers?
Containers are installed into MC by way of Ejb3Deployment.registerEJBContainer > MCKernelAbstraction:
AbstractBeanMetaData bean = new AbstractBeanMetaData(name, service.getClass().getName());
| bean.setConstructor(new AlreadyInstantiated(service));
| MCDependencyPolicy policy = (MCDependencyPolicy) dependencies;
| bean.setDepends(policy.getDependencies());
| bean.setDemands(policy.getDemands());
| bean.setSupplies(policy.getSupplies());
What's missing from this piece is a mechanism to do:
final BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder(bean);
| builder.createInject(beanToInject, fieldNameToInjectTo);
I don't really want to add this support to DependencyPolicy as that interface is the union of the MC and JMX Kernels.
Presently we're manually setting all sorts of stuff into the Containers via Ejb3JBoss5Deployment, like in the Ejb3Deployer:
deployment.setCacheFactoryRegistry(this.getCacheFactoryRegistry());
| // TODO: if the deployment becomes a proper MC bean, it'll get injected by MC.
| deployment.setMessageDestinationReferenceResolver(messageDestinationReferenceResolver);
| deployment.setPersistenceManagerFactoryRegistry(this.getPersistenceManagerFactoryRegistry());
| // TODO: if the deployment becomes a proper MC bean, it'll get injected by MC.
| deployment.setPersistenceUnitDependencyResolver(persistenceUnitDependencyResolver);
| deployment.setPoolFactoryRegistry(this.getPoolFactoryRegistry());
I want to add a new field to the containers to support EJB3 Metrics as a POJO. I guess for the time being I have to do this manually at the deployer level, ie:
* New Deployer to Create a Metrics POJO, then attach it to the DeploymentUnit
* Ejb3Deployer picks up the attachment and sets it upon the Ejb3JBoss5Deployment.
* Containers get at the Metrics POJO via getDeployment().
Lots of wiring.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233432#4233432
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233432
15 years, 1 month