|> 2- If you miss the spelling.. we should put a message saying "Creating
|> topic" and that's it.. very convenient.
|
|In this case, no, its not very convenient in my opinion. My application
|won't work since the MDB is subscribed to the wrong topic. So why bother
|deploying it at all. It's not going to receive anything anyhow, cause no
|other component in my app is going to publish anything to it.
It is not convenient in the sense that it won't make your mistake go away,
but for those that don't fuck up it is convenient.
If you fucked up, your application won't work anyhow, this is not a feature
to clear fuck-ups... yet if you screw up it doesn't hide the mistake, your
application won't work.
The idea is to enable single listening MDB to create and destroy the topic
they listen to.
|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.
An MDB can create the topic he listens to at deployment time automatically,
where is the evil in that :)?
|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.
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
wanna code a "verifier" barf??? you can do it :)
|There are two clear cases where you reach this exception code. Either the
|admin didn't configure the server correctly, or the developer made
|a mistake.
Well, there is also the case of the guy deploying the MDB and wanting the
server to create the topic at deployment and destroy it at undeployment...
to me it is like us defaulting to the ejb-server name if no jboss.xml jndi
name is specified.
An MDB is deployed, he will listen to a topic for the duration of his life,
the server creates the topic if not present for the duration of his life.
Create topic at deployment, delete at undeployment.. why is this so
contentious, I really fail to see it.
|> 7- Re: creating the topic, **uncreate** it at undeployment and basta! no
|> more non-sense.
|
|No that won't work. The MDB is just one client to the topic. You don't
|want to delete the topic because one subscriber decides to leave.
Yes it will...
If the MDB is deployed and there is no topic we can create and delete the
topic for the time the MDB is up. The MDB *IS* the only subscriber.
If the MDB is deployed and there is a topic we just listen to it, no create,
no delete. If you want many subscriber then you are by definition in the
second case.
|-- Juha
Boy, you guys are in a collective bad mood... what the fuck... this is a
simple feature, with a clear defined boundary and a clear advantage.
I really feel like it is a *relevant* MDB feature but you are free to
disagree. Who coded that, Doug? He felt the need, I still think it is
valid. He scratched an itch...
marcf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
