RE: [JBoss-dev] JMSContainerInvoker.java
|We have denied jBoss write privilidge to itself and only allow it to write |where it needs to. It may be a bad idea to allow jBoss to modify its own |jcml file (we have disabled the auto jcml feature) or to replace |executable |modules that comprise it. | |OTOH, it may not be such a bad idea for a seperate process to have |privilidge to do this, since it would need only be invoked when |its time to |upgrade jBoss. | |Just my 2 cents... my 39 cents (hey it's me!) frankly we are bundling 4 concerns in one... we need administration done right (auto.jcml is going away replaced by something better). we need remote installation of *code* and securing this. we need local installation of sensitive data (the point by scott yesterday). we need remote installation and admin of *applications* and securing this... I will try to untangle the spaghetti plate as soon as I am done with the website (which should hopefully be today), but for now we are miles and miles away from even a clear understanding of the spectrum of requirements and howwe go about prioritizing them (e.g. no we will not disable the remote installation because some bank is not going to use it, that is design by exception, but we will provide ways to do it locally as non-default etc etc). marcf | |Jim | |--On Tuesday, June 12, 2001 10:14 AM +0100 Mike Swainston-Rainford |<[EMAIL PROTECTED]> wrote: | |> From my experiences at security aware sites (like financial |> institutions) I'd say that a file of the node specific properties is a |> must. Port numbers have been mentioned but what about the DB user and |> password? |> |> Access to these leaves the database wide open so they would often not |> even be held in a file on the file system but typed in during a |> deployment or startup. If they are put in a file then it lives only on |> the node to which it applies protected under a secure user id that's used |> solely for deployment of the application server. |> |> The DB user id and password are currently stored in JBoss.jcml. They |> would need to be pulled out, as suggested for the port numbers, into a |> separate properties file before the more paranoid sites I've worked at |> would consider deploying JBoss. |> |> Mike S-R |> |> At 00:05 12/06/2001 -0700, you wrote: |>> We can argue the details, but I agree with Peter about the current |>> configuration |>> being very difficult to manage. If we are going to move to a web based |>> deployment |>> to multiple boxes we won't be able to simply rely on URLClassLoaders |>> pulling down the current config files and expect them to work as many |>> configuration parameters will be specific to box on which the server is |>> being installed. |>> |>> - Original Message - |>> From: "Peter Antman" <[EMAIL PROTECTED]> |>> To: <[EMAIL PROTECTED]> |>> Sent: Monday, June 11, 2001 11:30 PM |>> Subject: Re: [JBoss-dev] JMSContainerInvoker.java |>> |>> |>> > 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 |>> > ! |>> > |>> |>> |>> |>> ___ |>> 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 | | | | |I shall be telling this with a sigh |Somewhere ages and ages hence: |Two roads diverged in a wood, and I - |I took the one less traveled by, |And that has made all the difference. | |- Robert Frost, 1916 | | |___ |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
Re: [JBoss-dev] JMSContainerInvoker.java
On the topic of security, most *nix installations, including Linux, deny an application the ability to write to itself or its tree. This is to prevent a discovered exploit from modifying the applications code and causing it do do whatever the hacker wants (crash, access stuff it shouldent,...). We have denied jBoss write privilidge to itself and only allow it to write where it needs to. It may be a bad idea to allow jBoss to modify its own jcml file (we have disabled the auto jcml feature) or to replace executable modules that comprise it. OTOH, it may not be such a bad idea for a seperate process to have privilidge to do this, since it would need only be invoked when its time to upgrade jBoss. Just my 2 cents... Jim --On Tuesday, June 12, 2001 10:14 AM +0100 Mike Swainston-Rainford <[EMAIL PROTECTED]> wrote: > From my experiences at security aware sites (like financial > institutions) I'd say that a file of the node specific properties is a > must. Port numbers have been mentioned but what about the DB user and > password? > > Access to these leaves the database wide open so they would often not > even be held in a file on the file system but typed in during a > deployment or startup. If they are put in a file then it lives only on > the node to which it applies protected under a secure user id that's used > solely for deployment of the application server. > > The DB user id and password are currently stored in JBoss.jcml. They > would need to be pulled out, as suggested for the port numbers, into a > separate properties file before the more paranoid sites I've worked at > would consider deploying JBoss. > > Mike S-R > > At 00:05 12/06/2001 -0700, you wrote: >> We can argue the details, but I agree with Peter about the current >> configuration >> being very difficult to manage. If we are going to move to a web based >> deployment >> to multiple boxes we won't be able to simply rely on URLClassLoaders >> pulling down the current config files and expect them to work as many >> configuration parameters will be specific to box on which the server is >> being installed. >> >> - Original Message ----- >> From: "Peter Antman" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Monday, June 11, 2001 11:30 PM >> Subject: Re: [JBoss-dev] JMSContainerInvoker.java >> >> >> > 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 >> > ! >> > >> >> >> >> ___ >> 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 I shall be telling this with a sigh Somewhere ages and ages hence: Two roads diverged in a wood, and I - I took the one less traveled by, And that has made all the difference. - Robert Frost, 1916 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMSContainerInvoker.java
From my experiences at security aware sites (like financial institutions) I'd say that a file of the node specific properties is a must. Port numbers have been mentioned but what about the DB user and password? Access to these leaves the database wide open so they would often not even be held in a file on the file system but typed in during a deployment or startup. If they are put in a file then it lives only on the node to which it applies protected under a secure user id that's used solely for deployment of the application server. The DB user id and password are currently stored in JBoss.jcml. They would need to be pulled out, as suggested for the port numbers, into a separate properties file before the more paranoid sites I've worked at would consider deploying JBoss. Mike S-R At 00:05 12/06/2001 -0700, you wrote: >We can argue the details, but I agree with Peter about the current >configuration >being very difficult to manage. If we are going to move to a web based >deployment >to multiple boxes we won't be able to simply rely on URLClassLoaders pulling >down the current config files and expect them to work as many configuration >parameters will be specific to box on which the server is being installed. > >- Original Message - >From: "Peter Antman" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Monday, June 11, 2001 11:30 PM >Subject: Re: [JBoss-dev] JMSContainerInvoker.java > > > > 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 > > ! > > > > > >___ >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
Re: [JBoss-dev] JMSContainerInvoker.java
We can argue the details, but I agree with Peter about the current configuration being very difficult to manage. If we are going to move to a web based deployment to multiple boxes we won't be able to simply rely on URLClassLoaders pulling down the current config files and expect them to work as many configuration parameters will be specific to box on which the server is being installed. - Original Message - From: "Peter Antman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 11:30 PM Subject: Re: [JBoss-dev] JMSContainerInvoker.java > 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 > ! > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMSContainerInvoker.java
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
!
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=
webservice.port=8083
hypersonic.port=1476
htmladapter.port=8082
topics=logging
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:
> |
> | |name="DefaultDomain:service=Naming">
> |@rmi.port@
> |
> | |name="DefaultDomain:service=JNDIView" />
> |
> |You see the @rmi.port@
> |
> |In a propertyfile, for example default.properties ;-)
> |
> |rmi.port=1099
> |
> |
> |Some stuff in build.xml:
> |
> | |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:
> |
> |
> | |todir="${install.dir}/server/conf/tomcat/">
> | |
> |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}"
> |/>
> |
> |
> |
> |
> |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:
> |
> |bob
> |@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 ;-)
> |
RE: [JBoss-dev] JMSContainerInvoker.java
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: | | |@rmi.port@ | | | |You see the @rmi.port@ | |In a propertyfile, for example default.properties ;-) | |rmi.port=1099 | | |Some stuff in build.xml: | | | |This may be reset dynamicaly with -Dtemplates.properties to use other |values for an installation. | |Turn on filtering while copying: | | | | | | | | |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: | |bob |@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 |>
Re: [JBoss-dev] JMSContainerInvoker.java
e 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 ArchitectWWW: 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 ArchitectWWW: 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
RE: [JBoss-dev] JMSContainerInvoker.java
|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? | |# 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 |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... (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 |>> >
Re: [JBoss-dev] JMSContainerInvoker.java
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
>> >
Re: [JBoss-dev] JMSContainerInvoker.java
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 > > > 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
RE: [JBoss-dev] JMSContainerInvoker.java
|you make too many, and they're repetitive and become boring :) repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha repetition works, Juha and watch your language young lady... |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? no that is *really* splitting hairs on a funky exception... ease of use. |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. sure let doug code the point you and I made about undeployment and destroying the topic (the point 7 I keep repeating :) and let's move on... marcf peace ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMSContainerInvoker.java
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
RE: [JBoss-dev] JMSContainerInvoker.java
I need to add the code to remove the queue ad undeploy. I can also make the message really huge when creating a new topic/queue. Is there anything else I should do while I got the patient open? d. -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 5:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JMSContainerInvoker.java |It will be trial to remove the topic/queue at undeployment, |if and only if I added it at deploy time Which is exactly what I am arguing for, glad to see it already coded. If no topic, create and destroy at deployment boundaries. This enables the "I listen to the topic as an MDB the server creates and destroys the topic for me"... |This way the config file won't "build up"... precisely ... |We already display a message at deploytime that says that |the queue/topic doesn't exist. So it isn't really correct |that the server hides your fuck ups. It merely deals with them |in an itelligent fashion. well I wouldn't go that far, Doug :) we *don't* deal with a fuck up, we provide a useful feature for people that *don't* fuck-up. Their point is that we make life much harder for those that *do* fuck up... I am sure I don't agree I believe the point of contention with Juha and Peter is really around the "I want to know that I fucked up *early on*". My point is really centered around "OK but let's try to not penalize those who don't fuck up". The real solution is the message you display and maybe a warning in the verifier on the server saying that the topic doesn't exist. Juha what do you think? marcf That is our story and we stick by it! -- Bill Clinton's Mother -- ___ 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
RE: [JBoss-dev] JMSContainerInvoker.java
|It will be trial to remove the topic/queue at undeployment, |if and only if I added it at deploy time Which is exactly what I am arguing for, glad to see it already coded. If no topic, create and destroy at deployment boundaries. This enables the "I listen to the topic as an MDB the server creates and destroys the topic for me"... |This way the config file won't "build up"... precisely ... |We already display a message at deploytime that says that |the queue/topic doesn't exist. So it isn't really correct |that the server hides your fuck ups. It merely deals with them |in an itelligent fashion. well I wouldn't go that far, Doug :) we *don't* deal with a fuck up, we provide a useful feature for people that *don't* fuck-up. Their point is that we make life much harder for those that *do* fuck up... I am sure I don't agree I believe the point of contention with Juha and Peter is really around the "I want to know that I fucked up *early on*". My point is really centered around "OK but let's try to not penalize those who don't fuck up". The real solution is the message you display and maybe a warning in the verifier on the server saying that the topic doesn't exist. Juha what do you think? marcf That is our story and we stick by it! -- Bill Clinton's Mother -- ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMSContainerInvoker.java
On Fri, 1 Jun 2001, Ferguson, Doug wrote: > It will be trial to remove the topic/queue at undeployment, > if and only if I added it at deploy time ok.. > We already display a message at deploytime that says that > the queue/topic doesn't exist. So it isn't really correct > that the server hides your fuck ups. It merely deals with them > in an itelligent fashion. make it a big and ugly, the size of a stack trace. Anything else will go unnoticed. We print out too much information anyhow, one liners will drown in the noise. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMSContainerInvoker.java
|> 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
RE: [JBoss-dev] JMSContainerInvoker.java
|Ok, I'm fine with this being an optional behavior. I'm not fine with that |being the only way it is. I agree. It should be labeled as default-city. JBoss only. If you specify all the bells and whistles then of course we will find the topic in JNDI and use it... J2EE standard. marcf | |- Original Message - |From: "marc fleury" <[EMAIL PROTECTED]> |To: <[EMAIL PROTECTED]> |Sent: Friday, June 01, 2001 2:20 PM |Subject: RE: [JBoss-dev] JMSContainerInvoker.java | | |> |Its not redundant as there are many provider specific properties |> |that an admin |> |has to set: security, clustering, etc. You don't create database |> |connection pools |> |automatically because there are too many provider specific |options that an |> |admin familiar with the database has to set. In general the same |> |is true with |> |JMS. |> |> Time out, |> |> I am not saying that this should be the ONLY way to do it, just |that if you |> don't specify anything in jbossmq.xml we provide a default behavior. |> |> If you want to specify the name the security the clustering then |*of course* |> you need to do it by hand. I will agree that my first point was maybe |> missleading on this. |> |> Now, if you don't specify anything in jbossmq.xml then the |default kicks in, |> and we notify the user "Creating TOPIC", simple. If there is something |> specified and the stuff already exists in the naming space then |*of course* |> you use that topic. |> |> Makes sense, Makes playing with MDBs simple. An MDB can create |the Topic he |> is listening to at deployment time and delete it at |undeployment... simple, |> why is it such an issue? |> |> marc |> | | | |___ |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
RE: [JBoss-dev] JMSContainerInvoker.java
It will be trial to remove the topic/queue at undeployment, if and only if I added it at deploy time This way the config file won't "build up"... We already display a message at deploytime that says that the queue/topic doesn't exist. So it isn't really correct that the server hides your fuck ups. It merely deals with them in an itelligent fashion. d. -Original Message- From: Juha-P Lindfors [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 4:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JMSContainerInvoker.java On Fri, 1 Jun 2001, marc fleury wrote: > 1- If it is not there, right now we have to manually go and create the damn > thing, very redundant. > 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. 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. 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. > 4- You guys are designing by exception, i.e. "h but what happens if > someone FUCKS up and mis-spells the topic. Well someone FUCKED up... and we > SAY "Creating Topic" so we give all the information, where is the harm done? > 5- You are saying, because of this possible fuck-up we should not permit the > feature that will be very useful for most people design by exception > 6- design by exception == bad This piece of code gets called by exception anyhow. It creates configuration changes that live longer than the MDB it created them for, and it has no way of knowing if the fix its trying to make is the right one or if its just messing things up more. 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. The admin mistake would be easy to notice at deployment time because there's a failed lookup. The developer mistake will be made more difficult to notice since the app can fail silently. > 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. > 8- ANYTHING THAT IS ADMIN FRIENDLY IS GOOD > > Oka? I admit I wear the developer hat more than the admin hat. But anything that makes it easier for me to find my own bugs saves my time and my nerves and someone else's money, and that is also good in my book. If I make a mistake, I'd rather know about it right away, and I'd rather not go clean up configuration files because of 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
Re: [JBoss-dev] JMSContainerInvoker.java
Ok, I'm fine with this being an optional behavior. I'm not fine with that being the only way it is. - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 01, 2001 2:20 PM Subject: RE: [JBoss-dev] JMSContainerInvoker.java > |Its not redundant as there are many provider specific properties > |that an admin > |has to set: security, clustering, etc. You don't create database > |connection pools > |automatically because there are too many provider specific options that an > |admin familiar with the database has to set. In general the same > |is true with > |JMS. > > Time out, > > I am not saying that this should be the ONLY way to do it, just that if you > don't specify anything in jbossmq.xml we provide a default behavior. > > If you want to specify the name the security the clustering then *of course* > you need to do it by hand. I will agree that my first point was maybe > missleading on this. > > Now, if you don't specify anything in jbossmq.xml then the default kicks in, > and we notify the user "Creating TOPIC", simple. If there is something > specified and the stuff already exists in the naming space then *of course* > you use that topic. > > Makes sense, Makes playing with MDBs simple. An MDB can create the Topic he > is listening to at deployment time and delete it at undeployment... simple, > why is it such an issue? > > marc > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMSContainerInvoker.java
On Fri, 1 Jun 2001, marc fleury wrote: > 1- If it is not there, right now we have to manually go and create the damn > thing, very redundant. > 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. 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. 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. > 4- You guys are designing by exception, i.e. "h but what happens if > someone FUCKS up and mis-spells the topic. Well someone FUCKED up... and we > SAY "Creating Topic" so we give all the information, where is the harm done? > 5- You are saying, because of this possible fuck-up we should not permit the > feature that will be very useful for most people design by exception > 6- design by exception == bad This piece of code gets called by exception anyhow. It creates configuration changes that live longer than the MDB it created them for, and it has no way of knowing if the fix its trying to make is the right one or if its just messing things up more. 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. The admin mistake would be easy to notice at deployment time because there's a failed lookup. The developer mistake will be made more difficult to notice since the app can fail silently. > 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. > 8- ANYTHING THAT IS ADMIN FRIENDLY IS GOOD > > Oka? I admit I wear the developer hat more than the admin hat. But anything that makes it easier for me to find my own bugs saves my time and my nerves and someone else's money, and that is also good in my book. If I make a mistake, I'd rather know about it right away, and I'd rather not go clean up configuration files because of it. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMSContainerInvoker.java
|Its not redundant as there are many provider specific properties |that an admin |has to set: security, clustering, etc. You don't create database |connection pools |automatically because there are too many provider specific options that an |admin familiar with the database has to set. In general the same |is true with |JMS. Time out, I am not saying that this should be the ONLY way to do it, just that if you don't specify anything in jbossmq.xml we provide a default behavior. If you want to specify the name the security the clustering then *of course* you need to do it by hand. I will agree that my first point was maybe missleading on this. Now, if you don't specify anything in jbossmq.xml then the default kicks in, and we notify the user "Creating TOPIC", simple. If there is something specified and the stuff already exists in the naming space then *of course* you use that topic. Makes sense, Makes playing with MDBs simple. An MDB can create the Topic he is listening to at deployment time and delete it at undeployment... simple, why is it such an issue? marc | |> 1- If it is not there, right now we have to manually go and |create the damn |> thing, very redundant. |> 2- If you miss the spelling.. we should put a message saying "Creating |> topic" and that's it.. very convenient. |> 3- What is the big fuss about...? |> 4- You guys are designing by exception, i.e. "h but what happens if |> someone FUCKS up and mis-spells the topic. Well someone FUCKED |up... and we |> SAY "Creating Topic" so we give all the information, where is |the harm done? |> 5- You are saying, because of this possible fuck-up we should |not permit the |> feature that will be very useful for most people design by exception |> 6- design by exception == bad |> 7- Re: creating the topic, **uncreate** it at undeployment and basta! no |> more non-sense. |> 8- ANYTHING THAT IS ADMIN FRIENDLY IS GOOD |> |> Oka? |> |> but I am open to discussion and will stick by dug on this one... |I thought |> it was a good proposition and I still do. |> |> marc | | | |___ |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
Re: [JBoss-dev] JMSContainerInvoker.java
Its not redundant as there are many provider specific properties that an admin has to set: security, clustering, etc. You don't create database connection pools automatically because there are too many provider specific options that an admin familiar with the database has to set. In general the same is true with JMS. > 1- If it is not there, right now we have to manually go and create the damn > thing, very redundant. > 2- If you miss the spelling.. we should put a message saying "Creating > topic" and that's it.. very convenient. > 3- What is the big fuss about...? > 4- You guys are designing by exception, i.e. "h but what happens if > someone FUCKS up and mis-spells the topic. Well someone FUCKED up... and we > SAY "Creating Topic" so we give all the information, where is the harm done? > 5- You are saying, because of this possible fuck-up we should not permit the > feature that will be very useful for most people design by exception > 6- design by exception == bad > 7- Re: creating the topic, **uncreate** it at undeployment and basta! no > more non-sense. > 8- ANYTHING THAT IS ADMIN FRIENDLY IS GOOD > > Oka? > > but I am open to discussion and will stick by dug on this one... I thought > it was a good proposition and I still do. > > marc ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMSContainerInvoker.java
WTF... the create the MDB topic on deployment if not present? I think it is a kick ass feature... let me explain: 1- If it is not there, right now we have to manually go and create the damn thing, very redundant. 2- If you miss the spelling.. we should put a message saying "Creating topic" and that's it.. very convenient. 3- What is the big fuss about...? 4- You guys are designing by exception, i.e. "h but what happens if someone FUCKS up and mis-spells the topic. Well someone FUCKED up... and we SAY "Creating Topic" so we give all the information, where is the harm done? 5- You are saying, because of this possible fuck-up we should not permit the feature that will be very useful for most people design by exception 6- design by exception == bad 7- Re: creating the topic, **uncreate** it at undeployment and basta! no more non-sense. 8- ANYTHING THAT IS ADMIN FRIENDLY IS GOOD Oka? but I am open to discussion and will stick by dug on this one... I thought it was a good proposition and I still do. marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Juha |Lindfors |Sent: Friday, June 01, 2001 11:40 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] JMSContainerInvoker.java | | | |poo poo! | |;-D | |--Juha | |At 07:08 1.6.2001 -0700, you wrote: |>This is something that was suggested at the Atlanta training and Marc |liked so |>you need to slap him around. I was not particularly in favor of it and |that seems |>to be the general feeling so let's roll the change back. |> |>- Original Message - |>From: "Juha-P Lindfors" <[EMAIL PROTECTED]> |>To: <[EMAIL PROTECTED]> |>Sent: Friday, June 01, 2001 3:15 AM |>Subject: Re: [JBoss-dev] JMSContainerInvoker.java |> |> |> |> |>On Fri, 1 Jun 2001, Peter Antman wrote: |>> |>> You see what will happen? Yes, the client will send its messages to one |>> topic (no automatic creation here), and the MDB will listen on ANOTHER |>> topic, namely a to the system unknown destination, since it was not |>> correctly spelled. |>> |>> What do you other guys say on the list? Hiram? |> |>I agree with you it's not a good change. If the developer has made a |>mistake in his code or forgot to add the topic he should be warned during |>the deployment, instead of allowing the application to silently fail. |> |>Also, since the created topics are persistent, this requires the developer |>to go clean up the jbossmq configuration file from time to time to make |>sure resources aren't wasted on topics that never meant to be there in the |>first place. I think thats worse than the requirement of having to create |>the topic upfront, especially since the developer may not even be |aware he is |>accidentally creating new topics. |> |>So if the idea was to help the developer to avoid finding out about our |>obscure configuration files, I think this change may have made the problem |>even worse. Now you HAVE TO go browse them, just to fix your typos that |>won't go away. |> |>-- 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 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMSContainerInvoker.java
poo poo! ;-D --Juha At 07:08 1.6.2001 -0700, you wrote: >This is something that was suggested at the Atlanta training and Marc liked so >you need to slap him around. I was not particularly in favor of it and that seems >to be the general feeling so let's roll the change back. > >- Original Message - >From: "Juha-P Lindfors" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, June 01, 2001 3:15 AM >Subject: Re: [JBoss-dev] JMSContainerInvoker.java > > > > >On Fri, 1 Jun 2001, Peter Antman wrote: >> >> You see what will happen? Yes, the client will send its messages to one >> topic (no automatic creation here), and the MDB will listen on ANOTHER >> topic, namely a to the system unknown destination, since it was not >> correctly spelled. >> >> What do you other guys say on the list? Hiram? > >I agree with you it's not a good change. If the developer has made a >mistake in his code or forgot to add the topic he should be warned during >the deployment, instead of allowing the application to silently fail. > >Also, since the created topics are persistent, this requires the developer >to go clean up the jbossmq configuration file from time to time to make >sure resources aren't wasted on topics that never meant to be there in the >first place. I think thats worse than the requirement of having to create >the topic upfront, especially since the developer may not even be aware he is >accidentally creating new topics. > >So if the idea was to help the developer to avoid finding out about our >obscure configuration files, I think this change may have made the problem >even worse. Now you HAVE TO go browse them, just to fix your typos that >won't go away. > >-- 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
Re: [JBoss-dev] JMSContainerInvoker.java
This is something that was suggested at the Atlanta training and Marc liked so you need to slap him around. I was not particularly in favor of it and that seems to be the general feeling so let's roll the change back. - Original Message - From: "Juha-P Lindfors" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 01, 2001 3:15 AM Subject: Re: [JBoss-dev] JMSContainerInvoker.java On Fri, 1 Jun 2001, Peter Antman wrote: > > You see what will happen? Yes, the client will send its messages to one > topic (no automatic creation here), and the MDB will listen on ANOTHER > topic, namely a to the system unknown destination, since it was not > correctly spelled. > > What do you other guys say on the list? Hiram? I agree with you it's not a good change. If the developer has made a mistake in his code or forgot to add the topic he should be warned during the deployment, instead of allowing the application to silently fail. Also, since the created topics are persistent, this requires the developer to go clean up the jbossmq configuration file from time to time to make sure resources aren't wasted on topics that never meant to be there in the first place. I think thats worse than the requirement of having to create the topic upfront, especially since the developer may not even be aware he is accidentally creating new topics. So if the idea was to help the developer to avoid finding out about our obscure configuration files, I think this change may have made the problem even worse. Now you HAVE TO go browse them, just to fix your typos that won't go away. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMSContainerInvoker.java
On Fri, 1 Jun 2001, Peter Antman wrote:
>
> You see what will happen? Yes, the client will send its messages to one
> topic (no automatic creation here), and the MDB will listen on ANOTHER
> topic, namely a to the system unknown destination, since it was not
> correctly spelled.
>
> What do you other guys say on the list? Hiram?
I agree with you it's not a good change. If the developer has made a
mistake in his code or forgot to add the topic he should be warned during
the deployment, instead of allowing the application to silently fail.
Also, since the created topics are persistent, this requires the developer
to go clean up the jbossmq configuration file from time to time to make
sure resources aren't wasted on topics that never meant to be there in the
first place. I think thats worse than the requirement of having to create
the topic upfront, especially since the developer may not even be aware he is
accidentally creating new topics.
So if the idea was to help the developer to avoid finding out about our
obscure configuration files, I think this change may have made the problem
even worse. Now you HAVE TO go browse them, just to fix your typos that
won't go away.
-- Juha
>
> //Peter
>
> On 31 Maj, [EMAIL PROTECTED] wrote:
> > User: thedug
> > Date: 01/05/31 16:53:44
> >
> > Modified:src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
> > Log:
> > Add auto generation for topic/queue if topic/queue doesn't already exist.
> > Uses the mbean server to create a new topic/queue..
> >
> > Revision ChangesPath
> > 1.11 +54 -7
>jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
> >
> > Index: JMSContainerInvoker.java
> > ===
> > RCS file:
>/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v
> > retrieving revision 1.10
> > retrieving revision 1.11
> > diff -u -r1.10 -r1.11
> > --- JMSContainerInvoker.java 2001/05/07 19:19:57 1.10
> > +++ JMSContainerInvoker.java 2001/05/31 23:53:44 1.11
> > @@ -45,18 +45,24 @@
> >import org.jboss.jms.jndi.JMSProviderAdapter;
> >import org.jboss.jms.asf.ServerSessionPoolFactory;
> >
> > +import org.exolab.jms.client.JmsServerSessionPool;
> > +
> >import org.w3c.dom.Element;
> >
> > +import javax.management.MBeanServerFactory;
> > +import javax.management.MBeanServer;
> > +import javax.management.ObjectName;
> > +
> >/**
> > * ContainerInvoker for JMS MessageDrivenBeans, based on JRMPContainerInvoker.
> > *
> > - *
> > + *
> > * @see
> > * @author Peter Antman ([EMAIL PROTECTED])
> > * @author Rickard Öberg ([EMAIL PROTECTED])
> > * @author mailto:[EMAIL PROTECTED]";>Sebastien
>Alborini
> > * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
> > - * @version $Revision: 1.10 $
> > + * @version $Revision: 1.11 $
> > */
> >public class JMSContainerInvoker implements
> >ContainerInvoker, XmlLoadable
> > @@ -205,7 +211,24 @@
> >
> > // Set up pool
> > ServerSessionPoolFactory poolFactory =
>(ServerSessionPoolFactory)jbossContext.lookup(serverSessionPoolFactoryJNDI);
> > -
> > +
> > + // jndiSuffix is merely the name that the user has given the MDB.
> > + // since the jndi name contains the message type I have to split at the
>"/"
> > + // if there is no slash then I use the entire jndi name.
> > + String jndiSuffix = "";
> > + if(destinationJNDI != null){
> > +int indexOfSlash = destinationJNDI.indexOf("/");
> > +if(indexOfSlash != -1){
> > + jndiSuffix = destinationJNDI.substring(indexOfSlash+1);
> > +}else{
> > + jndiSuffix = destinationJNDI;
> > +}
> > +
> > +// if the jndi name from jboss.xml is null then lets use the ejbName
> > +}else{
> > +jndiSuffix = config.getEjbName();
> > +}
> > + MBeanServer server =
>(MBeanServer)MBeanServerFactory.findMBeanServer(null).iterator().next();
> >
> > if (destinationType.equals("javax.jms.Topic"))
> >{
> > @@ -230,7 +253,18 @@
> >}
> >
> >// Lookup destination
> > -Topic topic = (Topic)context.lookup(destinationJNDI);
> > + // First Try a lookup.
> > + // If that lookup fails then try to contact the MBeanServer and
>inoke a new...
> > + // Then do lookup again..
> > +String topicJndi = "topic/"+jndiSuffix;
> > +Topic topic;
> > +try{
> > + topic = (Topic)context.lookup(topicJndi);
> > +}catch(NamingException ne){
> > + Logger.log("JndiName not found:"+topicJndi + "...attempting
>to recover");
> > + server.invoke(new ObjectName("JMS","service","JMSServ
