|I do like simplicity of management (that why I redo every JBoss
|distribution so I can configure it with a single property file - Ant,
|copy and filter).
what do you mean, what do you redo?
|
|# Here some code
|
|set_my_variable(11);
|print get_my_variable;
|
|What do you think one will get, yes 1. Do you get any warnings? NO. Is
|it hard to debug? Oh, yes. Verry hard.
|
|I think automatic creation of destinations for MDB suffers the same of
|problems.
geez you guys are all banging on this feature... you know what?
two peas in a bucket
f*ck it! (as my father in law will say (deep south))...
we will see if people complain
|What happens when a created destination is suddenly destroyed when the
|MDB is undeployed (perhaps for a redeploy because of code change)? Well,
|all publisher to that destination will bark and be gone (if they was not
|coded to be failsafe). Suddenly we do not have a loosly coupled system
|any more, but the destination becomes just another remote interface
|against the bean (answer: use stateless sessions instead of MDB).
uh.... tell me how is that related to the fact that we create it at
deployment time? if you remove a destination (period) then all clients will
be barking... if not then create a "durable topic" in the right JMS stuff...
we are not out to solve the world problems, if you want a durable topic
then you need to tell us. I still stick to my guns (and I could be wrong)
|Ok,ok,ok. The only (I say only) acceptable thing a can think of is that
|it *might* be OK if the jboss.xml is completly missing. Then we might do
|somethink like automatic creation, *but only then*.
ah... look at me in the eye... yes I do see that gleam in the corner of your
eye... you still see it don't you? yeah..ease of use for management, the
"dirty step child" of J2EE we are squarely competing at the low end with
very high end features for management... yeah you know it! yeah that
gleam...
(drunk)
marcf
|
|2. Is it a good think to implement it in JMSContainerInvoker?
|
|Well, maybe not. The container invoker is designed to be agnostic about
|the underlying JMS provider. All its ways to communicate with the JMS
|provider is done through indirection and interfaces. If this is placed
|in JMSContainerInvoker it should not be dependand on any special JBossMQ
|features, such as being able to create destinations on the fly through
|JMX. Or perhaps to be more correct, if this is done, is must be a part
|of the org.jboss.jms package that a JMX based destination creator is
|part of the JMSContainerInvoker contact.
|
|Was that clear, or am I just babling around?
|
|Chers
|Peter
|
|
|On 1 Jun, Hiram Chirino wrote:
|> My vote on the issue is turn the feature OFF by default.
|>
|> A JMS queue is like a database table: I don't want the thing getting
|> created and destroyed every time I deploy and undeploy a bean. This is
|> mainly doe to the time indepenent processing "feature" JMS usually gives
|> you. If you are creating and destroying a destination, the publisher
|> becomes time dependent on when the bean is deployed (does this
|make sense?).
|>
|> Regards,
|> Hiram
|>
|>
|> ----- Original Message -----
|> From: "Juha-P Lindfors" <[EMAIL PROTECTED]>
|> To: <[EMAIL PROTECTED]>
|> Sent: Friday, June 01, 2001 6:34 PM
|> Subject: RE: [JBoss-dev] JMSContainerInvoker.java
|>
|> j
|>>
|>>
|>> On Fri, 1 Jun 2001, marc fleury wrote:
|>> > to clear fuck-ups... yet if you screw up it doesn't hide the mistake,
|> your
|>> > application won't work.
|>>
|>> yes... but I want to know exactly *WHY* it doesn't work :)
|>>
|>> > |I'd much rather see the lookup fail than have the server hide my fuck
|> ups.
|>> > |Because that very clearly indicates something's wrong in the
|>> > |configuration.
|>> >
|>> > and by doing so you prevent those that didn't fuck up from having a
|>> > convenient feature. Design by exception.
|>>
|>> hey, I just like my errors pointed out to me in a clear and unambiguous
|>> matter. It's because I make lots of them and have rarely fun time trying
|>> to find them... :P
|>>
|>>
|>> > |The proposed implementation requires me to go clean up the
|jbossmq.xml
|>> > |unless I like to have the naming space cluttered with stuff
|that wasn't
|>> > |supposed to go there. It also allows the application to
|silently fail,
|> as
|>> > |Peter pointed out.
|>> >
|>> > Please read my mails, point 7.
|>>
|>> you make too many, and they're repetitive and become boring :)
|>>
|>>
|>> > Also, I don't see the "silently" point, if you don't have the
|right name
|> you
|>> > get 2 things from us
|>> > 1- A "Creating topic"
|>> > 2- An exception in your application
|>>
|>> I mean, where I create a MDB and lookup 'bob' which isnt right
|>> or configured and the server then creates it, and then have a client
|>> that *correctly* looks up 'Bob' which was probably configured
|by some guy
|>> three years ago. Everyone's happy, except I'm tearing
|>> my hair out wondering why the fuck my messages arent getting through.
|>>
|>> See it?
|>>
|>> half my components talk to 'bob', the other half talks to 'Bob' and
|>> everyone refuses to talk to the other party.
|>>
|>> As long as its painfully obvious that the server is trying to be smart
|>> even in cases where it shouldnt, where it was my fault, its ok
|by me. And
|>> if it does destroy the topic so that I don't end up with bob,
|Bob, BoB and
|>> BOB in my config, then I can live with it.
|>>
|>> -- Juha
|>>
|>>
|>>
|>> _______________________________________________
|>> Jboss-development mailing list
|>> [EMAIL PROTECTED]
|>> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>>
|>
|> _______________________________________________
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|
|--
|------------------------------------------------------------
|Peter Antman Technology in Media, Box 34105 100 26 Stockholm
|Systems Architect WWW: http://www.tim.se
|Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
|Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
|------------------------------------------------------------
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
