Why not create an MBean with this information? Or another EJB that holds application configuration information?
Besides this, JBoss 3.x has the concept of pluggable deployers. The deployer's job is to read xml files and register and startup the component in jboss. We have deployers for EJBs, WARS, EARS, and SARs(MBeans) and in 4.0 AOPs. There's no reason you couldn't write a specialized EJB deployer that got configuration information from a database. Of course this would be proprietary. Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Guy > Rouillier > Sent: Tuesday, February 18, 2003 11:10 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Is 4.0 new or evolution of 3.2? > > > Bill, thank you for taking the time to explain in depth the major > architectural changes for 4.0. This would be great material for a white > paper. I'm very interested in the changes you are making regarding > configuration changes. One significant annoyance (with the spec, not > JBoss) is the bundling of the deployment descriptors with EJB executable > code (remember we are still using 2.4.3.) For example, our trouble > ticketing was not really designed for ticket creation via APIs, so we > have to invoke a URL to create tickets (http post.) Each platform (dev, > test, prod) has a different server and port to connect to. I've wrapped > the trouble ticket functionality in an EJB, and put the server and port > values into env values in the deployment descriptor. I don't want our > ops people to have to know about the workings of EJBs - our promotion > process consists solely of moving files around. So I've had to create 3 > different instances of the JARs for this EJB, and put them into separate > directories for each platform. This process would be greatly simplified > if configuration values were stored externally to the EJB jars, for > example if the EJB could ask the container for these values. Will the > changes you are making for 4.0 configuration address this issue? > Personally, I think the deployment descriptor design is flawed. > > ----- Original Message ----- > From: "Bill Burke" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, February 18, 2003 5:31 PM > Subject: RE: [JBoss-user] Is 4.0 new or evolution of 3.2? > > > > In 4.0 we will be finalizing JMX as our lightweight component model. > One of > > the problems with the 3.x series though is that cool features like > client > > and server side interceptors and detached Invokers (aka pluggable > > transports) were written around EJBs and the EJB container. In 4.0, > we want > > to generalize interceptor technology and detached invocations so that > any > > type of object or any plain old Java Class can leverage these > technologies. > > We want to bring J2EE services transparently and implicitly to plain > old > > java objects and classes and truly isolate business logic from > > infrastructure. > > > > Another thing that we really want to change is how components get > configured > > and how JBoss components locate their configurations. We want to > enable app > > developers at runtime to be able to change a configuration setting at > > runtime for only the duration of an invocation. For example, let's > say for > > a particular finder call, you want the result set page size to be 100 > when > > the default is 1000. We would provide generic APIs for you to do > this. > > Also, we want the ability to define default configurations > cluster-wide, > > JVM-wide, and application-wide. The way we'll implement this is what > I like > > to call MetaData Repository Chains. IMHO, this new architecture for > > configuration will allow JBoss to be a truly dynamically configurable > > application server. > > > > Yet another thing we want to be able to do is ease the burden of ISVs > and > > tool integrators that want to plug-in and extend JBoss with their > > proprietary technologies. In 3.0, client and server side interceptors > were > > a great start for this. 4.0 will bring in the Metadata Repository > Chains > > that I just talked about to ease configuration. What you'll also be > able to > > do is to define and plug-in proprietary APIs that you want your > MBeans, > > EJBs, plain java classes, all through configuration. For example, > let's say > > Gemstone, our distributed caching partner, wants to extend EJBs with a > > proprietary API. They'll be able to do this just by hot-deploying a > new > > component and in your application code you'll be able to typecast the > > component to the new API. > > > > MyEJB ejb = ...; > > GemstoneCachedObject cached = (GemstoneCachedObject)ejb; > > cached.flushCache(); > > > > So the goals of 4.0 are as follows: > > 1. Finalize JMX as our lightweight component model > > 2. Bring J2EE services to plain old java classes through our AOP > framework > > 3. Generalize configuration through MetaData Repository Chains > > 4. Make it even easier to integrate and extend JBoss. > > > > Ok, that the generalized vision for JBoss 4.0. I'm sure each lead > developer > > of each JBoss subproject will want to give you other reasons why we're > > re-architecting other parts of JBoss. > > > > Best regards, > > XXXXXXXXXXXXXXXX > > Bill Burke > > Chief Architect > > JBoss Group, LLC > > XXXXXXXXXXXXXXXX > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Guy > > > Rouillier > > > Sent: Tuesday, February 18, 2003 12:27 PM > > > To: JBoss User > > > Subject: [JBoss-user] Is 4.0 new or evolution of 3.2? > > > > > > > > > I skipped over a recent email proclaiming 4.0 to be a ground-up > > > rearchitecture for the 21st century (or some such fluff.) I just > > > deleted it at the time, but last night it got me to thinking. I'm > the > > > lead architect at our small telecom startup, and I introduced JBoss > > > there. We are still on 2.4.3 because, well, it has done what we > need. > > > But I've been looking at an upgrade to 3.2 to meet some new > > > requirements. Not trying to be provocative, but 3.0 was a complete > > > rearchitecture that was supposed to position the code base for > future > > > needs. So finally my question. Is 4.0 really another complete > > > rearchitecture, or is it an evolution of 3.2? If it is completely > new, > > > why? Were there things not foreseen in the 3.0 redesign? I'm just > > > wondering when and where I should plan an upgrade of our > infrastructure. > > > Thanks. > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > JBoss-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
