The JBoss DTDs are no longer online at "http://www.jboss.org/j2ee/dtd/XXXXX.dtd"; and this causes an exception at deploy time on JBoss 3.0RC3
It seems like JBossSubTask.java needs a dtdDirectory property to set the location of the DTDs. If no one has started to work on this already I can do it... Just say go. Philippe On July 9, 2002 12:04, Konstantin Priblouda wrote: > --- Aslak_Hellesoy <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > > > From: Konstantin Priblouda > > > > [mailto:[EMAIL PROTECTED]] > > > > > Sent: 9. juli 2002 11:22 > > > To: Aslak_Hellesoy > > > Subject: RE: [Xdoclet-devel] xtags DTD > > > > > > > > Yeah, I spotted that one (tag-param), but I > > > > don't > > > > > > think that'll do it; > > > > > > > > > it's a config parameter I need to test, not a > > > > tag > > > > > > parameter i.e. if > > > > > > > > > ejbspec = 1.1 use one optionset, if ejbspec >= > > > > 2.0 > > > > > > use the other. Of > > > > > > > > > course, that means xdocletgui would need > > > > somewhere > > > > > > to specify the ejbspec > > > > > > > > > version you want to use (I don't know if it > > > > does > > > > > > or not, I've not looked > > > > > > > > > at it much yet), and I have a suspicion it'll > > > > need > > > > > > changes to the DTD. > > > > > > > > > > > > We might have to redesign the condition > > > > mini-framework. It's centered around > > > > XProgramElement now. -Evaluating whether a > > > > condition > > > > > > holds for a given > > > > XProgramElement (superinterface of XClass, > > > > XMethod > > > > > > etc.). > > > > > > > > It seems obvious that we'll have to evaluate > > > > conditions based on other > > > > factors, like the one you mention here. Here are > > > > some suggestions: > > > > > > > > 1) > > xtags.condition.Condition.eval(xjavadoc.XProgramElement) > > > > > can be > > > > refactored to > > > > xtags.condition.Condition.eval(java.lang.Object). > > > > > > The > > > > consequence of this would be a more flexible > > > > evaluation system. Each > > > > Condition subclass can cast the argument to an > > > > expected class and perform > > > > the evaluation. In the config parameter > > > > scenario, it > > > > > > could be cast to e.g. > > > > xdoclet.ConfigParameter or perhaps some Version > > > > class we want to define. The > > > > drawback is typeunsafeness. The advantage is > > > > minaimal API changes. > > > > > > > > 2) > > xtags.condition.Condition.eval(xjavadoc.XProgramElement) > > > > > can be > > > > refactored to xtags.condition.Condition.eval() > > > > (no > > > > > > argumanets). This would > > > > require various setters to be called prior to > > > > validation. If we go for this > > > > approach, we can make an > > > > XProgramElementCondition > > > > > > class that defines the > > > > setProgramElement(xjavadoc.XProgramElement). A > > > > parallel class hierarchy > > > > could be made for config parameters and other > > > > things. I like this approach > > > > better, because it's more typesafe. > > > > > > > > Whatever approach we choose, nothing prevents us > > > > from modifying the DTD now. > > > > Currently, we're using the DTD merely to > > > > validate > > > > > > the xtags.xml which in > > > > turn is currently mostly used for HTML doc > > > > generation. > > > > > > > > I suggest you modify the xtags.dtd to add a new > > > > condition type > > > > (config-param) in the condition ATTLIST. Then we > > > > can > > > > > > worry about > > > > implementation details later, when the > > > > much-talked-about xtags start to > > > > emerge. > > > > > > I do not think that we have to modify condition > > > framework a lot. Nothing prevents us to add > > > > condition > > > > > which tests parameters passed on xdoclet > > > > invocation. > > > > > It may still get XProgramElement - there is no > > > problem. > > > > > > I started work to move xtags into xdoclet core > > > ( if there are no objections ) and add support > > > for them in module loading stuff. > > > ( clearly module has to provide own xtags on > > > > demand... > > > > > ) > > > > I think we should discuss this with Ara first. And > > no new stuff in XDoclet > > now please. We have a release coming up you know ;-) > > Yes, of course. I'm just playing around with ideas how > to integrate it. I plan to make GUI module-aware, > with possibility to choose which modules we cover. > > ( no need to bomb user with all the tags he/she may > never need for his application ) > > To achieve this, GUI has to use module loader, > and module has to be able to spit out tag families > it uses... > > regards, > > ===== > Konstantin Priblouda ( ko5tik ) Freelance Software developer > < http://www.pribluda.de > < play java games -> http://www.yook.de > > < render charts online -> http://www.pribluda.de/povray/ > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Stuff, things, and much much more. > http://thinkgeek.com/sf > _______________________________________________ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
