[prev in list] [next in list] [prev in thread] [next in thread]
List: barracuda
Subject: RE: [Barracuda] Barracuda and using Servlet 2.3 features?
From: "Christian Cryder" <christianc () granitepeaks ! com>
Date: 2003-04-16 16:53:32
[Download RAW message or body]
Ah, ok. My bad ;-)
----------------------------------------------
Christian Cryder [christianc@atmreports.com]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"
-----Original Message-----
From: barracuda-admin@barracudamvc.org
[mailto:barracuda-admin@barracudamvc.org]On Behalf Of Jacob Kjome
Sent: Wednesday, April 16, 2003 12:44 PM
To: barracuda@barracudamvc.org
Subject: RE: [Barracuda] Barracuda and using Servlet 2.3 features?
Hi Christian,
I didn't touch ObjectRepositoryAssembler, only
DefaultApplicationAssembler.
Jake
At 12:36 PM 4/16/2003 -0400, you wrote:
Hi Jake,
I haven't actually looked at the changes you've made, but I did want to
mention that I just committed a change to this class, before I realized
you
had been working in it. Shouldn't be a problem to integrate
though...just
search for csc_041603.2 and you'll see what I touched.
Basically, here's what I did...
--------------------------------
<b>csc_041603.2</b> - Added logic to ObjectRepositoryAssembler so that
you
can
get it to continue assembling a file even if errors are encountered.
This is
useful
because it allows your assembler file to specify things which may not
always
be there
(depending on your deploy configuration). Of course, if those things
aren't
there,
then subsequent assembly may not work either, so use with caution...
To take advantage of this functionality, you can either specify a
startup
parameter
in the GlobalRepositoryAssembler section of web.xml, like this:
<pre>
<init-param>
<param-name>LogHeartbeat</param-name>
<param-value>true</param-value>
</init-param>
<pre>
or, you can specify it within the object-repository.xml file itself,
like
this:
<pre>
<object
class="org.enhydra.barracuda.plankton.data.ObjectRepositoryAssembler">
<prop name="globalContinueOnErr">true</prop>
</object>
</pre>
or, you can specify it on a per-line item in object-repository.xml, like
this:
<pre>
<object name="$cts" class="com.atmr.kilimanjaro.CodeTables"
continue_on_err="true" />
</pre>
Note that the default remains false, so this should not affect any
existing
code
at all...you have to explicitly turn this behavior on if you want it.
----------------------------------------------
Christian Cryder [christianc@atmreports.com]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"
-----Original Message-----
From: barracuda-admin@barracudamvc.org
[mailto:barracuda-admin@barracudamvc.org]On Behalf Of Jacob Kjome
Sent: Wednesday, April 16, 2003 12:48 AM
To: barracuda@barracudamvc.org
Subject: Re: [Barracuda] Barracuda and using Servlet 2.3 features?
(see attached zip file for new DefaultApplicationAssembler to test out!)
Ok, I broke down and used reflection. Since people, thus far, are used
to
specifying a single application assembler file I figure that this is not
a
critical feature that mandates all of Barracuda moving to servlet 2.3.
If
we, however, decided that the event model would start using filters or
something like that, then that would be more of a reason to say that
Barracuda, as a whole, should require servlet 2.3.
So, those with servlet 2.2 engines must specify the whole relative
path+filename of the assembler file such as...
/WEB-INF/event-gateway.xml
Those with servlet 2.3+ engines may do any one of the following....
/WEB-INF/event-gateway.xml //load single file as named (same as
servlet
2.2 behavior)
/WEB-INF/assemblerFiles/ //load all files in assemblerFiles
directory ending with ".xml" (note the ending "/")
/WEB-INF/event //load all files in WEB-INF
directory starting with "event" and ending with ".xml"
/WEB-INF/event*way.xml //load all files in WEB-INF directory
starting with "event" and ending with "way.xml"
I wrote up some Javadoc that may or may not be totally
accurate/complete.
Someone (Christian?) might want to look at what I started and add to it
(once I check this into CVS or modify this version's javadoc and send it
back to me so I can check it in).
I also added some other functionality. One can now set the DOMFactiory
for
the DefaultDOMLoader via the assembler file. For instance....
<!-- sets default dom factory for the DefaultDOMLoader -->
<dom-loader
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
/>
and/or
<!-- registers specific dom factory for specific dom classes, leaving
the
default dom factory alone -->
<dom-loader>
<dom-loader-register
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.Navigatio
nHTML" />
<dom-loader-register
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.FileUploa
dHTML" />
<dom-loader-register
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.PrefixMap
pingHTML" />
<dom-loader-register
factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"
class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.Repopulat
ionHTML" /> -->
</dom-loader>
This is somewhat experimental, but I've tested it to work perfectly with
Diez' contrib app. Without this config, one has to set this in code
such
as...
DOMLoader domLoader = DefaultDOMLoader.getGlobalInstance();
DOMFactory domFactory = new XMLCDeferredParsingDOMFactory();
domLoader.registerDOMFactory(domFactory, NavigationHTML.class);
domLoader.registerDOMFactory(domFactory, FileUploadHTML.class);
domLoader.registerDOMFactory(domFactory,
PrefixMappingHTML.class);
domLoader.registerDOMFactory(domFactory,
RepopulationHTML.class);
Setting this in code makes one have to modify and recompile the code to
change the DOMFactory. Having this ability in the assembly descriptor
allows for easy changes without recompiling....although you'd have to
make
sure that you rebuild the XMLC classes with/without
"-for-deferred-parsing" because, currently the normal XMLCStdFactory is
unable to load dom classes compiled for deferred parsing (and
vice-versa).
I asked about this on the XMLC list and David Li provided two potential
solutions....
<quote name="David Li">
1. Implement the backward compatible document class generating. This
shouldn't be very hard but tedious. It requires merging the std class
generating codes with the deferred parsing generating codes.
2. Just forget about the existing of StdFactory and start thinking
Deferred
parsing as the only factory. ;)
</quote>
So, if #1 isn't implemented, then we might think about doing #2 by
making
the DefaultDOMFactory use XMLCDeferredParsingFactory rather than
XMLCStdFactory. Of course, this means using the flag
"-for-deferred-parsing" for all XMLC compilation in the Barracuda build
by
default. I'm not really pushing for this change in DefaultDOMFactory.
I'd
rather see #1 implemented, but the question is, who is going to do it?
Anyway, that's that. Try the attached DefaultApplicationAssembler out
if
you like. I'd like to get confirmation from someone using a servlet 2.2
engine that things work . It certainly works under my Tomcat-4.1.24.
I'll
check this in if I hear no complaints.
Jake
At 01:52 PM 4/15/2003 -0500, you wrote:
Jacob Kjome wrote:
Anyway, let me know how ready you are to move to requiring Servlet 2.3.
Maybe tag the current build as 2.2 compliant, and start a new branch
that
works with 2.3.
Iman
_______________________________________________
Barracuda mailing list
Barracuda@barracudamvc.org
http://barracudamvc.org/lists/listinfo/barracuda
_______________________________________________
Barracuda mailing list
Barracuda@barracudamvc.org
http://barracudamvc.org/lists/listinfo/barracuda
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=032245316-16042003><FONT face=Arial color=#0000ff size=2>Ah,
ok. My bad ;-)</FONT></SPAN></DIV>
<DIV> </DIV>
<P><FONT size=2>----------------------------------------------<BR>Christian
Cryder [christianc@atmreports.com]<BR>Internet Architect,
ATMReports.com<BR>Barracuda - <A href="http://barracudamvc.org/"
target=_blank>http://barracudamvc.org</A><BR>----------------------------------------------<BR>"Coffee? \
I could quit anytime, just not today" </FONT></P>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; \
MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT \
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
barracuda-admin@barracudamvc.org
[mailto:barracuda-admin@barracudamvc.org]<B>On Behalf Of </B>Jacob
Kjome<BR><B>Sent:</B> Wednesday, April 16, 2003 12:44 PM<BR><B>To:</B>
barracuda@barracudamvc.org<BR><B>Subject:</B> RE: [Barracuda] Barracuda and
using Servlet 2.3 features?<BR><BR></FONT></DIV><FONT size=3><BR>Hi
Christian,<BR><BR>I didn't touch ObjectRepositoryAssembler, only
DefaultApplicationAssembler.<BR><BR>Jake<BR><BR>At 12:36 PM 4/16/2003 -0400,
you wrote:<BR>
<BLOCKQUOTE class=cite cite="" type="cite">Hi Jake,<BR><BR>I haven't
actually looked at the changes you've made, but I did want to<BR>mention
that I just committed a change to this class, before I realized you<BR>had
been working in it. Shouldn't be a problem to integrate
though...just<BR>search for csc_041603.2 and you'll see what I
touched.<BR><BR>Basically, here's what I
did...<BR>--------------------------------<BR><b>csc_041603.2</b>
- Added logic to ObjectRepositoryAssembler so that you<BR>can<BR>get it to
continue assembling a file even if errors are encountered. This
is<BR>useful<BR>because it allows your assembler file to specify things
which may not always<BR>be there<BR>(depending on your deploy
configuration). Of course, if those things aren't<BR>there,<BR>then
subsequent assembly may not work either, so use with caution...<BR><BR>To
take advantage of this functionality, you can either specify a
startup<BR>parameter<BR>in the GlobalRepositoryAssembler section of web.xml,
like this:<BR><BR><pre><BR>
<init-param><BR>
<param-name>LogHeartbeat</param-name><BR>
<param-value>true</param-value><BR>
</init-param><BR><pre><BR><BR>or, you can specify it within the
object-repository.xml file itself,
like<BR>this:<BR><BR><pre><BR>
<object<BR>class="org.enhydra.barracuda.plankton.data.ObjectRepositoryAssembler"><BR> \
<prop name="globalContinueOnErr">true</prop><BR>
</object><BR></pre><BR><BR>or, you can specify it on a per-line
item in object-repository.xml,
like<BR>this:<BR><BR><pre><BR> <object name="$cts"
class="com.atmr.kilimanjaro.CodeTables"<BR>continue_on_err="true"
/><BR></pre><BR><BR>Note that the default remains false, so this
should not affect any existing<BR>code<BR>at all...you have to explicitly
turn this behavior on if you want
it.<BR><BR>----------------------------------------------<BR>Christian
Cryder [christianc@atmreports.com]<BR>Internet Architect,
ATMReports.com<BR>Barracuda - <A href="http://barracudamvc.org/"
eudora="autourl">http://barracudamvc.org</A><BR>----------------------------------------------<BR>"Coffee? \
I could quit anytime, just not today"<BR>-----Original Message-----<BR>From:
barracuda-admin@barracudamvc.org<BR>[<A
href="mailto:barracuda-admin@barracudamvc.org"
eudora="autourl">mailto:barracuda-admin@barracudamvc.org</A>]On Behalf Of
Jacob Kjome<BR>Sent: Wednesday, April 16, 2003 12:48 AM<BR>To:
barracuda@barracudamvc.org<BR>Subject: Re: [Barracuda] Barracuda and using
Servlet 2.3 features?<BR><BR><BR><BR>(see attached zip file for new
DefaultApplicationAssembler to test out!)<BR><BR>Ok, I broke down and used
reflection. Since people, thus far, are used to<BR>specifying a single
application assembler file I figure that this is not a<BR>critical feature
that mandates all of Barracuda moving to servlet 2.3. If<BR>we,
however, decided that the event model would start using filters
or<BR>something like that, then that would be more of a reason to say
that<BR>Barracuda, as a whole, should require servlet 2.3.<BR><BR>So, those
with servlet 2.2 engines must specify the whole relative<BR>path+filename of
the assembler file such as...<BR><BR>/WEB-INF/event-gateway.xml<BR><BR>Those
with servlet 2.3+ engines may do any one of the
following....<BR><BR>/WEB-INF/event-gateway.xml
//load single file as named (same as servlet<BR>2.2
behavior)<BR>/WEB-INF/assemblerFiles/ \
//load all files in assemblerFiles<BR>directory ending with ".xml" (note the
ending
"/")<BR>/WEB-INF/event \
\
//load all files in WEB-INF<BR>directory starting with "event" and ending
with
".xml"<BR>/WEB-INF/event*way.xml \
//load all files in WEB-INF directory<BR>starting with "event" and ending
with "way.xml"<BR><BR>I wrote up some Javadoc that may or may not be totally
accurate/complete.<BR>Someone (Christian?) might want to look at what I
started and add to it<BR>(once I check this into CVS or modify this
version's javadoc and send it<BR>back to me so I can check it in).<BR><BR>I
also added some other functionality. One can now set the DOMFactiory
for<BR>the DefaultDOMLoader via the assembler file. For
instance....<BR><BR><!-- sets default dom factory for the
DefaultDOMLoader
--><BR><dom-loader<BR>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferredParsingDOMFactory"<BR>/><BR><BR>and/or<BR><BR><!-- \
registers specific dom factory for specific dom classes, leaving
the<BR>default dom factory alone
--><BR><dom-loader><BR>
<dom-loader-register<BR>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferr \
edParsingDOMFactory"<BR>class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.Navigatio<BR>nHTML" \
/><BR>
<dom-loader-register<BR>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferr \
edParsingDOMFactory"<BR>class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.FileUploa<BR>dHTML" \
/><BR>
<dom-loader-register<BR>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferr \
edParsingDOMFactory"<BR>class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.PrefixMap<BR>pingHTML" \
/><BR>
<dom-loader-register<BR>factory="org.enhydra.barracuda.core.util.dom.XMLCDeferr \
edParsingDOMFactory"<BR>class="org.enhydra.barracuda.contrib.dbroggisch.examples.view.xmlc.Repopulat<BR>ionHTML" \
/> --><BR></dom-loader><BR><BR>This is somewhat experimental,
but I've tested it to work perfectly with<BR>Diez' contrib app.
Without this config, one has to set this in code
such<BR>as...<BR><BR> DOMLoader
domLoader =
DefaultDOMLoader.getGlobalInstance();<BR> \
DOMFactory domFactory = new
XMLCDeferredParsingDOMFactory();<BR>
domLoader.registerDOMFactory(domFactory,
NavigationHTML.class);<BR>
domLoader.registerDOMFactory(domFactory,
FileUploadHTML.class);<BR>
domLoader.registerDOMFactory(domFactory,
PrefixMappingHTML.class);<BR>
domLoader.registerDOMFactory(domFactory,
RepopulationHTML.class);<BR><BR>Setting this in code makes one have to
modify and recompile the code to<BR>change the DOMFactory. Having this
ability in the assembly descriptor<BR>allows for easy changes without
recompiling....although you'd have to make<BR>sure that you rebuild the XMLC
classes with/without<BR>"-for-deferred-parsing" because, currently the
normal XMLCStdFactory is<BR>unable to load dom classes compiled for deferred
parsing (and vice-versa).<BR>I asked about this on the XMLC list and David
Li provided two potential<BR>solutions....<BR><BR><quote name="David
Li"><BR>1. Implement the backward compatible document class generating.
This<BR>shouldn't be very hard but tedious. It requires merging the std
class<BR>generating codes with the deferred parsing generating
codes.<BR><BR>2. Just forget about the existing of StdFactory and start
thinking Deferred<BR>parsing as the only factory.
;)<BR></quote><BR><BR>So, if #1 isn't implemented, then we might think
about doing #2 by making<BR>the DefaultDOMFactory use
XMLCDeferredParsingFactory rather than<BR>XMLCStdFactory. Of course,
this means using the flag<BR>"-for-deferred-parsing" for all XMLC
compilation in the Barracuda build by<BR>default. I'm not really
pushing for this change in DefaultDOMFactory. I'd<BR>rather see #1
implemented, but the question is, who is going to do it?<BR><BR>Anyway,
that's that. Try the attached DefaultApplicationAssembler out
if<BR>you like. I'd like to get confirmation from someone using a
servlet 2.2<BR>engine that things work . It certainly works under my
Tomcat-4.1.24. I'll<BR>check this in if I hear no
complaints.<BR><BR>Jake<BR><BR>At 01:52 PM 4/15/2003 -0500, you
wrote:<BR><BR>Jacob Kjome wrote:<BR><BR>Anyway, let me know how ready you
are to move to requiring Servlet 2.3.<BR><BR>Maybe tag the current build as
2.2 compliant, and start a new branch that<BR>works with
2.3.<BR><BR>Iman<BR><BR>_______________________________________________<BR>Barracuda \
mailing list<BR>Barracuda@barracudamvc.org<BR><A
href="http://barracudamvc.org/lists/listinfo/barracuda"
eudora="autourl">http://barracudamvc.org/lists/listinfo/barracuda</A><BR><BR>_______________________________________________<BR>Barracuda \
mailing list<BR>Barracuda@barracudamvc.org<BR><A
href="http://barracudamvc.org/lists/listinfo/barracuda"
eudora="autourl">http://barracudamvc.org/lists/listinfo/barracuda</A></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic