Re: [LONG TERM PLAN] ProposedArchitectureforTomcat.NextServletContainer

[James Todd <jw...@pacbell.net>]

cool. straight forward enough.

much appreciated,

- james

Assaf Arkin wrote:

> Unless you specify a mapping (i.e. MarshalInfo), the marshaller will
> look for a setFoo and if it cannot find one will look for an addFoo :-)
>
> You can override it to look at either one and not the other.
>
> When it generates Java sources from XML Schema it will create a
> setFoo/getFoo for a scalar and an addFoo/getFoo/listFoo (enumeration)
> for a vector.
>
> arkin
>
> James Todd wrote:
> >
> > !much appreciated!
> >
> > available code should be enough docs for me.
> >
> > one item i was pondering is when to determine to call a "setFoo" vs
> > an "addFoo" in the first case the value is a scalar whereas in the later
> > it is a vector/list. does your marshalizer handle lists?
> >
> > thx much,
> >
> > - james
> >
> > Assaf Arkin wrote:
> >
> > > > can you share more info on this? i'm doing pretty much the same thing
> > > > but haven't had time to make the xml to/from java as clean as i'd like.
> > > > i know it can be done and have some thoughts in mind but i'd love to
> > > > hear some thoughts from those that have been there/done that.
> > > >
> > > > i'll take whatever you can offer; class sigs, ascii diags, methodologies,
> > > > api's, patterns, etc. if others aren't interested in this please feel free to
> > >
> > > I can do better than that. I can give you a working implementation,
> > > fully open source.
> > >
> > > Go to http://castor.exolab.org, download the latest release (0.6). You
> > > will also need ftp://ftp.exolab.org/pub/jars/xerces.jar since it depends
> > > on the serializer API found there. Xerces and ProjectX can coexist in
> > > the same classpath, and I'm happily running Tomcat with both.
> > >
> > > The two most interesting classes there are
> > > org.exolab.castor.xml.Marshaller (Java -> XML) and
> > > org.exolab.castor.xml.Unmarshaller (XML -> Java). You don't need much
> > > documentation to get them up running :-)
> > >
> > > The trivial Java - XML mapping is done automatically for you by the
> > > framework, e.g. an element called server will map to a class called
> > > Server, an attribute called sql-name will map to getSqlName/setSqlName
> > > methods.
> > >
> > > The non trivial mapping (e.g. different naming, mapping based on class
> > > name attribute, element/attribute switches, etc) relies on MarshalInfo
> > > descriptors (modeled after the JavaBean descriptors). There's an XML
> > > Schema -> Java source code generator that can do most of the work for
> > > you.
> > >
> > > Unfortunately, documentation is a bit lacking at this point, so I
> > > suggest you fire an email directly to Keith (kvisco@exoffice.com) for
> > > any question you have.
> > >
> > > If you're looking for sample code for the non-trivial examples I've
> > > described, download the Tyrex sources from tyrex.exolab.org and look in
> > > the directory src/main/tyrex/conf. There's enough samples in there to
> > > cover all the bases :-)
> > >
> > > If anyone is willing to help with documentations and sample code, that
> > > would be greatly appreciated.
> > >
> > > arkin
> > >
> > > >
> > > > fire me a private message. this specific is near'n dear to me at the
> > > > moment as i've got to get our infrastructure fleshed out so that it is
> > > > trivial to add in new java/xml tuples.
> > > >
> > > > at this time i'm using:
> > > >
> > > >     jdk 1.2.2
> > > >     tomcat: http server, servlet engine
> > > >     project-x: xml parser
> > > >
> > > > thx much,
> > > >
> > > > - james
> > > >
> > > > >
> > > > >
> > > > > In the Tyrex configuration file I have some non trivial cases, e.g. I
> > > > > need to map an element to an object type specified in one of the
> > > > > object's attribute. The element maps to a generic DataSource interface,
> > > > > but the actual object created and configured is an implementation of
> > > > > this interface that can have any arbitrary set of properties that can't
> > > > > be expressed in a fixed DTD. Works like a charm.
> > > > >
> > > > > I also get to map the same object to two different element types, where
> > > > > the DTD (element name and attribute list differ) but the same
> > > > > implementation can be used in both cases. Also works like a charm.
> > > > >
> > > > > And in case we get too generic, a portion of the file can always be
> > > > > delegated as SAX events to some consumer, which we're using for the DSML
> > > > > portions that are handled by a direct DSML->LDAP mapping.
> > > > >
> > > > > arkin
> > > > >
> > > > > > --
> > > > > > Stefano Mazzocchi      One must still have chaos in oneself to be
> > > > > >                           able to give birth to a dancing star.
> > > > > > <st...@apache.org>                             Friedrich Nietzsche
> > > > > > --------------------------------------------------------------------
> > > > > >  Come to the first official Apache Software Foundation Conference!
> > > > > > ------------------------- http://ApacheCon.Com ---------------------
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org