This content has been marked as final.
Show 8 replies
-
1. Re: New tree state model
dmlloyd Apr 9, 2009 10:49 AM (in response to alesj)Just out of curiousity - what is wrong with the original linear state model? Seems like exploring concurrent startup etc. would be more important to most users.
-
2. Re: New tree state model
alesj Apr 9, 2009 11:09 AM (in response to alesj)"david.lloyd@jboss.com" wrote:
Just out of curiousity - what is wrong with the original linear state model?
It's not able to support EJB state model,
which has some decision/condition after passivate state,
hence it's not plain linear. -
3. Re: New tree state model
jason.greene Apr 9, 2009 12:43 PM (in response to alesj)"alesj" wrote:
"david.lloyd@jboss.com" wrote:
Just out of curiousity - what is wrong with the original linear state model?
It's not able to support EJB state model,
which has some decision/condition after passivate state,
hence it's not plain linear.
This just sounds wrong. We should not be increasing the already high level of complexity in the MC by trying to make it into an EJB container. Why does the MC have to manage anything associated with passivation? -
4. Re: New tree state model
dmlloyd Apr 9, 2009 1:06 PM (in response to alesj)Yeah, I tend to agree - anyway this doesn't seem to be the time to be redesigning core chunks of the MC. Just my opinion
-
5. Re: New tree state model
alesj Apr 9, 2009 1:47 PM (in response to alesj)"jason.greene@jboss.com" wrote:
We should not be increasing the already high level of complexity in the MC by trying to make it into an EJB container.
Where did you pick up this?
This is just a discussion/brainstorming about
how to change current (limited) linear state model."jason.greene@jboss.com" wrote:
Why does the MC have to manage anything associated with passivation?
This was just an example.
And since EJB actually builds upon MC, it's a real example.
Currently they have to do some tweaks/hacks to get around this problem.
With a tree based state model this would be trivial to do it properly."david.lloyd@jboss.com" wrote:
anyway this doesn't seem to be the time to be redesigning core chunks of the MC
Who said this is gonna be done now? ;-)
This is a future roadmap feature, which Kabir got interested about.
Your two post are just steering this discussion off the target.
I would much rather see you added something useful on how
we should actually impl this new tree model,
then jumping on the thread when I simply mention EJB.
This is just not the way how MC dev forum should work. ;-) -
6. Re: New tree state model
jason.greene Apr 9, 2009 2:10 PM (in response to alesj)"alesj" wrote:
"jason.greene@jboss.com" wrote:
We should not be increasing the already high level of complexity in the MC by trying to make it into an EJB container.
Where did you pick up this?
This is just a discussion/brainstorming about
how to change current (limited) linear state model.
Increasing the complexity of the MC state model to support something that only EJB3 needs, that might not even be the right way to solve their problem needs to be justified."jason.greene@jboss.com" wrote:
Why does the MC have to manage anything associated with passivation?
This was just an example.
And since EJB actually builds upon MC, it's a real example.
Currently they have to do some tweaks/hacks to get around this problem.
With a tree based state model this would be trivial to do it properly.
Great, but before this is done, we need to first ask should it be done? Does the overall AS architecture make sense this way? How does this make the MC better for users? How does this make the AS better for users?
Your two post are just steering this discussion off the target.
I would much rather see you added something useful on how
we should actually impl this new tree model,
then jumping on the thread when I simply mention EJB.
This is just not the way how MC dev forum should work. ;-)
This is exactly the way this forum should work. -
7. Re: New tree state model
alesj Apr 9, 2009 3:32 PM (in response to alesj)"jason.greene@jboss.com" wrote:
Increasing the complexity of the MC state model to support something that only EJB3 needs, that might not even be the right way to solve their problem needs to be justified.
Justified by who or what?
And how do you know that might not be the right way to do it?
They are moving more and more to MC.
Why should they invent a new way to handle their lifecycle
when MC could/should do this.
I'm not saying it needs to be done now.
And nothing of what I wrote implied it will be."jason.greene@jboss.com" wrote:
Great, but before this is done, we need to first ask should it be done?
Afaik MC has it's own roadmap, steered by the one's who are actively involved / contribute."jason.greene@jboss.com" wrote:
Does the overall AS architecture make sense this way?
AS has nothing to do here.
This is transparent to 99,9% of MC use cases.
Apart from EJB3 there is no project/component that I know
that is outside of MC umbrella and uses MC/Kernel spi directly."jason.greene@jboss.com" wrote:
How does this make the MC better for users?
More generic state model.
This was one of the ideas from the first day I joined the project back in 2006.
It was based on my real use case from my previous work."jason.greene@jboss.com" wrote:
How does this make the AS better for users?
Again, no relation, it should be completely transparent.
And it depends which users you're refering to here.
Plain app developer doesn't see the diff from 4.2.x and 5.x wrt to kernel.
If you mean components inside AS, then EJB3 is a clear example.
We would only have a single lifecycle state model,
hence the possible contributors wouldn't have learn any other hacks."jason.greene@jboss.com" wrote:
"alesj" wrote:
Your two post are just steering this discussion off the target.
I would much rather see you added something useful on how
we should actually impl this new tree model,
then jumping on the thread when I simply mention EJB.
This is just not the way how MC dev forum should work. ;-)
This is exactly the way this forum should work.
By hijacking brainstorming thread. Nice ...
It was never done this way and I hope it will stay that way.
If you mean to bring AS to every MC dev thread,
then I don't see why we have Pojo server forum.
I'm not saying it should be completely separate,
but it should be limited to only issues that are not transparent to AS.
e.g. deployers api, OSGi-fication, ... -
8. Re: New tree state model
jason.greene Apr 9, 2009 5:17 PM (in response to alesj)"alesj" wrote:
"jason.greene@jboss.com" wrote:
Increasing the complexity of the MC state model to support something that only EJB3 needs, that might not even be the right way to solve their problem needs to be justified.
Justified by who or what?
And how do you know that might not be the right way to do it?
They are moving more and more to MC.
Why should they invent a new way to handle their lifecycle
when MC could/should do this.
A project's scope and proper usage is a normal topic to discuss when core architectural changes are being considered, especially when it impacts the many things that depend on it. It could very well be this is the right way, which is why i said "may". I am generally suspicious about pushing more and more ejb specific behavior into the MC."jason.greene@jboss.com" wrote:
Great, but before this is done, we need to first ask should it be done?
Afaik MC has it's own roadmap, steered by the one's who are actively involved / contribute.
First off, part of public forums and open source is accepting feedback from anywhere, and being open to public debate. Second of all, the roadmap needs to consider the big picture, since AS is the whole reason (and the funding source) for this project."jason.greene@jboss.com" wrote:
Does the overall AS architecture make sense this way?
AS has nothing to do here.
This is transparent to 99,9% of MC use cases.
Apart from EJB3 there is no project/component that I know
that is outside of MC umbrella and uses MC/Kernel spi directly.
Sure it does. All design decisions with the MC greatly affect the AS, even more so now that EJB functionality keeps moving in its direction. We have ALOT of work to do to make the AS better (performance, on-demand, etc), and the only way we are going to accomplish this, is if every task is tied to a user need."jason.greene@jboss.com" wrote:
How does this make the MC better for users?
More generic state model.
This was one of the ideas from the first day I joined the project back in 2006.
It was based on my real use case from my previous work.
Alright, but shouldn't these use cases be discussed before a solution is designed?"jason.greene@jboss.com" wrote:
How does this make the AS better for users?
Again, no relation, it should be completely transparent.
And it depends which users you're refering to here.
Plain app developer doesn't see the diff from 4.2.x and 5.x wrt to kernel.
Sure they do, they see more memory consumption and unreasonable startup times ;) The negative side-effects should be considered (and compensated with the good) as well.
If you mean components inside AS, then EJB3 is a clear example.
We would only have a single lifecycle state model,
hence the possible contributors wouldn't have learn any other hacks.
"Hack" is rather subjective. The overall question to answer, is where do we draw the line on functionality that should be specific to EJB. Does passivation of MC beans make sense? Should MC be a superset of EJB? The answers to these questions *majorly* affect other componets. As an example, if passivation is moved to the MC, then clustering must switch its implementation to the MC."alesj" wrote:
By hijacking brainstorming thread. Nice ...
It was never done this way and I hope it will stay that way.
If you mean to bring AS to every MC dev thread,
then I don't see why we have Pojo server forum.
I'm not saying it should be completely separate,
but it should be limited to only issues that are not transparent to AS.
e.g. deployers api, OSGi-fication, ...
Perhaps some of the branches of this conversation should be moved to a separate thread. However, discussing the reasons and use-cases for a MC architecture change in the first thread announcing such a change seems reasonable to me.