Ive simplified the examples and made them more configurable.
Ive split the server and client classpath. the server does not now use the same classpath as the client when spawned. The client classpath now also only includes the jbm client jars and netty.
The server also loads its settings, i.e. -XmX2048M, in from the file server.properties. For examples that use different properties the build file just over rides this with a different props file, take a look at one to see.
Ive run all the examples but i'm getting a few errors with some. This is prior to my changes so I'll look at these separately.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233603#4233603
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233603
Ive made some changes to the logging infrastructure to remove the log4j deoendency, the only thing we need it for is to compile the 'Log4jLoggerHandler', This how it works.
Ive changed the JBMLoggerPlugin to redirect to JUL, this now means that the MC now uses this instead of log4j.
Ive added a JUL Formatter so the logging looks something like what we would expect and ive added/updated logging.properties file to use this and also a filehandler. We can tweak the formatter as we need or make it more configurable.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233601#4233601
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233601
"alesj" wrote : "david.lloyd(a)jboss.com" wrote : While you're going through the API to do this refactor, it might be a good time to change all the parameters which represent a bean name from being "Object" to "String".
| |
| Isn't this already the case on BeanMetaData?
|
| Doing this elsewhere would be wrong,
| as you don't really know or care what kind of type do other components use for their name.
Of course you do. The name is a String so why support anything else? And even if you do decide to support something like ObjectName or whatever, you should use overloading for that purpose. It doesn't make sense to allow Object. It implies that I can pass in a HashMap, or a Socket, or an AudioFileFormat, or ...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233594#4233594
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233594
Looking at the code, I saw I did a crappy job of how we check for bean validators.
It just doesn't scale well by default. :-(
So, I did a little change, creating a KernelBeanValidator hanging from Kernel.
Hence it means it gets configured as part of Kernel.
It's a bit twisted by how it's done, in order to be back compatible.
You can trace the changes from KernelControllerContextAction::getBeanValidatorBridge.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233583#4233583
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233583
anonymous wrote : Exceptions on the console are generally too verbose and we have, in the past, made a concerted effort to reduce this. This is happening in other projects as well, not just ours.
OK, that is reasonable.
Can we at least do something about the default logging in the ESB Server that we ship. The amount of logging from jbpm and hibernate really floods the log file. Using a tool like tail on server.log does not work that great at the moment.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4233514#4233514
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4233514