Nukes compatibility to JBoss upgrade path

[kamikatze]

Hi!

I think this question is for Julien:

Currently Nukes compiles against JBoss 3.2.3.
The currently latest released versions of JBoss are 3.2.5 and 3.2.6RC1.

Are there plans to move on with Nukes to make it compile with a later version than 3.2.3, and which version (or versions) are targeted?

Cheers, Mika

[invisiblemage]

Hi,
I read a post which says after the release 1.1 nukes should be made 3.2.3+ compatible.
As I posted in the user forum, I would need a working solution for 4.0.0 now – if somebody could tell me where in the code I had to look (seems like a jmx-problem), I could try to change it.

Boris

[invisiblemage]

so, again:
if someone could tell me what to change in the sources to make it running, or tell me how to figure out where to look, I would give it a try.

[theute]

It might not be as simple as it seems. I guess the best way is to try to deploy it on JBoss 4 and fix one by one the deployment troubles.

Regards,
Thomas

[invisiblemage]

well,...

how can I figure out what that LifeCycleInterceptor should be doing?

It's missing the getNext()... it was in the jboss 3 AbstractInterceptor class I guess.
Where can I check what has been changed and how it's supposed to work now?

[kamikatze]

That's the tricky part about it. A great deal of the code was put together by Julien and as he's thinking some dimensions beyond what the average programmer is used to, it is sometimes hard to get one's brain around it.
What I want to say is, that you can't expect to get answers on your questions, you have to figure out by yourself what's behind it.
The bright side of it is, that you will learn all about nukes and what I can say for me -- a lot of elegant tricks to do things (ok, some I find not that elegant but at the end everything is a compromise between speed of development, practicality and elegance).
As I'm prepared to put some work into this as well, I would like to clear upfront, what the target version will be: 3.2.6 or 4.0.0? The former will be easier but the later will have more future, I think.
What are your thoughts?

[invisiblemage]

I know that people here don't talk to everyone - but I thought it's worth a try, anyway. maybe faster then figuring out myself.

I have jdk 1.5 and jboss 4. No way round, since I have (well, want) to use EJB 2.1 features

[theute]

The thing is just that (i think) nobody really took care of it yet and is able to answer your question. If you succeed, please let us know how you did.

[kamikatze]

Ok, then let's start :-)

(Just don't take me wrong, I didn't want to sound offending, it's just that if someone would have figured out what to do already, he would propably have coded it :-)

[julien1]

I will look at the compatibility issue this week, Nukes 1.x should work with JBoss-3.2.6

[invisiblemage]

Just trying to sound funny ;-)

I will have a look at that Lifecycle and the changes to the AbstractInterceptor tomorrow… Anyway, if somebody knows where the “getNext()” is gone, just tell me :)

[kamikatze]

getNext().invoke() is the body of the AbstractInterceptor's invoke() method in 3.2.x. Have a look into the invoke() Method of the AbstractInterceptor of 4.0, there you see where getNext().invoke() has gone :-)

Mika

[jae77]

i could have sworn i posted something about this not to long ago, but i can't seem to find the thread, and i'm pretty worn out from relocating back to nyc, and i don't really have the energy to keep looking. :)

the Invocation class that used to reside in org.jboss.mx.interceptor package no longer exists as well, which is another issue that needs to be dealt with. the LifeCycleInterceptor changes are going to be where the bulk of the work is.

these are the other changes i made (there may also be the need for build script changes as well b/c the javax.servlet classes no longer live under lib (they are in the tomcat dir under deploy)

org.jboss.nukes.component

NukesBuilder

- convert MBeanAttributeInterceptor to ModelMBeanAttributeInterceptor
- synced ModelMBeanConstants variable names


org.jboss.nukes.handler

NukesImpl

- added stubbed impls for missing methods
- removed throws exception from setCharacterEncoding

org.jboss.nukes.utils

Tools.java

- removed jdom import statements

org.jboss.nukes.system

JDBCPersistenceManager

- synced ModelMBeanConstants variable names

----
and w/ that, i'm off to continue unpacking.

[invisiblemage]

Hi,
yes, I have found that post two days ago... after several hours figuring out myself :-(

what I did after that:
I got MBeanNotCompliant, since the lifecycleinterceptor seems to be missing the default constructor, so I added

public LifeCycleInterceptor() {
super();
this.log = Logger.getLogger(this.getClass());
} // just to have a logger, else will result in a null pointer in the invoke()

In NukesBuilder I changed

Descriptor mbeanDesc = resourceInfo.getDescriptor(null, ModelMBeanConstants.MBEAN_DESCRIPTOR);

to:

Descriptor mbeanDesc = resourceInfo.getMBeanDescriptor();

since in getDescriptor you can not have null as a first parameter:
public Descriptor getDescriptor(String inDescriptorName,
String inDescriptorType)
throws MBeanException, RuntimeOperationsException {
if (inDescriptorName==null) { throw new RuntimeOperationsException(new IllegalArgumentException("Descriptor is invalid"),
("Exception occurred trying to set the descriptors of the MBeanInfo"));
}


But I don't know if I took the correct function

And in LifeCycleManager I added the (missing) getNext() function (from AbstractInterceptor) and replaced all the getNext().invoke(incovation) with a call to that:


// copied from AbstractInterceptor
private Object getNext(Invocation invocation) throws Throwable{
Interceptor ic = invocation.nextInterceptor();

// if the invocation object does not provide us with more interceptors,
// invoke the dispatcher that lands the invocation to its final target
// in the resource object
if (ic == null)
return invocation.dispatch();

// see if the next interceptor in the chain is shared
if (ic.isShared())
{
// we require a common interface for all shared interceptors
SharedInterceptor shared = (SharedInterceptor)ic;

// we invoke shared interceptor it via the MBean server bus, get the
// interceptors view to its MBean server
MBeanServer server = shared.getMBeanServer();

// And the object name the interceptor is registered under
ObjectName name = shared.getObjectName();

return server.invoke(
name, "invoke",
new Object[] { invocation }, // args
new String[] { Invocation.class.getName() } // signature
);
}

// invoke non-shared interceptor directly via Java reference
else
{
return ic.invoke(invocation);
}
}


... ending up with the following exceptions:

Caused by: java.lang.Exception: org.jboss.util.UnreachableStatementException: in
voke
at org.jboss.nukes.mx.LifeCycleInterceptor.create(LifeCycleInterceptor.j
ava:112)
at org.jboss.nukes.mx.LifeCycleInterceptor.invoke(LifeCycleInterceptor.j
ava:61)
... 80 more
Caused by: org.jboss.util.UnreachableStatementException: invoke
at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelM
BeanAttributeInterceptor.java:199)
at org.jboss.nukes.mx.LifeCycleInterceptor.getNext(LifeCycleInterceptor.
java:150)
at org.jboss.nukes.mx.LifeCycleInterceptor.create(LifeCycleInterceptor.j
ava:110)
... 81 more


So, I don't exactly know what I am doing here, since I am into the JMX stuff since two days (beginning to understand how that ModelMBean works) and have a hard time figuring out what the hell you guys are doing with that interceptor/invoker stuff...

[invisiblemage]

Invocation.OP_INVOKE == "invoke" which is first called on LifeCycleInterceptor for the create...
but then
Interceptor ic = invocation.nextInterceptor();
ic.invoke(interceptor)

is called on the ModelMBeanAttributeInterceptor, where the invocation.getType() == OP_INVOKE, but it should be one of the following:

...
if (invocation.getType().equals(Invocation.OP_SETATTRIBUTE))
else if (invocation.getType().equals(Invocation.OP_GETATTRIBUTE)


so I guess either my nextInterceptor is wrong, or it maybe has to be called somewhere else?
Anyway, I was wondering why the lifecycleinterceptor checks for more interceptors... shouldn't this be handled by another class that goes through the interceptor chain?