[Design of JBossCache] - Too much jboss cache INFO logging
by dimitris＠jboss.org
I think we've discussed this before. We really don't need all this stuff to be logged as INFO, it should be DEBUG:
| 12:34:58,343 INFO [PojoCacheImpl] PojoCache version: JBossCache 'Habanero' 2.0.
| 0.CR3[ $Id: Version.java,v 1.33 2007/06/12 07:41:03 msurtani Exp $]
| 12:34:58,593 INFO [InterceptorChainFactory] interceptor chain is:
| class org.jboss.cache.interceptors.CallInterceptor
| class org.jboss.cache.interceptors.DataGravitatorInterceptor
| class org.jboss.cache.interceptors.PassivationInterceptor
| class org.jboss.cache.interceptors.ActivationInterceptor
| class org.jboss.cache.interceptors.UnlockInterceptor
| class org.jboss.cache.interceptors.PessimisticLockInterceptor
| class org.jboss.cache.interceptors.ReplicationInterceptor
| class org.jboss.cache.interceptors.NotificationInterceptor
| class org.jboss.cache.interceptors.TxInterceptor
| class org.jboss.cache.interceptors.CacheMgmtInterceptor
| class org.jboss.cache.interceptors.InvocationContextInterceptor
| 12:34:58,687 INFO [InterceptorChainFactory] interceptor chain is:
| class org.jboss.cache.interceptors.CallInterceptor
| class org.jboss.cache.interceptors.EvictionInterceptor
| class org.jboss.cache.interceptors.UnlockInterceptor
| class org.jboss.cache.interceptors.PessimisticLockInterceptor
| class org.jboss.cache.interceptors.ReplicationInterceptor
| class org.jboss.cache.interceptors.NotificationInterceptor
| class org.jboss.cache.interceptors.TxInterceptor
| class org.jboss.cache.interceptors.CacheMgmtInterceptor
| class org.jboss.cache.interceptors.InvocationContextInterceptor
| 12:34:58,734 INFO [InterceptorChainFactory] interceptor chain is:
| class org.jboss.cache.interceptors.CallInterceptor
| class org.jboss.cache.interceptors.EvictionInterceptor
| class org.jboss.cache.interceptors.DataGravitatorInterceptor
| class org.jboss.cache.interceptors.PassivationInterceptor
| class org.jboss.cache.interceptors.ActivationInterceptor
| class org.jboss.cache.interceptors.UnlockInterceptor
| class org.jboss.cache.interceptors.PessimisticLockInterceptor
| class org.jboss.cache.interceptors.ReplicationInterceptor
| class org.jboss.cache.interceptors.NotificationInterceptor
| class org.jboss.cache.interceptors.TxInterceptor
| class org.jboss.cache.interceptors.CacheMgmtInterceptor
| class org.jboss.cache.interceptors.InvocationContextInterceptor
| 12:34:58,750 INFO [InterceptorChainFactory] interceptor chain is:
| class org.jboss.cache.interceptors.CallInterceptor
| class org.jboss.cache.interceptors.UnlockInterceptor
| class org.jboss.cache.interceptors.PessimisticLockInterceptor
| class org.jboss.cache.interceptors.ReplicationInterceptor
| class org.jboss.cache.interceptors.NotificationInterceptor
| class org.jboss.cache.interceptors.TxInterceptor
| class org.jboss.cache.interceptors.CacheMgmtInterceptor
| class org.jboss.cache.interceptors.InvocationContextInterceptor
| 12:34:58,750 INFO [PojoCacheImpl] PojoCache version: JBossCache 'Habanero' 2.0.
| 0.CR3[ $Id: Version.java,v 1.33 2007/06/12 07:41:03 msurtani Exp $]
| 12:34:59,968 INFO [DefaultPartition-TomcatCache] Using marshaller org.jboss.cac
| he.marshall.VersionAwareMarshaller
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067740#4067740
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067740
16 years, 9 months
[Design of JBoss jBPM] - Barging in with a bug report
by Johan.Parent
Hi all,
I let findBugs chew on the jbpm-3.1.4.jar and it spit 220 errors and warnings. The reported errors are classified in 4 categories each with their own bug patterns, bug kinds and priority. For me the annoying "errors" are those related to correctness as it entails that the code does not do what the programmer intended in the first place. There are two such categories: correctness and multithreaded correctness. I list the reported error below.
Being a static code analyzer findBugs only looks at the bytecode so some of these "errors" may never surface in the application.
How can one go about to submit patches for these issues?
Best regards,
Johan
Multithreaded correctness bugs
anonymous wrote : M M DC_DOUBLECHECK DC: Possible doublecheck on org.jbpm.jpdl.el.impl.BeanInfoManager.mInitialized in org.jbpm.jpdl.el.impl.BeanInfoManager.checkInitialized(Logger) At BeanInfoManager.java:[lines 198-200]
| M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of org.jbpm.jpdl.el.impl.BeanInfoManager.mInitialized; locked 66% of time Unsynchronized access at BeanInfoManager.java:[line 198]
| M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of org.jbpm.persistence.db.DbPersistenceServiceFactory.configuration; locked 75% of time Unsynchronized access at DbPersistenceServiceFactory.java:[line 146]
| M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of org.jbpm.persistence.db.DbPersistenceServiceFactory.schemaExport; locked 75% of time Unsynchronized access at DbPersistenceServiceFactory.java:[line 152]
| M M IS2_INCONSISTENT_SYNC IS: Inconsistent synchronization of org.jbpm.persistence.db.DbPersistenceServiceFactory.sessionFactory; locked 66% of time Unsynchronized access at DbPersistenceServiceFactory.java:[line 155]
| M M STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE STCAL: Call to method of static java.text.DateFormat in org.jbpm.scheduler.exe.Timer.toString() At Timer.java:[line 140]
| M M STCAL_STATIC_SIMPLE_DATA_FORMAT_INSTANCE STCAL: Found static field of type java.text.DateFormat in org.jbpm.scheduler.exe.Timer.dateFormat In Timer.java
| M M STCAL_STATIC_SIMPLE_DATA_FORMAT_INSTANCE STCAL: Found static field of type java.text.DateFormat in org.jbpm.scheduler.impl.SchedulerMain.dateFormat In SchedulerMain.java
| M M STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE STCAL: Call to method of static java.text.DateFormat in org.jbpm.scheduler.impl.SchedulerMain$LogListener.timerExecuted(Date, Timer) At SchedulerMain.java:[line 60]
|
Correctness bugs
anonymous wrote : M C NP_UNWRITTEN_FIELD NP: Read of unwritten field taskInstance in org.jbpm.command.TaskInstanceEndCommand.execute() At TaskInstanceEndCommand.java:[line 36]
| M C NP_UNWRITTEN_FIELD NP: Read of unwritten field taskInstance in org.jbpm.command.TaskInstanceEndCommand.execute() At TaskInstanceEndCommand.java:[line 38]
| H C UWF_NULL_FIELD UwF: Field only ever set to null: org.jbpm.command.TaskInstanceEndCommand.taskInstance At TaskInstanceEndCommand.java:[line 31]
| M C NP_UNWRITTEN_FIELD NP: Read of unwritten field className in org.jbpm.context.exe.matcher.ClassNameMatcher.matches(Object) At ClassNameMatcher.java:[line 40]
| M C NP_UNWRITTEN_FIELD NP: Read of unwritten field className in org.jbpm.context.exe.matcher.ClassNameMatcher.matches(Object) At ClassNameMatcher.java:[line 46]
| H C UWF_NULL_FIELD UwF: Field only ever set to null: org.jbpm.context.exe.matcher.ClassNameMatcher.className At ClassNameMatcher.java:[line 30]
| M C RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE RCN: Nullcheck of tokens at line 405 of value previously dereferenced in org.jbpm.db.GraphSession.deleteProcessInstance(ProcessInstance, boolean, boolean, boolean) At GraphSession.java:[line 374]
| M C DMI_INVOKING_TOSTRING_ON_ARRAY DMI: Invocation of toString on an array in org.jbpm.db.TaskMgmtSession.findTaskInstances(String[]) At TaskMgmtSession.java:[line 89]
| M C NP_NULL_ON_SOME_PATH_EXCEPTION NP: Possible null pointer dereference of outputMap in org.jbpm.graph.node.Fork.execute(ExecutionContext) on exception path Dereferenced at Fork.java:[line 108]
| M C BC_IMPOSSIBLE_INSTANCEOF BC: instanceof will always return false in org.jbpm.graph.node.Join.execute(ExecutionContext), since a java.util.Map can't be a java.lang.Boolean At Join.java:[line 121]
| H C RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE RCN: Nullcheck of method at line 42 of value previously dereferenced in org.jbpm.instantiation.BeanInstantiator.setPropertyValue(Class, Object, String, Element) At BeanInstantiator.java:[line 39]
| M C IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN IP: The parameter processDefinition to org.jbpm.jpdl.par.JpdlArchiveParser.readFromArchive(ProcessArchive, ProcessDefinition) is dead upon entry but overwritten At JpdlArchiveParser.java:[line 51]
| M C NP_NULL_ON_SOME_PATH_EXCEPTION NP: Possible null pointer dereference of node in org.jbpm.jpdl.xml.JpdlXmlReader.readNodes(Element, NodeCollection) on exception path Dereferenced at JpdlXmlReader.java:[line 227]
| M C NP_NULL_PARAM_DEREF NP: Method call in org.jbpm.jpdl.xml.JpdlXmlReader.createAction(Element) passes null for unconditionally dereferenced parameter of readAction(Element, Action) Method invoked at JpdlXmlReader.java:[line 591]
- http://findbugs.sf.net
- btw an eclipse plugin exists
- Presentation @google http://video.google.com/videoplay?docid=-8150751070230264609
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067716#4067716
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067716
16 years, 9 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote :
| The business interface managed object would also have a seperate
| managed object to represent the "*" method (the wildcard).
| ...
| 1) The metadata knows whether "*" applies to its specific method.
| But there should be some way to say it is actually using the "*" managed object
| and linked to where it is really defined.
|
| 2) The "*" metadata should be able to know where it applies and show
| what methods will change if it changes. Again these are links.
|
I don't view the "*" notation as anything other than a convience for the selection of all methods on the ejb. I don't see that we need to be able to output the same shorthand descriptor. If a descriptor with wildcard mappings is parsed, the resulting metadata is just the collection of methods with the transaction and security attributes the wildcard is associated with mapped onto the methods. If this is serialized back to a descriptor, I don't see a need to be able to collapse the transaction or security assembly sections into a minimal wildcard form.
"adrian(a)jboss.org" wrote :
| 3) It should be possible to create alternate views of this information
| (again ManagedObjects within the top level managed object that is really
| just linking). e.g. a view that looks like the transaction-assembly and a view
| that has it all unwrapped, i.e. one method - one attribute
|
| Of course, this has all got to be described in a generic way such
| that an admin console can understand it and present it to the user.
|
| e.g. The view managed objects in (3) would have to be marked in some way
| and probably assigned a "view group" so the admin console and
| user knows what the alternate views are.
|
| e.g.2 The links described above would need to be marked so it is obvious to the
| console/user that the information shown (for convience) is actually coming
| from somewhere else and they can navigate to where it is really defined.
|
| As you can see, my view of a ManagedObject is not a simple one.
| It represents a piece of metadata (not necessarily the whole metadata)
| that knows where it fits in the whole model.
| It also may not be the only ManagedObject presenting that piece of metadata.
I agree with the notion of views, but this seems more of an admin tool task rather than something the managed objects need to describe themselves. There does need to be an ability to link a ManagedProperty from one ManagedObject/ManagedComponent to another. I added a ManagementComponentRef annotation to allow the deployer writer to describe such relationships.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067682#4067682
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067682
16 years, 9 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote :
| The top level managed object would know how to "reconstruct" the -ds.xml
| from the individual pieces, or preferably the lower managed objects
| would know where they fit in the whole.
|
| The ejb deployer would be similar with a collection of EJB managed objects
| and seperate one for the "deployment level" stuff.
|
| The idea being it is pretty easy for the deployer writers to create ManagedObjects
| (around their deployment descriptors - or more correctly parts of them)
| if we add the framework that knows how to present the descriptors (and update them)
| from annotations or xml) - we're really just wrapping their annotated metadata
| which they've told us how to map.
|
Its not that the ManagedObject is gone, its just not manifest to the user from the aggregate ManagedDeployment and associated ManagedComponents. It still exists in terms of the metadata instance attachment. A ManagedComponent is a collection of ManagedPropertys that may have more than one ManagedObject depending on how many attachments make up the ManagedComponent.
"adrian(a)jboss.org" wrote :
| This looks very similar to your ManagedComponent but it doesn't have
| the notion of getting the attachment back again for the top level managed object
| (the whole deployment descriptor) so it can set it in the "predetermined managed objects" for (re)deployment.
|
The attachment(s) for a given ManagedComponent is associated with the ManagedObject(s) that make up the ManagedComponent ManagedPropertys. I am looking at an ejb/datasource as the external component view an admin tool wants to work with being built up from multiple metadata attachments from the various deployers/descriptors that contribute ManagedPropertys to the component management view.
"adrian(a)jboss.org" wrote :
| Where the disconnect occurs (to me) is there is no idea of top level managed object
| (or top level managed component if you like) at all.
|
| The only aggregate is the ManagedDeployment. But the deployer writers don't
| (and shouldn't) care about this. e.g. The ejb deployer doesn't care if there is
| also a META-INF/log4j.xml in an ejb jar, its irrelevant and orthogonal.
|
I do view the ManagedDeployment as the top level managed object. It will contain objects extraneous to an ejb deployer just as the DeploymentUnit contains attachments the ejb deployer does not care about. Maybe there does need to be a top level component that does better correspond to the jsr88 DeploymentConfiguration for example. I was not viewing the deployment descriptors as anything more than a serialized view of the attachment metadata, but maybe there needs to be a stronger coupling due to jsr88 keeping the xml oriented model.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067676#4067676
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067676
16 years, 9 months
[Design of JBoss Build System] - Extraneous pom.xml dependencies in jboss-common and others
by genman
I've been building my project against the snapshot release of JBoss Microcontainer using Maven and there's 28 libraries that get pulled in, and some of them seem fairly non-relevant to runtime.
Most of the issues are due to transitive dependencies. Here are a list of dependencies I end up with:
| ? ant\ant\1.6.5\ant-1.6.5.jar
| ? apache-httpclient\commons-httpclient\2.0.2\commons-httpclient-2.0.2.jar
| ? apache-slide\webdavlib\2.0\webdavlib-2.0.jar
| apache-xerces\xercesImpl\2.7.1\xercesImpl-2.7.1.jar
| apache-xerces\xml-apis\2.7.1\xml-apis-2.7.1.jar
| jboss\jboss-common-core\2.0.4.GA\jboss-common-core-2.0.4.GA.jar
| jboss\jboss-common-logging-log4j\2.0.4.GA\jboss-common-logging-log4j-2.0.4.GA.jar
| jboss\jboss-common-logging-spi\2.0.4.GA\jboss-common-logging-spi-2.0.4.GA.jar
| jboss\jboss-logging-spi\2.0.3.GA\jboss-logging-spi-2.0.3.GA.jar
| ? jboss\jboss-test\1.0.4-SNAPSHOT\jboss-test-1.0.4-SNAPSHOT.jar
| jboss\jboss-vfs\2.0.4.snapshot\jboss-vfs-2.0.4.snapshot.jar
| jboss\jbossxb\2.0.0.CR3\jbossxb-2.0.0.CR3.jar
| ? jboss\profiler\jvmti\jboss-profiler-jvmti\1.0.0.CR5\jboss-profiler-jvmti-1.0.0.CR5.jar
| ? org\apache\ant\ant-junit\1.7.0\ant-junit-1.7.0.jar
| ? org\apache\ant\ant-launcher\1.7.0\ant-launcher-1.7.0.jar
| ? org\apache\ant\ant\1.7.0\ant-1.7.0.jar
| org\jboss\javassist\3.6-beta\javassist-3.6-beta.jar
| org\jboss\jboss-aop\2.0.0-SNAPSHOT\jboss-aop-2.0.0-SNAPSHOT.jar
| org\jboss\microcontainer\jboss-aop-mc-int\2.0.0-SNAPSHOT\jboss-aop-mc-int-2.0.0-SNAPSHOT.jar
| org\jboss\microcontainer\jboss-container\2.0.0-SNAPSHOT\jboss-container-2.0.0-SNAPSHOT.jar
| org\jboss\microcontainer\jboss-dependency\2.0.0-SNAPSHOT\jboss-dependency-2.0.0-SNAPSHOT.jar
| org\jboss\microcontainer\jboss-kernel\2.0.0-SNAPSHOT\jboss-kernel-2.0.0-SNAPSHOT.jar
| oswego-concurrent\concurrent\1.3.4\concurrent-1.3.4.jar
| ? qdox\qdox\1.6\qdox-1.6.jar
| sun-jaf\activation\1.0.2\activation-1.0.2.jar
| trove\trove\2.1.1\trove-2.1.1.jar
| wutka-dtdparser\dtdparser121\1.2.1\dtdparser121-1.2.1.jar
|
Projects with (potential) extraneous dependencies:
jboss-commons-core: Pulls in apache-httpclient and apache-slide:webdavlib. Seems like the "web" portion of commons belongs someplace else.
jboss-aop: Pulls in Ant, plus qdox. These are compile tools, but not needed for runtime, I think.
org.jboss.microcontainer: compile depends on junit, probably should be "test"
I'm not sure why I end up with jboss-test, seems like the Maven2 plugin from Eclipse might be confused.
I'm going to see if I can't fix the microcontainer dependencies, I hope nobody gets mad.
A useful tool I've found is: http://www.jfrog.org/sites/dep-analyzer/1.0/ , but only seems to work when built from source. The GUI maps out where the dependencies you get come from, so you can follow the chain.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067672#4067672
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067672
16 years, 9 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments
by adrian＠jboss.org
Let me give you a more complicated example. So you can see more clearly
what I'm talking about and where I was heading (although not all of it was planned
for JBoss-5.0.0 :-)
The example is transaction attributes on ejbs.
There's aren't configured in a very nice way (unless you use annotations).
You don't configure them directly on the ejb, you configure them in a seperate
section of ejb-jar.xml (that's because some of them can be wildcards).
I would expect the EJB managed object to have
a managed object that represents its business interface. It would really be a
collection of methods and part of it would be the transaction attribute.
The business interface managed object would also have a seperate
managed object to represent the "*" method (the wildcard).
These would know how to put the config changes back into the transaction assembly
part of the xml (assuming you wanted to get ejb-jar.xml back again).
Eventually I would expect us to add features to make this management
easier and more transparent:
(These are a lot more complicated ManagedObjects and I wasn't planning
on implementing these features in the initial release.)
1) The metadata knows whether "*" applies to its specific method.
But there should be some way to say it is actually using the "*" managed object
and linked to where it is really defined.
2) The "*" metadata should be able to know where it applies and show
what methods will change if it changes. Again these are links.
3) It should be possible to create alternate views of this information
(again ManagedObjects within the top level managed object that is really
just linking). e.g. a view that looks like the transaction-assembly and a view
that has it all unwrapped, i.e. one method - one attribute
Of course, this has all got to be described in a generic way such
that an admin console can understand it and present it to the user.
e.g. The view managed objects in (3) would have to be marked in some way
and probably assigned a "view group" so the admin console and
user knows what the alternate views are.
e.g.2 The links described above would need to be marked so it is obvious to the
console/user that the information shown (for convience) is actually coming
from somewhere else and they can navigate to where it is really defined.
As you can see, my view of a ManagedObject is not a simple one.
It represents a piece of metadata (not necessarily the whole metadata)
that knows where it fits in the whole model.
It also may not be the only ManagedObject presenting that piece of metadata.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067598#4067598
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067598
16 years, 9 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments
by adrian＠jboss.org
Sounds reasonable, except the dropping of the ManagedObject.
The ManagedObject is meant to behave like an MBean, both for a
deployment descriptor as a whole but more convienantly for the lowest
unit of management (what I think you call components).
I also argued that you should be able to use it for smaller parts of the
deployment descriptor but that's irrelevant to this discussion, I think?
The way I originally thought it would work was that a -ds.xml
would really be little more than a collection of managed objects
and the MCF deployer work be just to create ManagedObjects for individual
datasources and connection factories (I know there's other things that can
go in a -ds.xml, e.g. mbeans - these would be other managed objects in the collection).
The top level managed object would know how to "reconstruct" the -ds.xml
from the individual pieces, or preferably the lower managed objects
would know where they fit in the whole.
The ejb deployer would be similar with a collection of EJB managed objects
and seperate one for the "deployment level" stuff.
The idea being it is pretty easy for the deployer writers to create ManagedObjects
(around their deployment descriptors - or more correctly parts of them)
if we add the framework that knows how to present the descriptors (and update them)
from annotations or xml) - we're really just wrapping their annotated metadata
which they've told us how to map.
This looks very similar to your ManagedComponent but it doesn't have
the notion of getting the attachment back again for the top level managed object
(the whole deployment descriptor) so it can set it in the "predetermined managed objects" for (re)deployment.
Where the disconnect occurs (to me) is there is no idea of top level managed object
(or top level managed component if you like) at all.
The only aggregate is the ManagedDeployment. But the deployer writers don't
(and shouldn't) care about this. e.g. The ejb deployer doesn't care if there is
also a META-INF/log4j.xml in an ejb jar, its irrelevant and orthogonal.
In summary:
I think ManagedComponent is really just a ManagedObject
under a different name and with extra information.
But it no longer serves the original purpose intended, i.e. of dealing with
management at the "atomic level" but also knowing where/how it fits in the
"bigger picture".
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067589#4067589
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067589
16 years, 9 months