Re: Re: Re: Re: Using XMLC 2.3.2 L10n/I18n in Barracuda apps (looking for comments)

This is a multi-part message in MIME format...

------------=_1287579638-30467-6256
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

hs_err log file gives me a bit of extra info :

Current CompileTask:
C2:873      jregex.Pretokenizer.next()V (1064 bytes)



Le mercredi 20 octobre 2010 =C3=A0 12:54 +0200, Franck Routier a =C3=A9cr=
it :
> Jake,
>=20
> I just tried to test what you commited, but as soon as I build, I come
> into a bug affecting at least my environment: the jvm will SIGSEGV
> when...
>=20
>      [l10n] Generating localized templates in...
>      [l10n] /home/franck/devel/workspace/BarracudaMVC/WEB-INF/tmp
> $/src_xmlc/org/barracudamvc/tutorials/xmlc
>      [l10n] HelloWorld4_sv.html
>      [l10n] HelloWorld4_pt.html
>      [l10n] HelloWorld4_fr.html
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=3D0x00007fd81b820b90, pid=3D5026, tid=3D14056485=
4421264
>=20
> My JVM is OpenJDK 64-Bit Server VM (17.0-b16 mixed mode linux-amd64).
>=20
> I'm going to try with another JVM and to narrow down the source of the
> problem... I'll keep you informed.
>=20
> Franck=20
>=20
>=20
>=20
>=20
> Le vendredi 15 octobre 2010 =C3=A0 00:42 -0600, Jacob Kjome a =C3=A9cri=
t :
> > Hi Franck,
> >=20
> > See comments inline below.  Also note that I committed the changes.  =
Please update
> > and try things out.
> >=20
> > On 10/14/2010 4:43 AM, Franck Routier wrote:
> > > Hi Jake,
> > >=20
> > > first of all thank for having done this work.
> > >=20
> >=20
> > No problem.  I've been meaning to get this in for a while, just didn'=
t have the time.
> >=20
> > >>
> > >> So, while DOMFactory.getInstance(Class) suffices for Barracuda, it=
 does not for
> > >> XMLC.  We need the Locale as the second argument.  But that would =
change the
> > >> interface, which might not be so bad.  But then we'd have essentia=
lly the same
> > >> interfaces for both DOMLoader and DOMFactory, which just seems wro=
ng.
> > >>
> > > Well, abstracting the DOMLoader at least give the option to swith
> > > DOMFactory and document parser if needed. But it might well be a fa=
lse
> > > sense of "security". Until now, the only alternative has been Xmlc =
or
> > > Jivan. I don't think Jivan is supported in any way (in fact the sit=
e is
> > > down). As far as I can tell, it was suffuring from limitations anyw=
ay
> > > and not all Barracuda possibilities were supported (cannot remeber =
what
> > > exactly, but I remember my tests where not succesful)... So maybe t=
he
> > > ability to switch from xmlc to ... nothing is not that valuable. Af=
ter
> > > all, xmlc in a libre/free software, so depending on it is really ok=
.
> > >=20
> >=20
> > Barracuda uses many XMLC'isms.  Trying to strip it out would be fairl=
y difficult.
> >  Adding Jivan was kind of an exercise to show that another DOM framew=
ork could be
> > used within Barracuda.  But, as you say, "not all Barracuda possibili=
ties [are]
> > supported [using Jivan]".
> >=20
> > >> At this point, I'm not even sure it was a good idea to abstract th=
is stuff.  After
> > >> all, each DOM loading implementation (such as XMLC and Jivan) has =
their own DOM
> > >> loading facilities.  And few will use the same one in the same app=
.  Having been
> > >> away from Barracuda for a while and coming back to it, it seems li=
ke Barracuda
> > >> tries to bite off too much rather than concentrating on its core c=
ompetency: the
> > >> component model.  For instance, here's how to load a Document usin=
g plain old XMLC...
> > >>
> > >>
> > >>         Locale locale =3D ...;
> > >>         XMLCContext context =3D XMLCContext.getContext(this.getSer=
vletContext());
> > >>         XMLCDeferredParsingFactory dpFactory =3D
> > >>             context.getXMLCDeferredParsingFactory();
> > >>         Document page =3D
> > >>             dpFactory.create(new XMLCCreateOptions()
> > >>                             .setXmlcClass(HelloWorld4HTML.class)
> > >>                             .setUserLocale(locale)
> > >>                         );
> > >>
> > >>
> > >> Why complicate such a simple procedure behind a bunch of Barracuda=
 specific
> > >> interfaces, which cannot possibly predict the various inputs a DOM=
 loading
> > >> framework might require?  I'm of the mind that the DOM Loading stu=
ff be deprecated
> > >> or re-engineered in a way that, while abstracting DOM loading, pro=
vides full
> > >> flexibility to meet the needs of any and all possible inputs a giv=
en framework
> > >> might require.
> > >>
> > > Are there really so many possibilities ? I think document name / ur=
l and
> > > a locale might be enought for anybody, don't you think ?
> > >=20
> >=20
> > For the most part, yes.  However, XMLC supports the following configu=
rations....
> >=20
> > XMLObject xmlObj =3D null;
> > xmlObj =3D dpFactory.create(new XMLCCreateOptions()
> >                             .setXmlcClass(getXmlcClassFromSomewhere()=
)
> >                             .setUserLocale(request.getLocale())
> >                             //.setFallbackLocale(Locale.US)
> >                          );
> > //OR
> > xmlObj =3D dpFactory.create(new XMLCCreateOptions()
> >                             .setXmlcClassName(getXmlcClassNameFromSom=
ewhere())
> >                             .setUserLocale(request.getLocale())
> >                          );
> > //OR
> > xmlObj =3D dpFactory.create(new XMLCCreateOptions()
> >                             .setDynMarkupFilePath(getDynMarkupFilePat=
hFromSomewhere())
> >=20
> > .setDynDomFactoryClassName(XercesHTMLDomFactory.class.getName())
> >                             .setUserLocale(request.getLocale())
> >                          );
> >=20
> >=20
> > So, it could be a class, a class name, or a file path (a path relativ=
e to the
> > classpath, servlet context, if configured for it, or a configured rep=
arse resource
> > directory).  Plus, there's the optional DOM Factory Class Name (an XM=
LC DOMFactory
> > as opposed to a Barracuda DOMFactory) when using dynamic loading as w=
ell as the
> > optional user locale and fallback locale (the latter of which can als=
o be set in
> > web.xml or programmatically on the deferred parsing factory).
> >=20
> > Plus, though XMLC derives the markup encoding from XMLC configuration=
 files or the
> > markup file itself, you never know if a framework might require that =
information
> > explicitly provided to it.  The point is, you might think you have al=
l you need
> > and then run into some new and cool DOM framework that accepts that o=
ne extra
> > argument, without which you can't utilize it's full functionality.
> >=20
> > Interfaces methods on the DOMFactory just don't seem to make much sen=
se.
> > Implementations must be able to be plugged in without presuming the a=
rguments they
> > accept.  I haven't put much thought into it yet.  Hopefully it will b=
e feasible in
> > a way that either preserves backward compatibility or we could deprec=
ate the old
> > stuff and write new ones in parallel.
> >=20
> > >> Thoughts?  Should I check in what I have done and use XMLC directl=
y for the
> > >> HelloWorld4 L10n example, or should I wait for further discussion?
> > >=20
> > > Does what you have done break apps that use the DOMLoader / DOMFact=
ory
> > > interfaces ?
> > >=20
> >=20
> > Nope. No breakage.
> >=20
> > > I not, go and check in you work. If it breaks, I'd rather find a wa=
y to
> > > modify DOMLoader/DOMFactory to take the new locale parameter into
> > > account, as trunk is in some way the "stable" Barracuda :-)
> > >=20
> > > What do you think ?
> > >=20
> >=20
> > As I stated above, I think the DOMFactory classes need to be refactor=
ed to work
> > without presuming the arguments.  I don't really have a design in min=
d yet, just a
> > requirement.  If you come up with something, please let me know.
> >=20
> > There's also some work to do on the DOMWriter (XMLC implementation) t=
o properly
> > write files in the correct character set as well as set it on the res=
ponse object
> > (along with a few other things).  I also noticed one thing lacking in=
 XMLC's
> > XMLCContext DOM writing, which may entail a 2.3.3 release, though not=
hing that
> > currently affects Barracuda (nor XMLC users all that much).  Anyway, =
I left that
> > stuff alone for now.
> >=20
> > > Franck
> > >=20
> >=20
> > Jake
> > pi=C3=A8ce jointe document texte brut (message-footer.txt)
> > --
> > Barracuda mailing list
> > [email protected]
> > http://www.ow2.org/wws/lists/projects/barracuda
>=20
> pi=C3=A8ce jointe document texte brut (message-footer.txt)
> --
> Barracuda mailing list
> [email protected]
> http://www.ow2.org/wws/lists/projects/barracuda

--=20
Franck Routier=20
             Logo Ax=C3=A8ge
Ax=C3=A8ge
23,rue Saint-Simon
63000 Clermont-Ferrand
T=C3=A9l: +33 (0)4 63 05 95 40
Fax: +33 (0)4 73 70 65 29
Email: [email protected]





------------=_1287579638-30467-6256
Content-Type: text/plain; charset="UTF-8"; name="message-footer.txt"
Content-Disposition: inline; filename="message-footer.txt"
Content-Transfer-Encoding: quoted-printable

=0D
--=0D
Barracuda mailing list=0D
[email protected]=0D
http://www.ow2.org/wws/lists/projects/barracuda=0D

------------=_1287579638-30467-6256--