-----Original Message-----
From: tek1 [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 3:12 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Code for auto-generating CUSTOM castor mapping
files
1)
>it is possible with xdoclet to generate a mapping with no @tags in the
>source, if you write the module as such.
Ignorant question: I only found info talking about @tags. How do I setup xdoclet to work without such tags (I just need some simple examples)?
2)
>however, with no @tags in the source, there is no way for the generator to
>know which fields should have which attributes (i.e. which fields should be
>NOT NULL and which can allow nulls)
As of now, this issue is of no concern to me. I might have some trouble with it in the future but it is a very small concern compared to what I'm currently facing.
3)
>also, without the @tags, there is no way to
>have database table and table field names that are different from the class
>and class's fields.
Again, this isn't currently a concern of mine. And again, if and when it becomes an issue, I see workarounds on it being much less painful than the current problem.
4)
>in other words, java itself needs to be able to describe *everything* that
>needs to appear in the mapping.xml file. that is not possible and thus the
>raison d'etre for xdoclet.
Now you lost me. I read statement 1) as "What you want to do is currently possible with xdoclet" and statement 4) as "What you want to do is impossible". I know Castor itself will generate mappings if you don't provide them, BUT this solution WILL NOT work for me as Castor utilizes a rather simple heuristic (which my codebase will grievously break).
Does xdoclet intelligently parse classes without the use of @tag metadata? Can it determine the serializable fields, getters and setters for those fields (again without metadata)?
Also, one other member (replying to this thread) seemed to indicate xdoclets castor mapping abilities were "broken". I'd like some more info on what exactly was "broken" and what version we are talking about.
FYI: I also submitted a "longshot" RFE to Sun on Java. Basically I'd like some way of asking the compiler (or something using code common to the compiler) for details on a class. The way I see it the java compiler is going to be the "best" solution for parsing .java classes (it already has to do that, it already needs to know more than anything else, it is also more used and tested than any other component). Likewise it will have all the info neatly packed away in datastructures (albeit native ones, but what I want is a java layer API to this). There are MANY uses for such a capability (and it could become a powerful feature of the language), not just aiding in intelligent serialization on the fly.... If you'd like to see this capability too look in a few weeks for the RFE (if they post it) and vote for it.
