EMAIL PROTECTED]]On Behalf Of
|Adrian Brock
|Sent: Saturday, March 02, 2002 8:49 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment
|EARDeployer
|
|
|Ok,
|
|I've done a quick scan of the proposed final draft.
|
|The J2EEManagedObject is a stan
I asked Andreas the part about the and he did not have a
chance to respond before he had to leave for the weekend. the current version of the
JSR77 interfaces and most of the implementation in jboss is based on the public draft
from last year.
yes, vendor specific types ar
Ok,
I've done a quick scan of the proposed final draft.
The J2EEManagedObject is a standardized
management interface. It can be used to expose everything
from the server right down to an individual servlet.
Section 3.1.1.3 is the important section for the
problem we have.
The spec says we are
I am working with Andreas to implement the JSR77 stuff
and there are plans to convert the current JSR77 MBeans into XMBeans when they are
ready. we are planning to look
at the XMBeans sometime next week.
As for the problems you guys are running into, the JSR77 spec was not designed to
handle
Thanks David,
I'll download the JSR77 spec, to see what it all about.
The other problem is, that JSR77 has the same
ObjectName problems as we found with EjbModule.
Try deploying
My=App.ear and you get a MalformedObjectName exception :-)
Regards,
Adrian
> On 2002.03.02 22:00:15 -0500 Adrian Br
On 2002.03.02 22:00:15 -0500 Adrian Brock wrote:
> You are correct, I didn't read the bug report very well.
>
> When I fixed the windows locking problem for ears,
> I saw the same exception. I thought it was the same
> problem.
>
> I've been making too many errors this week.
> I think I *need* a
You are correct, I didn't read the bug report very well.
When I fixed the windows locking problem for ears,
I saw the same exception. I thought it was the same
problem.
I've been making too many errors this week.
I think I *need* a day off. :-)
Regards,
Adrian
> Hi Adrian,
>
> I'm not very f
Hi Adrian,
I'm not very familiar with jsr-77 either, and despite repeated explanations
from Andreas I keep having difficulty understanding what problem it is
solving ;-)
I've started wondering if there is some way of eliminating the current
jsr-77 mbeans and providing the entire implementation a
Hi David,
I've only just started looking at the new Deployer and
I'm not familiar with JSR77.
But, like you say, the problem is that JSR77
tries to do everything in one step.
Creating the MBeans in create and linking them in start
is a general solution to the problem.
The current code doesn't