"alesj" wrote : "jason.greene(a)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. anonymous wrote : | "jason.greene(a)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. anonymous wrote : | "jason.greene(a)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. anonymous wrote : | "jason.greene(a)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? anonymous wrote : | "jason.greene(a)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. anonymous wrote : | 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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224804#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...