Re: 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...

------------=_1287604755-30467-6317
Content-Type: text/plain;charset=utf-8;format="flowed"
Content-Transfer-Encoding: quoted-printable

Yikes, that's bizarre.=C2=A0 It would be great if you could post a link t=
o the=20
issue you report.=C2=A0 Also, are you using a "stable" version or some ni=
ghtly=20
development release?=C2=A0 And is it OpenJDK6,=C2=A0 OpenJDK7, or both?

To help in tracking this issue down, you might want to mention that the s=
ource=20
for the Pretokenizer class exists in the "jregex/Term.java" source file.=C2=
=A0 I'd=20
link to the ViewCVS, but it doesn't seem to show anything for the JRegex=20
project.=C2=A0 However, you can obtain the source by downloading the sour=
ce jar=20
file from...

http://sourceforge.net/projects/jregex/files/jregex/jregex-1.2_01/jregex1=
.2_01-src.jar/download

BTW, do you understand what the following means?

[quote]
Current CompileTask:
  C2:873      jregex.Pretokenizer.next()V (1064 bytes)
[/quote]

"873" doesn't seem to correspond to any line number in the source.=C2=A0 =
In any=20
case, the "next()" method doesn't appear to do anything out of the ordina=
ry,=20
other than use a lot of nested "switch" statements and looping.

Glad it works for you on the Sun JDK.=C2=A0 Let me know of anything else =
you find.


Jake

On Wed, 20 Oct 2010 15:27:57 +0200
  Franck Routier <[email protected]> wrote:
> Ok,
>=20
> using sun's jdk fixes the problem.
>=20
> With openjdk:
> - it will always fail on first launch, at the same point, with the same
> method call in hs_err_pidxxx.log
> - but re-running the build (without clean) will complete the task
>=20
> I'll open a bug report on openjdk and go on testing the new xmlc.
>=20
>Franck
>=20
>=20
> Le mercredi 20 octobre 2010 =C3=A0 12:54 +0200, Franck Routier a =C3=A9=
crit :
>> 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=3D1405648=
54421264
>>=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=A9cr=
it :
>> > Hi Franck,
>> >=20
>> > See comments inline below.  Also note that I committed the changes.=20
>> 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=20
>>have the time.
>> >=20
>> > >>
>> > >> So, while DOMFactory.getInstance(Class) suffices for Barracuda, i=
t does=20
>>not for
>> > >> XMLC.  We need the Locale as the second argument.  But that would=
=20
>>change the
>> > >> interface, which might not be so bad.  But then we'd have essenti=
ally=20
>>the same
>> > >> interfaces for both DOMLoader and DOMFactory, which just seems wr=
ong.
>> > >>
>> > > Well, abstracting the DOMLoader at least give the option to swith
>> > > DOMFactory and document parser if needed. But it might well be a f=
alse
>> > > 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 si=
te is
>> > > down). As far as I can tell, it was suffuring from limitations any=
way
>> > > and not all Barracuda possibilities were supported (cannot remeber=
 what
>> > > exactly, but I remember my tests where not succesful)... So maybe =
the
>> > > ability to switch from xmlc to ... nothing is not that valuable. A=
fter
>> > > all, xmlc in a libre/free software, so depending on it is really o=
k.
>> > >=20
>> >=20
>> > Barracuda uses many XMLC'isms.  Trying to strip it out would be fair=
ly=20
>>difficult.
>> >  Adding Jivan was kind of an exercise to show that another DOM frame=
work=20
>>could be
>> > used within Barracuda.  But, as you say, "not all Barracuda possibil=
ities=20
>>[are]
>> > supported [using Jivan]".
>> >=20
>> > >> At this point, I'm not even sure it was a good idea to abstract t=
his=20
>>stuff.  After
>> > >> all, each DOM loading implementation (such as XMLC and Jivan) has=
 their=20
>>own DOM
>> > >> loading facilities.  And few will use the same one in the same ap=
p.=20
>> Having been
>> > >> away from Barracuda for a while and coming back to it, it seems l=
ike=20
>>Barracuda
>> > >> tries to bite off too much rather than concentrating on its core=20
>>competency: the
>> > >> component model.  For instance, here's how to load a Document usi=
ng=20
>>plain old XMLC...
>> > >>
>> > >>
>> > >>         Locale locale =3D ...;
>> > >>         XMLCContext context =3D=20
>>XMLCContext.getContext(this.getServletContext());
>> > >>         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 Barracud=
a=20
>>specific
>> > >> interfaces, which cannot possibly predict the various inputs a DO=
M=20
>>loading
>> > >> framework might require?  I'm of the mind that the DOM Loading st=
uff be=20
>>deprecated
>> > >> or re-engineered in a way that, while abstracting DOM loading, pr=
ovides=20
>>full
>> > >> flexibility to meet the needs of any and all possible inputs a gi=
ven=20
>>framework
>> > >> might require.
>> > >>
>> > > Are there really so many possibilities ? I think document name / u=
rl and
>> > > a locale might be enought for anybody, don't you think ?
>> > >=20
>> >=20
>> > For the most part, yes.  However, XMLC supports the following=20
>>configurations....
>> >=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()
>> >=20
>>                            .setXmlcClassName(getXmlcClassNameFromSomew=
here())
>> >                             .setUserLocale(request.getLocale())
>> >                          );
>> > //OR
>> > xmlObj =3D dpFactory.create(new XMLCCreateOptions()
>> >=20
>>                            .setDynMarkupFilePath(getDynMarkupFilePathF=
romSomewhere())
>> >=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 relati=
ve to=20
>>the
>> > classpath, servlet context, if configured for it, or a configured re=
parse=20
>>resource
>> > directory).  Plus, there's the optional DOM Factory Class Name (an X=
MLC=20
>>DOMFactory
>> > as opposed to a Barracuda DOMFactory) when using dynamic loading as =
well=20
>>as the
>> > optional user locale and fallback locale (the latter of which can al=
so be=20
>>set in
>> > web.xml or programmatically on the deferred parsing factory).
>> >=20
>> > Plus, though XMLC derives the markup encoding from XMLC configuratio=
n=20
>>files or the
>> > markup file itself, you never know if a framework might require that=
=20
>>information
>> > explicitly provided to it.  The point is, you might think you have a=
ll you=20
>>need
>> > and then run into some new and cool DOM framework that accepts that =
one=20
>>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 se=
nse.
>> > Implementations must be able to be plugged in without presuming the=20
>>arguments they
>> > accept.  I haven't put much thought into it yet.  Hopefully it will =
be=20
>>feasible in
>> > a way that either preserves backward compatibility or we could depre=
cate=20
>>the old
>> > stuff and write new ones in parallel.
>> >=20
>> > >> Thoughts?  Should I check in what I have done and use XMLC direct=
ly for=20
>>the
>> > >> HelloWorld4 L10n example, or should I wait for further discussion=
?
>> > >=20
>> > > Does what you have done break apps that use the DOMLoader / DOMFac=
tory
>> > > interfaces ?
>> > >=20
>> >=20
>> > Nope. No breakage.
>> >=20
>> > > I not, go and check in you work. If it breaks, I'd rather find a w=
ay 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 refacto=
red to=20
>>work
>> > without presuming the arguments.  I don't really have a design in mi=
nd=20
>>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) =
to=20
>>properly
>> > write files in the correct character set as well as set it on the re=
sponse=20
>>object
>> > (along with a few other things).  I also noticed one thing lacking i=
n=20
>>XMLC's
>> > XMLCContext DOM writing, which may entail a 2.3.3 release, though no=
thing=20
>>that
>> > currently affects Barracuda (nor XMLC users all that much).  Anyway,=
 I=20
>>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
> --=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]
>=20
>=20
>=20
>=20
>=20
>=20


------------=_1287604755-30467-6317
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

------------=_1287604755-30467-6317--