MC tools

[alesj]

Just yesterday I was thinking of needing nice MC tool(s)
to help me with some migration, optimization.

So, the idea is next (all cmd line tools):
(1) help migrate -service.xml --> -beans.xml
* single file, ant patterns
* warn on non portable elements (perhaps being able to type in the fix/change)

(2) display services dependencies (pojos, mbeans, aliases, deployments, ...) via apiwiz
* at descriptor file level (-beans.xml, -service.xml, jboss-dependency.xml, jboss-classloading.xml)
* at (Bean|Service)MetaData level (hook into Deployers attachments)
* at kernel level (inspect ControllerContexts for DependencyItems)

This would require a new mc-tools projects,
with 2 modules: migration, dependencies

Both tools should come pretty much in-handy with JBoss6.
(1) moving all those mbeans to mc pojos
(2) helping determining how to handle On_Demand mode

[flavia.rainone]

"alesj" wrote:
Just yesterday I was thinking of needing nice MC tool(s)
to help me with some migration, optimization.

So, the idea is next (all cmd line tools):
(1) help migrate -service.xml --> -beans.xml
* single file, ant patterns
* warn on non portable elements (perhaps being able to type in the fix/change

I'm doing some investigation to implement this tool.

"alesj" wrote:

Both tools should come pretty much in-handy with JBoss6.
(1) moving all those mbeans to mc pojos

Should the migration tool generate a beans.xml file that declares every MBean just as a POJO, without injecting the @JMX annotation?
If yes, how exactly are we dealing with those MBeans? For example, suppose that I use the migration tool to migrate my MBean X to a MC bean. But suppose that another MBean Y, deployed at the MBeanServer, has an attribute that is initialized with the name of old MBean X, and it uses this property internally to look up for X in the MBeanServer. Now that I'm not deploying X as an MBean anymore, Y is hence broken. How do we deal with that?

[alesj]

Should the migration tool generate a beans.xml file that declares every MBean just as a POJO, without injecting the @JMX annotation?
If yes, how exactly are we dealing with those MBeans? For example, suppose that I use the migration tool to migrate my MBean X to a MC bean. But suppose that another MBean Y, deployed at the MBeanServer, has an attribute that is initialized with the name of old MBean X, and it uses this property internally to look up for X in the MBeanServer. Now that I'm not deploying X as an MBean anymore, Y is hence broken. How do we deal with that?

I would do it like this.

Ask if all beans should get @JMX:
(a) yes, all
(b) none
(c) prompt for every mbean

If (b) is used then the new bean name is previous mbean name.
For (a) and (c) I would make a plugable mechanism.
e.g. -Dname_transformer=org.jboss.mc.tools.naming.UseServiceProperty
Where this naming class would know how to create a new bean name from the old mbean name.
Or it could force a prompt, while already suggesting some name.

[flavia.rainone]

Ales,

Regarding the convertion tool, what do I do with embedded XMBeans and with XMBeans with references to external descriptors?

I'm guessing this is going to be unsupported feature, but let me know what you think.

[alesj]

Regarding the convertion tool, what do I do with embedded XMBeans and with XMBeans with references to external descriptors?

It's been a while since I used this, so how does this exactly look like?
Although we have beans nested within beans, is this it?

[flavia.rainone]

"alesj" wrote:

Regarding the convertion tool, what do I do with embedded XMBeans and with XMBeans with references to external descriptors?

It's been a while since I used this, so how does this exactly look like?
Although we have beans nested within beans, is this it?

This is when you define one of the attributes xmbean-dd (external descriptor) or xmbean-code (embedded), in order to define the interface of the MBean.

[alesj]

This is when you define one of the attributes xmbean-dd (external descriptor) or xmbean-code (embedded), in order to define the interface of the MBean.

This is then similar to @ManagedX annotations?

OK, leave it out atm.
If there is some demand, we might persuade the one with the demand to do it. :-)

[alesj]

Looking at the JBossBeanXMLMarshaller::marshal.

 else if(value instanceof BeanMetaData)
 {
 BeanMetaData anonymousBean = (BeanMetaData) value;

I guess a recursions could be used here?

[alesj]

I would also handle different metadata classes/values differently, more OO.
As it would be much easier to extend (and support) in the future.

Every excessive "if" usage usually indicates lack of OO. ;-)

[flavia.rainone]

"alesj" wrote:
Looking at the JBossBeanXMLMarshaller::marshal.

 else if(value instanceof BeanMetaData)
 {
 BeanMetaData anonymousBean = (BeanMetaData) value;

I guess a recursions could be used here?

It shouldn't, unless you want to make the code less clear.
The method that receives the BeanMetaData does not deal with anonymous beans, as is the case of the internal bean. Plus, the internal bean is much simpler, it can only have properties.

I think that the point here is that I wrote the code converting ServiceMetaData to BeanMetaData counting on using JBoss XB marshalling. This marshalling would validate my bean meta data (I'm absolutly sure that this meta data I'm generating is not correct, if I passed it along to MC it wouldn't interpret all the meta data the same way I'm doing it).

Now, that discovered that I can't use JBoss XB marshalling:
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234012

I think that converting meta data is pointless, IMO. I'm considering to get rid of that convertion and to generate the XML directly, based on ServiceMetaData.

What do you think?

[flavia.rainone]

For the record, this thread is related to the Jira issue:
https://jira.jboss.org/jira/browse/JBMICROCONT-444

[flavia.rainone]

"alesj" wrote:
I would also handle different metadata classes/values differently, more OO.
As it would be much easier to extend (and support) in the future.

Every excessive "if" usage usually indicates lack of OO. ;-)

This is the case when you can edit the types you're dealing with and add a method to them to do what you want to do. So, instead of doing:

CommonSuperClass obj =...;
if (obj instance of A) { System.out.println("A blablabla"); }
else if (obj instance of B) { System.out.println("B bla bla bla");}

You change A and B classes to:

class A extends CommonSuperClass
{
...
public String getMessage() { return "A blablabla";}
}

class B extends CommonSuperClass
{
...
public String getMessage() { return "B bla bla bla";}
}

And now you can do:

CommonSuperClass obj = ...;
System.out.println(obj.getMessage());

But, of course, I can't change the meta data classes, adding a method that generates the XML form of each one of them. So, how can I get rid of my if instanceof statements and still generate proper XML for every meta data type?

I guess I missed what you're trying to tell me. So, please, elaborate :)

[alesj]

I think that converting meta data is pointless, IMO. I'm considering to get rid of that convertion and to generate the XML directly, based on ServiceMetaData.

What do you think?

No, I would still do it over conversion.

* it's more type safe.
* it shows how SMD and BMD, or mbeans and pojos, relate to each other
* once XB has proper marshaling, it will be trivial to spit out xml

[alesj]

But, of course, I can't change the meta data classes, adding a method that generates the XML form of each one of them. So, how can I get rid of my if instanceof statements and still generate proper XML for every meta data type?

I guess I missed what you're trying to tell me. So, please, elaborate :)

I don't know the name of the pattern, but it's trivial to do it. ;-)
Instead of changing the classes, you can write proper adapters / delegates.

e.g. (pseudo code)

// T --> SMD side metadata type; e.g. ServiceInjectionValueMetaData
// U --> BMD side metadata type; e.g. AbstractInjectionValueMetaData
interface SMD2BMD<T, U>
{
 Class<T> mappingClass();

 U toBMD(T t);

 String toXML(U u);
}

Where now instead of multiple ifs, you would simply do something like this:

Map<?, ?> adapters = ...;
SMD2BMD s2b = adapters.get(smd.getClass());
if (s2b == null)
{
 // no exact mapping class match, lets iterate
 for (Class key : adapters.keySet())
 {
 if (key.isInstance(smd))
 {
 s2b = adapters.get(key);
 break;
 }
 }
 if (s2b == null)
 throw new IllegalArgumentException("No such mapping " + smd);
}

[flavia.rainone]

"alesj" wrote:
I don't know the name of the pattern, but it's trivial to do it. ;-)
Instead of changing the classes, you can write proper adapters / delegates.

I have started implementing this and it really looks much better. :-)
The first version of these classes, implementing only the metadata to metadata conversion, is committed to svn.