OK, I think I fixed it. Thanks for the test case, I put it in the test suite.
david jencks On 2001.11.30 01:41:18 -0500 David Budworth wrote: > Ok, I did some research. > > On my machine (linux), I can't create a bad queue name to make it throw > an exception (all chars are valid in file names). > I had already nuked my validation code, so I'll have to test a bit more > to make queue creation fail. > > What I suspect is, when the new queue mbean fails to start (due to > validation errors), and the MBean is left around, that you can't destroy > the topic via Queue manager anymore (but that's a hunch). > > When I say fail on bad name, I mean when creating it via the JMX server > mbean on 8082. > > > But in what I did test, I found that > <mbean code="some.crashing.class" name="Domain:name=ThisCrashesAtStart"/> > and > <mbean code="some.noncrashing.class" name="Domain:name=ThisDoesntCrash"> > <mbean-ref>Domain:name=ThisCrashesAtStart<mbean-ref> > </mbean> > > > What will happen is you start the first one and, as expected, it > crashes. But since it's left in the JMX tree, you have satisfied MBean > #2 dependancy, so it starts. > > I think this is bad since #2 assumes #1 is a working MBean. > > Since start() is called automatically on and service mbean, I would > expect start() to be a requirement for deployment. And if it fails to > start, it fails to deploy. > > As it is now, you have a reference to a broken bean. > > Or am I totally missing the point of MBean refs in general? > > The way I look at the whole service mbeans + mbean refs is like unix > init scripts. > > I understand that if you programatically add a mbean, and it's start > fails you may want to attempt to fix it, and restart. > > But that idea doesn't make sense from the auto-deployer point of view. > No one is going to fix it on the fly (unless JBoss gets a new fancy code > generating AI engine in it) > > > I haven't tried this, but if you create an mbean from code, does it's > start() get called automatically?, or do you have to manually call > start() after you get back the ObjectInstance? > > If it's called automatically, and providing you can specify initial > attribute values when you create the mbean, then I don't see why you > shouldn't fail to attach the mbean to the JNDI tree on start() failure. > > Actually, I would expect: > 1) Create object instace > 2) bind to JMX tree (because maybe start tries to look itself up) > 3) call start > 4a) if start failed, remove from tree > 4b) if not, go poke all waiting mbeans for reference resoltion > > Keep in mind here, I haven't read the JMX spec, so if "bind it to the > tree" is not something that makes sense, or is something we have no > control of, then slap me with a fish. > > -David > > On Thu, 29 Nov 2001, David Jencks wrote: > > > On 2001.11.29 21:06:27 -0500 David Budworth wrote: > > > After taking a shot at implementing this, by way of making the > > > QueueManager and TopicManager's startService() function do the > > > validation and throw if it fails, I find that the MBean get's stuck > in > > > the JMX tree. > > > > > > Is this a MBeanServer bug? (where a bean doesn't go away when an > > > exception is thrown by start())? > > > > > > I've seen this before. So I think it is. But I don't want to commit > my > > > code just in case it's my bug. (since it requires a jboss restart to > > > make it go away). > > > > Looking harder at the code.... > > > > Does undeploy(objectName) really not work, and undeploying the package > that > > created the mbean doesn't work? What is the exception start throws? > > > > I'm reluctant to make a start() failure destroy the mbean, because not > all > > mbeans are created through ServiceDeployer and reading xml. > Furthermore > > mbeans can be started long after they are created... after dependencies > are > > resolved. The guy who created the mbean might want an opportunity to > fix > > the config if start fails. > > > > Do you have a little example? > > > > david jencks > > > > > > -David > > > > > > > > > On Thu, 29 Nov 2001, David Budworth wrote: > > > > > > > Ok, now that we have the ability to set the JNDI name on a > queue/topic, > > > > I would like to fix the bug (that I put in) in regards to deep > queue > > > > names. > > > > > > > > For simplicities sake, I'll just revert the file PM back to the way > it > > > > was. > > > > > > > > But, since there was (and will be when I revert) a bug there that > if > > > > you create a queue/topic with depth (ie: mycompany/queues/q1) > > > > > > > > The File PM will fail at next startup. > > > > > > > > So, I'd like to add some name validation. > > > > > > > > Is anyone uncomfortable if I enforce the queue names to be > > > alpha-numeric > > > > only? (via, Character.isLetterOrDigit()) > > > > JBoss (as it ships), doesn't define any topics/queues that would > > > violate > > > > that rule right now. > > > > > > > > Opinions? > > > > > > > > -David > > > > > > > > _______________________________________________ > > > > Jboss-development mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
