JBossDeveloper

"adrian@jboss.org" wrote:

Another concern I have is: there may be bean/service that's designed without the ability to "re-configure".

We are talking about loosely coupled middleware, not tightly bound implementation detail.

"adrian@jboss.org" wrote:


Dependency semantics from other frameworks require an adapter
to have notification of availability and unavailability. This then fires state change
events for newly satisfied and unsatisfied dependencies.

You'll never convince me that a piece of xml is going to solve the problem,
and certainly not anything that assumes a procedure/script.

It is an event not a process. :-)

"adrian@jboss.org" wrote:
I never understood why software developers are so adverse to state machines?

I've been thinking about the "valve" concept these two days.

One question I found we may not be on the same page is:

How does Jboss mc expect itself to be used by the client?

Is it designed to be some kind of super-duper name server/registry/service locator kind of thing so that clients still call "registry.getBean(bean_name)" to "pull" each bean?

Or is it a dependency injection framework where client code is not aware of the framework at all and dependencies are simply pushed to these components?

The "valve" concept is a bit hard to understand in the case of "push", because once a dependency is injected into components, there doesn't look like any chance for the framework to "reconfigure" this dependency. The semantics of such "reconfiguration" is generally undefined. Client code may not even know to read the re-configured value or the dependency is simply not reconfigurable at aLL.

It is however easy to understand in the case of "pull" approach, because we can add "valve" logic to the "getBean(bean_name)" function so that when the bean is being reconfigured, we just throw exception or wait.

Hopefully I'm not adding more confusion. :-)

It took me several days to re-think and digest what you guys said. :-)

Now it appears somewhat more clear to me what the state machine is for. Thanks for spending all this time.

Bill, doesn't Java EE 5 ear file contain an "application deployment descriptor"? And if it is not present, "naming convention" is used to figure out the dependencies? (Just found it in the java EE 5 spec)

If so, once the deployer knows which is "ejb", which is "web", it sounds trivial to figure out the deployment order.

I do not know the embedded ejb case, but it still sounds to me like a module level dependency analysis. And dependency analysis on granularity of component/service level doesn't seem like a perfect fit.

What I mean is, module level dependency analysis should be simpler to implement. And it is also better to de-couple module dependency management from the container that manages individual components/services.

Overall, you gave two nice practical examples that need dependency anylysis and management, but they don't seem to justify component level dependency.

With that said, I guess I kinda get some idea of why "dependency" on component level is needed. Correct me if I'm wrong. As what Adian said, if we ever need to reconfigure/re-deploy an individual component, we need to know the components that depend on it in order to ripple reconfigurations/redeployments up the dependency chain.


Does that sound like I'm getting it?

Adrian, let me summarize my understanding so far so you can easily see whereI am and what I'm mistaken about.

"adrian@jboss.org" wrote:

"ajoo" wrote:

1. It is a required feature for JBoss MC to allow reconfigure/redeploy individual services.

Not required, but possible. It depends upon what the user wants to do.
Think of it as an optional plugin.

"adrian@jboss.org" wrote:

5. When a service is "re-deployed", services whose property values are set to this redeployed guy, and services whose constructor/factory parameters were set to this redeployed guy, will be affected.

Not just the injected values, but the type system as well in some cases.
i.e. you have to reload the classes that are referencing the changed class.

"adrian@jboss.org" wrote:

6. If service A is redeployed and service B's properties reference A, service B needs to be re-configured.

This depends what you mean by redeployed. In some cases it is loosely coupled
so service is just suspended. In others the name changes or type system is affected,
etc.

"adrian@jboss.org" wrote:

7. If service A is redeployed and service B's parameters reference A, service B needs to be re-deployed as well. (because there's no way to re-configure service B)

Yes this is the difference between loosely coupled (by value) and tightly coupled (by reference).

"adrian@jboss.org" wrote:

8. When a service needs to be re-configured, property setters are called and the work is done.

Again it depends upon metadata attached to the property. In most cases a property
change doesn't require a restart. But sometimes it does. Another example
would be re-injecting a different reference to a DataSource.
You can't just swap the reference because there are ongoing transactions using
the old DataSource/connections.

"adrian@jboss.org" wrote:

You seem to be getting it. The redeploy/reconfigure is really a false dichotomy.
How much you have to unwind the state transitions depends upon the use case.

The really good implementations don't require any unwind/suspension
or nearly nothing (see the thread in the deployers forum about "transactional deployment") because they use additional tricks.

The technique to detect class bytecode dependency is an interesting topic to me cuz I can't think of a good way of implementing it out of my head right now.

But I think a more important question to keep asking again and again is:

Even for a non DataSource thing, when we re-deploy a service, how do we know the object is not already obtained and kept as reference by a client? We have no way to tell the client to "re-obtain me" in such case.

Let's say a client is designed as:

class BankAccount{
 private A a;
 void f(){
 this. a = jboss_container.get("service A");
 }
}