On Aug 24, 2012, at 2:27 AM, Bjorn Danielsson wrote: > David Blevins <david.blev...@gmail.com> wrote: >> [Please respond inline and don't top-post or the thread will be unreadable. >> Just trim the email down to the parts that pertain to the response and >> respond >> below the part] >> >> ## Configuration >> >> [Nested XML vs property-name prefixes] >> >> Both would actually function. User preference would dictate which is used. >> >> Thoughts? Given the choice, which would you use? See any third options >> that >> might be cooler? > > I would most likely use the second format. I grep config files all the time.
Great point. >> AppContext, ModuleContext, and BeanContext would each get a >> `<Configuration>` >> bucket. There might be a better name than `<Configuration>`. Maybe >> `<Properties>` or perhaps even better, `<Options>` ? > > I prefer <Properties> for the simple reason that it reinforces the idea that > the syntax is that of a Java properties file (with XML escapes, nota bene). Three voices for <Properties> so far. (love getting feedback) >> ## EJB vs Pojo >> >> - Let people use BeanContext anyway >> - Make a new element > > I believe having different elements here is probably a good idea, to avoid > blurring the distinction between EJBs and POJOs. Starting to lean that way too. >> Ideas on something better? Better names maybe? Perhaps `<PojoContext>` for >> consistency. Perhaps get really basic and `<ClassContext>` ? > > Or maybe <ManagedObjectContext> ? > Otherwise I think I prefer <PojoContext> over <ClassContext>. Maybe even <ManagedObject>? >> ## Standalone apps vs apps with many modules >> >> Or perhaps we want an entirely different root element for standalone apps? > > How about <WebAppContext> for the standalone? > I think that name is intuitive for the standalone WAR case. That might be smart. There's sort of an open ended question in this regard. Some settings only work on the "application" level and not the "module" level. A prime example is the AsynchronousPool config. We create one AsynchronousPool for the whole application. The fact that a "module" can also be the entire application really messes with config. Specifically, using official JavaEE terms: - a .war file deployed by itself, no ear file, is called a "Standalone Application". Same goes for an EJB jar deployed by itself. - that same war file deployed in an .ear is then just a module. So the question is what should we allow people to get away with in terms of config? For a war deployed as standalone application, should you be allowed to set AsynchronousPool properties in <WebAppContext>/<Properties>? If yes: - If that same .war file is deployed with another .war file in an ear and both war files attempt to set AsynchronousPool properties in <WebAppContext>/<Properties>, what would be the outcome? If no: - Then there must theoretically be some clearly marked "Application" level configuration element or section where the user must set AsynchronousPool properties. sub-issue: what happens if the user combines this war in an ear and deploys it? what is the outcome of N modules having potentially conflicting "application" config? You sort of come back to the same issue either way. There seem to be only two (maybe three) possible outcomes what is essentially the same problem: - Ignore or error. Moving a standalone war into an ear would cause any application-level config to be invalid. The result would be to ignore it or fail the deployment. - Merge the application level configs and try to make it work. Ignore or fail on conflicts. - Internally, don't have application-level config and allow everything to be done at the module-level. If you don't want two AsynchronousPools when you combine two wars together, you need to take care and clean that up. Not entirely sure that last option will be possible all the time and it does sort of mess up the property inheritance we have. If you specify "-DAsynchronousPool.CorePoolSize=10" at boot or in conf/system.properties that sets the default for all applications unless they explicitly set "AsynchronousPool.CorePoolSize=3" or something in the application.properties or this new config file. Would really love some thoughts. -David
