And while we are on the subject, it would be nice if people
fixed the tests they broke in jboss-head
http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.4/20060309183830/results/index.html
I've got bored of fixing the DOM property editor test every time
the webservices team plays wi
tic
classloading.
Regards,
Adrian "Pedant" Brock
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Adrian Brock
> Sent: Friday, August 05, 2005 11:24 AM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss
Ok, sure, if your going to get technical... ;)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Friday, August 05, 2005 11:24 AM
To: jboss-development@lists.sourceforge.net
Subject: RE: [JBoss-dev] JMX console
One obvious bug is that
editor.setAsText( null );
> editor.removePropertyChangeListener( listener );
> }
>
>
> Results in:
>
> standard boolean editor ...
> ---
> editor = [EMAIL PROTECTED]
> IAE error occured (as expected)
>
> standard Boolean editor ...
> ---
[mailto:[EMAIL PROTECTED] On Behalf Of
> Steve Ebersole
> Sent: Friday, August 05, 2005 10:06 AM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss-dev] JMX console
>
> AFAICT, this would require the following changes:
>
> 1) org.jboss.util.propertyeditor.Boole
: Friday, August 05, 2005 10:06 AM
To: jboss-development@lists.sourceforge.net
Subject: RE: [JBoss-dev] JMX console
AFAICT, this would require the following changes:
1) org.jboss.util.propertyeditor.BooleanEditor so that:
public void setAsText(final String text)
{
Object newValue
-
editor = [EMAIL PROTECTED]
[null]
[null]
[null]
Which all seems reasonable behavior.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Steve Ebersole
Sent: Thursday, August 04, 2005 4:08 PM
To: jboss-development@lists.sourceforge.net
S
logy Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Juha
Lindfors
Sent: Tuesday, January 20, 2004 10:49 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jmx unit tests
the jmx module unit tests are the
tark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Juha
Lindfors
Sent: Tuesday, January 20, 2004 2:28 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] jmx unit tests
JBOSS-HEAD:
/cygdri
wrote:
>
> > What are the other 3 known compliance issues? 3.2 and head should be in
> > synch
> > on class loaders and I need to merge some of the changes made to the jmx
> > layer so I want to get these test working before doing the merge.
> >
> >
> &g
[EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Juha
> Lindfors
> Sent: Tuesday, January 20, 2004 10:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] jmx unit tests
>
>
> the jmx module unit tests are the ones we run against, the ones in
> testsuite
ilto:[EMAIL PROTECTED] On Behalf Of Juha
> Lindfors
> Sent: Tuesday, January 20, 2004 10:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] jmx unit tests
>
>
> the jmx module unit tests are the ones we run against, the ones in
> testsuite were never maintained.
>
> A
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Juha
Lindfors
Sent: Tuesday, January 20, 2004 10:49 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jmx unit tests
the jmx module unit tests are the ones we run against, the ones
the jmx module unit tests are the ones we run against, the ones in
testsuite were never maintained.
At least 3 of the 4 failures on compliance are known issues (and reported
as such), I don't know about the JMX 1.2 notification emitter one.
The two errors are both related to classloading, at lea
Thanks jeff,
marcf
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Jeff Haynie
> Sent: Saturday, January 03, 2004 11:25 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] JMX 1.2, remoting, and jmx-remoting
>
: Saturday, January 03, 2004 7:45 AM
To: [EMAIL PROTECTED]
Cc: Tom Elrod
Subject: Re: [JBoss-dev] JMX 1.2, remoting, and jmx-remoting commited to
3.2 branch
Tom/Scott,
The modules remoting and jmx-remoting weren't integrated into the main
build and weren't being built into the main distri
day, January 03, 2004 7:45 AM
To: [EMAIL PROTECTED]
Cc: Tom Elrod
Subject: Re: [JBoss-dev] JMX 1.2, remoting, and jmx-remoting commited to
3.2 branch
Tom/Scott,
The modules remoting and jmx-remoting weren't integrated into the main
build and weren't being built into the main distribution. I
Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Saturday, January 03, 2004 7:45 AM
To: [EMAIL PROTECTED]
Cc: Tom Elrod
Subject: Re: [JBoss-dev] JMX 1.2, remoting, and jmx-remoting commited to
3.2 branch
Tom/Scott,
The modules remoting and jmx-remoting weren't integrated into the main
build and weren't being built into the main distribution. I fixed this
and also setup the default detector/connectors to be automatically
deployed as part of the default jboss-service.xml.
I've committed this fix
I'll be looking into the new errors today as well as validating these
changes.
The UnifiedClassLoader from head implements the byte code translator
interface
when it should not so I'm removing this.
The byte code translator interface also needs to be updated to be
compatible with
the JSR163 interf
On Tue, 2003-12-09 at 14:48, Alexey Loubyansky wrote:
> Are the jmx:${host.name}:rmi and jmx/invoker/RMIAdaptor different? I
> knew that the first one is just an old name.
>
> In fact, jmx/invoker/RMIAdaptor works but jmx:${host.name}:rmi does not.
>
jmx:${host.name}:rmi uses plain RMI.
jmx/inv
Are the jmx:${host.name}:rmi and jmx/invoker/RMIAdaptor different? I
knew that the first one is just an old name.
In fact, jmx/invoker/RMIAdaptor works but jmx:${host.name}:rmi does not.
Thank you.
Adrian Brock wrote:
Try it with the RMI invoker adapter
(bound at jmx/invoker/RMIAdaptor).
That
Try it with the RMI invoker adapter
(bound at jmx/invoker/RMIAdaptor).
That does late unmarshalling of arguments
when the correct classloader is known.
Vanilla RMI is pretty bad at hot deployment and classloader
selection.
Regards,
Adrian
On Tue, 2003-12-09 at 14:03, Alexey Loubyansky wrote:
>
I'll look into this today.
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Tom Elrod wrote:
...
For the CVS/build gurus out there, I would appreciate any pointers on why
build not working under the jmx-remoting directory.
Thanks.
-Tom
sage-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] Behalf Of
> > > Francisco Reverbel
> > > Sent: Monday, October 20, 2003 4:21 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [JBoss-dev] JMX DR3 rollback commit
> > >
&g
m going to wait an extra day before doing commit. Am also
assuming that the post below is not an objection to the commit, but a well
founded rant.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Francisco Reverbel
Sent: Monday, October 20, 2003 4:21 PM
To: [E
st below is not an objection to the commit, but a well
> founded rant.
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of
> > Francisco Reverbel
> > Sent: Monday, October 20, 2003 4:21 PM
> > To: [EMAIL PRO
m: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of
> > Francisco Reverbel
> > Sent: Monday, October 20, 2003 4:21 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-dev] JMX DR3 rollback commit
> >
> >
> > Guys,
> >
> > The test result
t; Sent: Monday, October 20, 2003 4:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] JMX DR3 rollback commit
>
>
> Guys,
>
> The test results Tom posted show IIOP tests failing on HEAD.
> I understand
> this is not his fault, as his changes were not yet merged
> into
Guys,
The test results Tom posted show IIOP tests failing on HEAD. I understand
this is not his fault, as his changes were not yet merged into HEAD when
the tests were run. Anyway, I've fixed IIOP in HEAD less than a month ago.
All IIOP tests were running with no errors back then.
I'm tired o
Thanks for the great work Tom!
Bill
Tom Elrod wrote:
Hello all. I have been working on bringing in the source code from the jmx
project from the Branch_4_0_DR3 into HEAD. This is needed since it is
compliant with JMX 1.2, which is needed for some of the other modules (like
JMX Remoting). Ever
JMX remoting (as it stands now) is in pretty decent shape. By this I mean
the main features have been implemented (detectors, connectors,
classloading, etc.). However, it has not been strenuously tested in the
field yet.
Also, much of what is there now will probably change to use the more generi
Yes, this is my fault and will resolve.
My IDE automatically puts those at the top of every new class and I have
to remember to delete them and replace for JBOSS code.
This code is part of JBOSS and not part of Vocalocity.
I will remove ASAP.
Jeff
-Original Message-
From: [EMAIL PROTEC
Holger Engels wrote:
Without even understanding, what the specifics of detyped invocation, ..
are, I _can_ say, that using the microkernel on the client side is the
way to go. It's aspect oriented programming, what the EJB spec is all
about (although most people seem to ignore it). Only the notati
What do you mean by the micokernel?
Regards,
Hiram
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Scott
> M Stark
> Sent: Monday, November 11, 2002 3:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [
CTED]>
Sent: Sunday, November 10, 2002 8:25 PM
Subject: RE: [JBoss-dev] JMX on the client side?
> >
> > Hiram, I think you missed the point. Of course we could do this with
> > out requiring JMX; anything is possible. The point is if we agree that
> > JMX is always on th
On Mon, 2002-11-11 at 07:13, Dain Sundstrom wrote:
> Hiram Chirino wrote:
> >>Hiram, I think you missed the point. Of course we could do this with
> >>out requiring JMX; anything is possible. The point is if we agree that
> >>JMX is always on the client side then entire system is simplified.
> >
forge.net]On Behalf Of David
> Jencks
> Sent: Monday, November 11, 2002 12:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] JMX on the client side?
>
>
> Let me give you my example of why I want it.
>
> I worked over the trunk invoker so it would do distributed tran
Hiram Chirino wrote:
Hiram, I think you missed the point. Of course we could do this with
out requiring JMX; anything is possible. The point is if we agree that
JMX is always on the client side then entire system is simplified.
I guess the disconnect is happening right here. IMO JMX does not
Let me give you my example of why I want it.
I worked over the trunk invoker so it would do distributed transactions.
This requires at least a source of xid's on the calling side, and
preferably a TransactionManager. Well, they are already there if the
calling side is a jboss instance. If it's
>
> Hiram, I think you missed the point. Of course we could do this with
> out requiring JMX; anything is possible. The point is if we agree that
> JMX is always on the client side then entire system is simplified.
>
I guess the disconnect is happening right here. IMO JMX does not always
make t
Hiram Chirino wrote:
What I would like to know, is: what are the features that JMX provides that
you need on the client side??
(1) Is it the interceptor architecture built around JMX?
(2) Is it the ability to look up other services via JMX?
I want to know because I think that we can provide clien
November 09, 2002 12:00 PM
Subject: RE: [JBoss-dev] JMX on the client side?
Scott,
Interesting.. Do you have this scoped in your mind yet? I mean, Jboss (I
hate how outlook "fixes" the b in jboss) currently uses JavaGroups,
which assumes a multicast-enabled network. When you get to tru
> > > JMX on the client side and JBoss on the client side are two different
> > > things, right? AFAIK, MBeanServerFactory.createMBeanServer() doesn't
> > > require the service deployer. If it does, that's another thing...
> >
> > Agreed. All I am talking about is an MBean server. If someone wa
> +1. This all came about because I was thinking about client side caches
> with server invalidation. Without the JMX kernel it is a pain because
> we have invent a totally new architecture to handle server to client
> invocations. If we have the kernel, we quickly prototype this by
> reusing the
Scott M Stark wrote:
> A JMX microkernel on the client is an avenue to explore. The focus
> should be extending the current dynamic proxy and detached invokers
> to a kernel for peer-peer type of computing: agents, grid computing,
> JMS, RMI callbacks, distributed caches, and whatever P2P is going
David Jencks wrote:
Agreed. All I am talking about is an MBean server. If someone wants
more JBoss services on the client side they can do that, but it
shouldn't be required.
Conceptually I like this, but...
Are you thinking that these mbeans won't have any attributes? Or do you
plan to se
ou must be envisioning more?
James
> -Original Message-
> From: Scott M Stark [mailto:scottmstark@;attbi.com]
> Sent: Saturday, November 09, 2002 12:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] JMX on the client side?
>
>
> A JMX microkernel on the client is
, LLC
- Original Message -
From: "Dain Sundstrom" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 09, 2002 9:10 AM
Subject: Re: [JBoss-dev] JMX on the client side?
> Matt Munz wrote:
> > What's wrong with m
On 2002.11.09 12:10:20 -0500 Dain Sundstrom wrote:
> Matt Munz wrote:
> > What's wrong with mbeanServer().registerMBean(mmb, name) ?
>
> Thank you matt. That is exactly what I am thinking.
>
> The first time you lookup an EJB or JMS connection, we we lazily force
> the client side to have an MB
Matt Munz wrote:
What's wrong with mbeanServer().registerMBean(mmb, name) ?
Thank you matt. That is exactly what I am thinking.
The first time you lookup an EJB or JMS connection, we we lazily force
the client side to have an MBeanServer. Then we register only the
mbeans required to service
David,
> I'm thinking of a minimal that is perhaps smaller than that. I think
> that
> the MBean API + proxies should be sufficient for many clients.
> Currently setting up the sar deployer is done in the jboss startup code,
> and the "minimal" jboss-service.xml is then read in. Without this, h
On 2002.11.08 23:33:50 -0500 Matt Munz wrote:
> David,
>
> > Hard to know. We do have the minimal jboss configuration, which is a
> good
> > starting place: as I recall basically all it can do is deploy .sars.
> AFAIK
>
> I'm thinking of a minimal that is perhaps smaller than that. I think
> th
David,
> Hard to know. We do have the minimal jboss configuration, which is a good
> starting place: as I recall basically all it can do is deploy .sars.
AFAIK
I'm thinking of a minimal that is perhaps smaller than that. I think that
the MBean API + proxies should be sufficient for many clients
#x27;s idea right?
Any other ideas?
thanks
david jencks
> :) ...
>
> - Matt
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of James
> Higginbotham
> Sent: Friday, November 08, 2002 4:42 PM
> T
> JBoss Unlimited.
> JBoss Unleashed.
> Infinite JBoss.
>
> This is the kind of thing that makes suits giddy with joy.
Right! Or:
JBoss Web Service Platform
JBoss: Web Service Edition
JBossXML
In fact, if you change the tagline from WebOS to WebServiceOS, you can
charge more consulting bucks on
On Fri, 8 Nov 2002, James Higginbotham wrote:
> Right.. I'm not talking about Jboss proper, I'm speaking of a rich
> client platform that uses jboss as its service arch kernel. Imagine a
> world where jboss is installed everywhere - client and server. ;)
JBoss Unlimited.
JBoss Unleashed.
Infinite
ay, November 08, 2002 4:42 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] JMX on the client side?
>
>
> > I think James had more esoteric plans...
> >
> > -danch
> >
>
> Right.. I'm not talking about Jboss proper, I'm speaking of a
&
riday, November 08, 2002 4:42 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JMX on the client side?
> I think James had more esoteric plans...
>
> -danch
>
Right.. I'm not talking about Jboss proper, I'm speaking of a rich
client platform that uses jboss as its service ar
> I think James had more esoteric plans...
>
> -danch
>
Right.. I'm not talking about Jboss proper, I'm speaking of a rich
client platform that uses jboss as its service arch kernel. Imagine a
world where jboss is installed everywhere - client and server. ;)
James
Matt Munz wrote:
Is this a good idea? Should we look at it for 4.0?
Great idea, Dain. Once you get that far, building client container
functionality should be pretty simple...
It makes sense to me. The closer a client environment models the server,
the better, IMO. Of course, the client s
: Thursday, November 07, 2002 10:12 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX on the client side?
+1000
This will greatly simplify many things, such as the trunk
invoker client.
I'd like to suggest that we also consider basing
UserTransaction on a transaction manager i
ent-admin@;lists.sourceforge.net]On Behalf Of Dain
Sundstrom
Sent: Friday, November 08, 2002 3:29 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX on the client side?
Yep, these are the technical issues. We should be able to code around
them, but it may be challenging. I am really interested in what
ever
-
could I end up with 2 kernels in the same VM? Just a thought..
This would rock!
James
-Original Message-
From: Dain Sundstrom [mailto:dain@;daingroup.com]
Sent: Friday, November 08, 2002 11:25 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX on the client side?
Yes that is ex
;-Original Message-
> >>From: David Jencks [mailto:davidjencks@;directvinternet.com]
> >>Sent: Thursday, November 07, 2002 10:12 PM
> >>To: [EMAIL PROTECTED]
> >>Subject: Re: [JBoss-dev] JMX on the client side?
> >>
> >>
> >
: [JBoss-dev] JMX on the client side?
+1000
This will greatly simplify many things, such as the trunk
invoker client.
I'd like to suggest that we also consider basing
UserTransaction on a transaction manager instance on the
client: this would allow UserTransaction to use the same
propag
Interesting.. Are you guys talking about a small JMX container on the
client invoker side? Or something else?
> -Original Message-
> From: David Jencks [mailto:davidjencks@;directvinternet.com]
> Sent: Thursday, November 07, 2002 10:12 PM
> To: [EMAIL PROTECTED]
> Subj
+1000
This will greatly simplify many things, such as the trunk invoker client.
I'd like to suggest that we also consider basing UserTransaction on a
transaction manager instance on the client: this would allow
UserTransaction to use the same propagation mechanism as distributed
transactions (shi
static final long serialVersionUID
= -9120448754896609940L;
thank you.
- Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of Scott
M Stark
Sent: Thursday, November 07, 2002 5:59 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX-
> Is this the object graph on the server side? In other words, the response
> object graph?
>
Its the object being unmarshalled in the client vm that originated from the server.
> The response object is really just a glorified Vector of Strings. Now it is
> possible, perhaps, but unlikely, tha
ehalf Of Scott
M Stark
Sent: Thursday, November 07, 2002 3:14 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JMX-RMI headaches
Well apparently the closure of the referenced object graph is including
QName due to an object holding onto an XML element or the like, and
the client and server don&#
Well apparently the closure of the referenced object graph is including
QName due to an object holding onto an XML element or the like, and
the client and server don't agree on the definition of javax.xml.namespace.QName.
Scott Stark
Chief Technology Officer
JBoss Group, L
> Hi,
>
> I've already put some code in 4.0 to sort the Domains/MBeans.
>
> Regards,
> Adrian
>
Excellent. I won't do that part then :)
Scott
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_
Done. Thanks Scott.
https://sourceforge.net/tracker/index.php?func=detail&aid=630789&group_i
d=22866&atid=376687
Scott
> -Original Message-
> From: Scott M Stark [mailto:scottmstark@;attbi.com]
> Sent: Tuesday, October 29, 2002 2:54 PM
> To: [EMAIL PROTECTED]
&
Hi,
I've already put some code in 4.0 to sort the Domains/MBeans.
Regards,
Adrian
From: "Scott M Stark" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
Subject: Re: [JBoss-dev] [jmx-console] changes to support multiple boolean
operations
Date
Submit the patch(es) to sourceforge and I'll look to integrate them.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Scott Sanders" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 29, 2
What is the CVS command you are using, so I can try to reproduce.
--jason
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED]] On Behalf Of Bill Burke
> Sent: Monday, October 07, 2002 2:58 PM
> To: Jboss-Dev
> Cc: Jboss-Group@Jboss. Org
> Subject: [JBoss-de
Thanks!!
david jencks
On 2002.09.30 10:19:22 -0400 Adrian Brock wrote:
> Fixed in HEAD.
>
> Regards,
> Adrian
>
>
> >From: David Jencks <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: jboss-dev <[EMAIL PROTECTED]>
> >Subject: [JBoss-dev] JMX -- Problem with dynamic mbean w/null info
Fixed in HEAD.
Regards,
Adrian
>From: David Jencks <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: jboss-dev <[EMAIL PROTECTED]>
>Subject: [JBoss-dev] JMX -- Problem with dynamic mbean w/null info.
>Date: Mon, 30 Sep 2002 00:37:02 -0400
>
>Hi,
>
>I'd appreciate it if one of the jmx expert
Hi Scott,
Yeh, we could do this, but see later.
There is no real reason why this shouldn't be a valid ObjectName
jboss.j2ee:service=Ejb,jndi-name=java:/blah
other than the spec of course.
Only the first : has any relevence for parsing.
The other reserved characters =*, are similar although ,
ca
Sorry, wrong list...
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Per
> Nyfelt
> Sent: Wednesday, August 21, 2002 1:53 PM
> To: Jboss-Development@Lists. Sourceforge. Net
> Subject: [JBoss-dev] JMX
>
>
> There's a pretty good article on JMX at T
AIL PROTECTED]>
>Subject: Re: [JBoss-dev] JMX Serialization and 3.0
>Date: Sat, 17 Aug 2002 12:10:01 -0400
>
>If these changes break the existing JMX api and user MBeans in 3.0.x then
>don't commit the changes there. If it just affects the JMX implementation
&g
If these changes break the existing JMX api and user MBeans in 3.0.x then
don't commit the changes there. If it just affects the JMX implementation
then
they can be put into 3.0 for 3.0.2 if you want.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
x
proxy.
cheers,
SAcha
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> David Jencks
> Envoyé : mercredi, 26 juin 2002 13:42
> À : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] JMX: Adding Model MBean database persistence
On Wed, 26 Jun 2002, David Jencks wrote:
> This may work fine for packages deployed by a deploymentScanner, but will
> work less well for packages deployed by directly calling
> MainDeployer.deploy. Scanning for packages may not be the most useful
> deployment method... even though right now it
Your ideas both seem promising. I'm still not sure about what we want as
the primary determinant of which mbeans are present in a restarted server.
My impression of your proposals is that they result in the set of mbeans
being determined by the deployed *-service.xml files available at restart,
First of all, I'm really delighted you are working on this.
You are going to have conflicts with our current usage of **-service.xml
files, since we are abusing them to serve for both telling the server what
mbeans we want and what their initial configuration is, and as our only
form of persisten
On Wed, 26 Jun 2002, Paul Ward wrote:
> Why I had to create an XMBean descendant:
>
> First, XMBean's link to the PM interface is through the instance created in the
>static
> initializer for the ModelMBeanInvoker class. This class is hard coded to use the
>NullPersistence
> class as it's PM.
Why I had to create an XMBean descendant:
First, XMBean's link to the PM interface is through the instance created in the static
initializer for the ModelMBeanInvoker class. This class is hard coded to use the
NullPersistence class as it's PM. The only flexibility to change this that I've fou
On Tue, 25 Jun 2002, Paul Ward wrote:
> I am currently in the process of creating an XMBean descendant and
>PersistenceManager implementation
We don't need an XMBean descendant, just the PM implementation.
> Is there any interest in having this added to the JBoss head?
Yes.
> If so, does an
On 2002.06.18 14:44:36 -0400 marc fleury wrote:
> |It won't do multiple languages yet AFAIK, but how about using the xmbean
> |functionality? You can put the descriptions in your source files and
> |generate the xmbean xml descriptors using xdoclet. I don't know if
> jetty
>
> That's really coo
|It won't do multiple languages yet AFAIK, but how about using the xmbean
|functionality? You can put the descriptions in your source files and
|generate the xmbean xml descriptors using xdoclet. I don't know if jetty
That's really cool, does it support initial values for the attributes as
well
It won't do multiple languages yet AFAIK, but how about using the xmbean
functionality? You can put the descriptions in your source files and
generate the xmbean xml descriptors using xdoclet. I don't know if jetty
is using the jboss service controller stuff to load its mbeans, but that
system w
> The JMX Connectors are not written for JBoss specific. Because JMX allows
> you
> to have more than one MBeanServer per JVM and there is a good chance that
> a box have more than one JVM running this is not so far fetched. Especially
> when
> an external JNDI server is used.
Ok, that is fine, b
Hi Jason
> How and when is this a problem? The two servers will be sharing a JNDI
> server then? When does this happen and who uses JBoss in this fashion.
It
> seems like there might be more snags than just the placement of the RMI
> adapter.
The JMX Connectors are not written for JBoss spe
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: Re: [JBoss-dev] JMX RMI Adapter & JNDI binding
Date: Mon, 13 May 2002 19:59:24 +
From: Jason Dillon <[EMAIL PROTECTED]>
To: "Hiram Chirino" <[EMAIL PROTECTED]>,
Resending due to my messed up sendmail config...
-- Forwarded Message --
Subject: Re: [JBoss-dev] JMX RMI Adapter & JNDI binding
Date: Mon, 13 May 2002 19:58:16 +
From: Jason Dillon <[EMAIL PROTECTED]>
To: "Andreas Schaefer" <[EMAIL PROTECTE
You can give the testsuite a ".ant.properties" file overriding the
servername. I've got a config that I use to run marathon on my laptop
against my 'big' machine at home. I can send this out this evening, if
anyone is interested. Unfortunately I don't have that stuff with me
right now.
As far
On Sun, 12 May 2002, Jason Dillon wrote:
> Currently we are binding to "jmx::rmi" which is fine when you are
> working with the localhost, but will start to cause problems once used in a
> multi-host environment.
>
...
>
> So for a client on a remote host to correctly make use of the deployer.sh
>From: "Andreas Schaefer" <[EMAIL PROTECTED]>
>To: "Hiram Chirino" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
><[EMAIL PROTECTED]>
>Subject: Re: [JBoss-dev] JMX RMI Adapter & JNDI binding
>Date: Mon, 13 May 2002 08:26:36 -0700
&g
1 - 100 of 160 matches
Mail list logo
