(changing the subject since it's not related to the patch)
On Fri, 15 Aug 2003, Chris Opacki wrote:
> Hi Aaron,
> I've been working on the DDBean and the class that
> loads them. In the spec examples it shows that a
> DDBean is grabbing data directly from the xml
> document. I was thinking that i would load the DDBeans
> from elsewhere holding the required data in the
> DDBeanImpl.
I'm not sure what you mean by that last sentence. Can you
elaborate?
> I am creating one DDBean implementation,
> one DDBeanRoot implementation and a Loader that is
> responsible for parsing a zip file, reading an entry
> and writing it to a temp file.
What zip file and temp file are you referring to? Let's start by
assuming we're just going to work with EJB JARs (we'll worry about EARs
later). Then you don't need any special temp files or anything -- just
create a new JarFile, get the Entry for META-INF/ejb-jar.xml, get the
InputStream for that, and load it.
Someone has already set up the infrastructure required to have
Castor generate object to read and write XML from an InputStream. We just
need to add something to the build to generate objects for the ejb-jar.dtd
(or maybe make a Schema out of it if we need to), and you could
practically load a set of objects representing the DD in one line. Of
course, for these purposes, it may be better to load a DOM rather than an
object tree (for resolving XPaths and so on), but that should still be
pretty straightforward. Do you have thoughts on how exactly you want to
read the XML?
Now when you say "one DDBean implementation", do you mean there
will be one generic DDBean class that can represent any element, or do you
mean you're just starting with a DDBean for "enterprise-beans" or
something?
> I am also assuming that
> we will grab child dd beans based on a relative path
> from root. I'm not sure if you have started that
> DDConfigBean implementations yet, but I thought it
> would be good that you know what I am doing.
I'd have to look -- I thought maybe you could do either absolute
or relative paths, but I need to check to confirm that.
> Is anyone
> else actively working on JSR88? There haven't been a
> whole lot of activity on our threads. Any thoughts?
Well, Maas contributed the original API implementation, but seems
to have moved on to 77 and elsewhere. A number of other seemed to be
interested on working on the UI, so we should probably give them a chance
to speak up too. As far as I know, I'm the only one working on the server
provider side for now.
Aaron
