Hi,
sorry I misses all the fun (we have had one of our christian hollidays,
and I have been banging nails into my summer cottage ;.)).
Let first state a simple fact. We should actually disuss two things:
1. Is it a good feature to have automatic creation of destinations for
MDB when JNDI lookup fails for a given topic?
2. If we should want that, where and how should it be implemented?
1.
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).
But I do also want my languages and systems to have a design that helps
in development and deployment. I once was quite a good perl programmer,
and I think I did know the language quite well with all its added "my"
and "use strict" to sort of compensate for the early bad language
designs that where made.
Perl is what we could call a loosly coupled language/system. Lets look
at a *verry common error".
$my_variable;
$MY_DEFAULT = 1;
sub get_my_variable {
return $my_variable || $MY_DEFAULT;
}
sub set_my_variable {
$my_valiable = shift;
}
# 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.
Here is another one for the book!
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).
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*.
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
