[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-3532 Design
As you said, the issue with DRM/ClusterPartition is that it's a circular dependency, making it a wee bit complex for dependency injection. That should be solvable by adding "whenRequired" attributes to the inject elements.
I.e in pseudo-xml in cluster-beans.xml:
| <bean name="HAPartition" ...>
| <property name="distributedReplicantManager"><inject bean="DRM" whenRequired="Create"/></property>
| <bean name="DRM" ...>
| <property name="HAPartition"><inject bean="HAPartition" whenRequired="Instantiated"/></property>
The above example could be wrong; it's more there to give you the concept. Idea is you inject the DRM into the HAPartition just before it needs it in create(). You inject HAPartition into DRM early, since a DRM without an HAPartition is basically useless. The MC can analyze this situation and properly instantiate both objects.
The schema for beans.xml explains this stuff fairly well; it's in the Microcontainer source at https://svn.jboss.org//repos/jbossas/projects/microcontainer/trunk/kernel... . Valid values for "whenRequired" are the various states the MC moves a bean through as it deploys it:
I didn't have a chance to properly explore this last Nov when I was looking at this. If you have bandwidth to play with it a bit and try to get it sorted, that would be great. (Note I'm leaving on 2 week vacation in a few hours, so will not be in touch.)
Re: JBAS-3499, that's still really low priority. DRM works now, except for a couple JIRAs we need to track down. DRM is mission critical, and with all the stuff there is to do, I have a "if it ain't broke don't fix it" attitude toward making DRM use JBoss Cache.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067961#4067961
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067961
15 years, 8 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments
"adrian(a)jboss.org" wrote : We'll have to agree to differ then. ;-)
| P.S. I was planning on writing my own Swing admin console that was entirely
| driven by the hints in the ManagedObjects. It might not be pretty, but it will
| test whether the information/model can be used to construct "reasonable" UI
| for user written deployers whose metadata model we know nothing about.
I don't know that I so much disagree as don't want to get too hung up on making this a required feature initially. Certainly in principle the default jmx console could use this to generate a much better default view of the admin capabilities. Its just not a required feature in order for an admin tool to be able to effectively manage a server.
I guess the main issue is validating that there are not incompatible evolutions of existing properties, as well as making sure that new properties that need user attention have some support without the tool needing a complete revision. For the ha datasource URLDeliimeter property, its is a new datasource type that does effectively need some synchronization with the admin tool as there can be a lot of hidden complexity in the list of jdbc urls in terms of a tool providing testing to ping the indicated databases. Arguably this also requires a new multi-valued jdbc url property rather than a separator that is used in combination with the old jdbc url. How we deal with this type of evolution best is the question.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067960#4067960
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067960
15 years, 8 months
[Design of JBossCache] - Re: Too much jboss cache INFO logging
The definition of INFO vs DEBUG there is slightly vague, until you interpret the concept of "service state" in the INFO description in terms of the AS ServiceMBean.getState() definitions; i.e. lifecycle state -- created/started/stopped/destroyed.
With that interpretation all these should be at DEBUG.
We could cheat and log the version as part of a "Cache started" INFO message. :-)
BTW, with the practice of only supporting Platforms, the need to log versions is reduced, since the JBC version is defined by the Platform version. When we support JBC as a Framework, the support tools will be fixed so the customer can properly specify the version in the form they fill out to submit a case. Presumably they know the version if they went to the effort of specifically buying support for it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067955#4067955
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067955
15 years, 8 months