On 11 Jun, marc fleury wrote:
> 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...
I guess it depends on you requirements. Mine is that I must be able to
support a lot of installations of JBoss on machines I do not have
complete controll over, such as ports, multihomed and such things.
My experience from working with JBoss for almost a year now is that the
configuration files changes a lot al the time, and it is quite hard to
diff all these files all the time when a new release arrives, or when I
have to go cutting cvs edge ;-).
It is much easier to have one central property files wich controlles all
those environment stuff (much like a preprocessor), just try to diff
standardjboss.xml with all those hardcoded
<RMIObjectPort>4444</RMIObjectPort>!
A local installation is therefore goverend by a template repository
(configuration files and a template propertyfile, where all environment
stuff is gathered). Here is my default for a vanilla JBoss installation.
# Default filter porperties for JBoss
java.rmi.server.hostname=#java.rmi.server.hostname=localhost
java.rmi.server.codebase=#java.rmi.server.codebase=http://localhost:8080/
java.naming.provider.url=#java.naming.provider.url=localhost:1099
jnp.port=1099
java.Xms=-Xms6m
java.Xmx=-Xmx128m
rmi.port=1099
rmi.object.port=4444
webservice.port=8083
hypersonic.port=1476
htmladapter.port=8082
topics=<Topic><Name>logging</Name></Topic>
queues=
mail.user=pra
mail.smtp.host=dagobert.annons.dn.se
[EMAIL PROTECTED]
# Tomcat Stuff
tomcat.http.port=8080
tomcat.Ajp12.port=8007
I need a customized install? I create a new template file and does
sh build.sh -Dtemplate.properties=alternative.file install
Say I have 10 installs with different configuratins. When I uppgrade
JBoss I do a check between the files in the template repository and
upgrade all changed configuration files. Then I just do an re install on
all machines with the local property file.
This was the best I could come up with to make installation and
upgrading of JBoss as smoth as possible.
Maybe its not the best there is, but it shure works better than without
it.
//Peter
ps
I actually think this would be great to have built in to JBoss, so that
all machine dependant parameters where configurable through a
preprosessor when installing JBoss, but that my 2c.
ds
>
> 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
--
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
