what I am hearing is that you want jbossmq/jboss/servlet configuration in
xml snippets in jboss.jcml, otherwise I don't see what it brings except yet
another layer of indirection...
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Peter
|Antman
|Sent: Monday, June 11, 2001 3:02 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] JMSContainerInvoker.java
|
|
|On 10 Jun, marc fleury wrote:
|> |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?
|
|Short example:
|
|>From jboss.jcml:
|
| <mbean code="org.jboss.naming.NamingService"
|name="DefaultDomain:service=Naming">
| <attribute name="Port">@rmi.port@</attribute>
| </mbean>
| <mbean code="org.jboss.naming.JNDIView"
|name="DefaultDomain:service=JNDIView" />
|
|You see the @rmi.port@
|
|In a propertyfile, for example default.properties ;-)
|
|rmi.port=1099
|
|
|Some stuff in build.xml:
|
|<property name="templates.properties"
|value="${jboss.dir.templates}/default.properties"/>
|
|This may be reset dynamicaly with -Dtemplates.properties to use other
|values for an installation.
|
|Turn on filtering while copying:
|
| <filter filtersfile="${templates.properties}"/>
| <copy overwrite="${install.overwrite}" filtering="yes"
|todir="${install.dir}/server/conf/tomcat/">
| <fileset
|
|includes="jboss.properties,jboss.conf,jboss.jcml,jndi.properties,lo
|g4j.properties,jnp.properties,standardjboss.xml,jbossmq.xml,alertMa
|il.properties"
| dir="${jboss.dir.templates}"
| />
|
| </copy>
|
|
|Makes it a snapp to install differently configured JBoss servers, just
|write a new property file to make your installment from.
|
|I particulary like this in jbossmq.xml:
|
|<Topic><Name>bob</Name></Topic>
| @topics@
|
|This is where I drive my destination configurations ;-)
|
|
|>
|> |
|> |# 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
|
|Calm down ;-)
|
|>
|> |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...
|
|He, he. But see further down too. Should it really be in
|JMSContainerInvoker. One thing thats bothers me is that there are
|several indications on that JBossMQ is actually not that production
|ready. It behaves eratic during heavy load (messages are lost, and it is
|VERRY slow), there are some creapy buggs in the management of durable
|topic subscription, a server may dissapear without the clients ever
|getting to know it, and probably much more.
|
|Hiram has done a fantastic jobb, but he does not seem to have that much
|time any longer, and no one else has really showed up to take over or
|work with the hard parts beside him.
|
|I know there are some potential guys in there, that could probably solve
|this stuff.
|
|But until that has happened it is probably wise to have an
|implementation of MDB that is possible to use with another JMS provider.
|
|Or, Marc, try to inspire some of the wise guys on this list to take on
|JBossMQ. It would actually be good if there where more than one
|developer active with JBossMQ at a time.
|
|
|//Peter
|>
|> (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
|
|--
|Jobba hos oss: http://www.tim.se/weblab
|------------------------------------------------------------
|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
