0 Replies Latest reply on Jul 18, 2006 10:56 AM by Scott Stark

    Moving to a POJO configuration API

    Scott Stark Master

      We have been discussing updating tomcat6 to support the POJO style configuration that is needed for effective integration with the jboss5/mc based kernel. Let's use this thread for the status/discussion. As of now its still just an idea:

      "scott.stark@jboss.org" wrote:

      > For now all I can say is that the parsing of the xml needs to produce
      > javabean metadata for which there is an api to configure both the
      > embedded tomcat instance as well as deployments. There should be no
      > feature of tomcmat we cannot set via a javabean api that does not
      > involve jmx or xml. Hopefully Bill can get the javaee5 injection stuff
      > done this week and then I can start working on porting this over to
      > the mc. Let's revisit this issue in a couple of weeks when I can state
      > where the configuration needs work.

      "mladen" wrote:

      OK. I already posted a mail on the Tomcat-dev to make something like that possible. So far I see no one objects to the proposal.
      Well, Remy is on the vacation :)

      So, I'll do my best to split the Tomcat6 to catalina-core.jar without JMX/SAX and cantalina.jar with the current API on top of catalina-core.jar

      Feel free to contact me for any problem.
      Seems we don't need a talk today then.

      Here the message thread about the subject from today:

      Yoav Shapira wrote:
      >> 3. What do you think that we split the Tomcat core
      >> from its configuration?
      >> The reason of the usage is very simple. First of all
      >> that additional package would be file system independent.
      >> It simply means that we would have a Tomcat with POJO
      >> API only, on top we could have any vitual-file-system
      >> abstraction there is. It can be a simple File, or as
      >> complex as email message.
      > Intriguing idea that I think is worth exploring further.

      I think this would give us a completely new POV.
      From the final product of view it would change nothing, but it would allow the embedder to provide the config from what ever content.

      The major thing is that we change the perspective from the configuration-centric to the application-centric, where the configuration would be requested, not provided.

      All that can be IMHO done in a very simple way, simply splitting the core from the SAX/JMX. Of course that split might introduce few extra cycles because of intermediate API, but who cares if the server will take 1 microsecond more to load?

      So, if we can do a catalina.jar on top of the catalina-core.jar one could use catalina-core without depending on the file system or JMX, without breaking anything.