Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-08 Thread Rickard Öberg
But you really don't know what you are talking about when you talk about transactions? Is this a question or sarcasm? I just can't tell... /Rickard ___ Jboss-development mailing list [EMAIL PROTECTED]

Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-07 Thread Jason Dillon
David Jencks wrote: I still don't understand how jini and jmx can relate. They seem to me to be unrelated and non-interoperable implementations of to a large extent the same functionality (as far as finding stuff, not failure recovery in a distributed environment). JMX handle the

Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-07 Thread Jason Dillon
This leads me back to my proposal of generating a collective of servers (yeah, your right, the BORG collective, because each server should know the whole configuration allowing the collective to work even when a member dies or is temporary unavailable IN CONTRAST to the community of

Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-07 Thread Rickard Öberg
Jason Dillon wrote: David Jencks wrote: I still don't understand how jini and jmx can relate. They seem to me to be unrelated and non-interoperable implementations of to a large extent the same functionality (as far as finding stuff, not failure recovery in a distributed

Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-07 Thread Jason Dillon
The network is the computer, the computer is the network, who cares... java lets you do cool things. Admins across the planet (perhaps beyond) will be greatful for millenia to come. Assuming we can get of the planet before the sun goes red giant =) Assuming that there will be a need

Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-07 Thread Rickard Öberg
Jason Dillon wrote: It can simply be a serializable? Yes. Any object is ok. An RMI stub *happens* to be one such case, and most people seem to assume that this is what it *has* to be. Not so. How about resource control? I guess you would implement that at the stub level? If I want a

Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-07 Thread Jason Dillon
on 1-09-07 09.42, Rickard Öberg at [EMAIL PROTECTED] wrote: How does Jini make JBoss a better platform for writing applications? Because it makes servers aware of other servers more easily, and services aware of other services more easily. JINI is broadcast so is JavaGroups - one is

Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-07 Thread Jason Dillon
*hit, what the heck am I rambling about... please forgive me. --jason On Fri, 7 Sep 2001, Jason Dillon wrote: on 1-09-07 09.42, Rickard Öberg at [EMAIL PROTECTED] wrote: How does Jini make JBoss a better platform for writing applications? Because it makes servers aware of other

Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-07 Thread Rickard Öberg
Jason Dillon wrote: FYI I am not against JavaGroups. I have read up on Jini, found it quite meaningful. How does Sun expect it to take off with a restrictive license. What is restrictive in the license? What are the differences between JavaGroups and Jini? Jini is this: * Discovery *

RE: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-07 Thread marc fleury
| In your opinion; What needs to be done to make this happen? Hope and | promise are prevalent, but there must be order to take an idea |and turn it | into a reality. | |When the service deployment stuff in JBoss3 stabilizes that should be |pretty much it. MBean wrappers for core Jini services

Re: Deployment Dependencies (was RE: [JBoss-dev] RH startup andJBossMQ)

2001-09-06 Thread Jason Dillon
I still think that it is a bad idea to have every node in a cluster to have the complete configuration information for every other node. This simply will not scale. You bring up also later but first let's talk about how much data each node has to manage and how often we expect that