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,log4j.properties,jnp.properties,standardjboss.xml,jbossmq.xml,alertMail.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
