[Design of POJO Server] - Re: MBeanRegistration (ProfileService test configuration sh
by jeff.zhang
This issue is still existing.
How to reproduce:
1. start default profile with set log level > DEBUG
2. copy a file from testsuite/output/lib/bean1ejb-not.ajar, rename it bean1ejb-not.jar, copy into deploy directory
3. ejb deployed and delete that jar to make undeployed
4. shutdown server instance and we can get the issue log nearby end of the server.log
anonymous wrote :
| 2009-04-10 09:06:57,478 DEBUG [org.jboss.system.ServiceCreator] (JBoss Shutdown Hook) Error unregistering mbean
| jboss.j2ee:service=EJB,plugin=pool,jndiName=Bean1EJB
| javax.management.InstanceNotFoundException: jboss.j2ee:service=EJB,plugin=pool,jndiName=Bean1EJB is not registered.
| at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
| at org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
| at org.jboss.system.ServiceCreator.uninstall(ServiceCreator.java:323)
| ...
|
The issue:
EjbModule.destroyService()
| serviceController.destroy(jmxName);
| serviceController.remove(jmxName);
|
here jmxName is jboss.j2ee:jndiName=Bean1EJB,service=EJB
in SessionContainer.destroyService
| destroyInstancePool();
|
it also destroy jboss.j2ee:service=EJB,plugin=pool,jndiName=Bean1EJB
but it does NOT remove jboss.j2ee:service=EJB,plugin=pool,jndiName=Bean1EJB in remove method.
When server shutdown, it try to find jboss.j2ee:service=EJB,plugin=pool,jndiName=Bean1EJB, the exception throws.
Any suggestion about how to fix it?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224833#4224833
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224833
16 years, 12 months
[Design the new POJO MicroContainer] - Re: New tree state model
by jason.greene＠jboss.com
"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#4224804
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224804
17 years
[Design the new POJO MicroContainer] - Re: New tree state model
by alesj
"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.
I'm not saying it needs to be done now.
And nothing of what I wrote implied it will be.
"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.
"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.
"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.
"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.
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(a)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, ...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224788#4224788
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224788
17 years
[Design the new POJO MicroContainer] - Re: New tree state model
by jason.greene＠jboss.com
"alesj" wrote : "jason.greene(a)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.
anonymous wrote :
| "jason.greene(a)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?
anonymous 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.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224775#4224775
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224775
17 years
[TODO - DEVELOPMENT] - Jboss Administrator
by okpremjit＠yahoo.co.in
Job Title: Jboss Administrator
Duration: Permanent
Location: Chevy Chase MD
Client: Confidential
Project Description:
Role:The successful Middleware Administrator candidate will be responsible for the installation, configuration, performance and tuning as well as ongoing operations and maintenance of JBoss application servers. Additionally, the Middleware Administrator will troubleshoot application issues and advise developers on how to develop applications in a best practice approach utilizing the specific application servers.
Additional Duties:
Install and configure JBoss Application Server and other J2EE software products and fixes on Linux/Windows/UNIX platforms.
Support the application development cycle involved with Application design, deploying code, and resolving any infrastructure problems.
Tune J2EE Application servers to optimize performance.
Support production implementations and resolve any production problems, support application releases, monitor production environment, participate in production problem calls, resolve any problems related to Middleware.
Write or modify scripts (Korn shell, JYTHON).
When we have lease replacements we have to reinstall all middleware products.
We use a change management system to report all changes in a timely manner and obtain the proper approvals
Project plans using MS Project will be written for most projects that we are overseeing
Handle requests tickets from our users that need some type of Middleware support
Requirements:
Must have 3+ years experience with Unix (SuSe, Solaris preferred)
Must have 3+ years of JBoss experience
Must have 3+ years of GC
Must have scripting experience
Must have experience with J2EE Application Server tuning experience.
Must be local to the MD area.
Please call me in 650-646-3220
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224774#4224774
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224774
17 years
[Design the new POJO MicroContainer] - Re: New tree state model
by alesj
"jason.greene(a)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(a)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(a)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. ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224772#4224772
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224772
17 years