You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Jorg Heymans <jh...@domek.be> on 2004/10/21 12:07:46 UTC
Re: Locales problem (was Re: batik attempts to download classes
from applet)
Hi Thomas,
Still having some symptoms of this, batik tries to download
org.apache.batik.swing.resources.Messages.class (and subsequently,
"Messages_de_DE" variants of this)
Is this the same problem as with the dtd.properties file before?
Regards
Jorg
Thomas DeWeese wrote:
> Jorg Heymans wrote:
>
>> Is this Services API something Batik specific ?
>
>
> No, it's not, it's generally called Service Provider
> Interface:
>
> http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html
>
> Under Service Provider.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Locales problem (was Re: batik attempts to download classes
from applet)
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
>>
>>
>> Yes, except these files really should be able to be localized.
>> The Messages*.properties files store all the UI text, see,
>> java.util.ResourceBundle.
>>
> I see. But why does it try to find
> org.apache.batik.swing.resources.Messages.class when this class is not
> even in the archive?
You need to read the description of ResourceBundle, one option
is to have classes instead of properties files.
> There is a org.apache.batik.swing.Messages however.
> And if i set the locale on the canvas to English, why does it still try
> to retrieve the OS locale message properties (ie german)?
I would guess that we don't quite properly handle locale, so
setting it on the canvas doesn't carry through the whole system,
we end up just using the 'default' locale for the JVM.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Locales problem (was Re: batik attempts to download classes
from applet)
Posted by Jorg Heymans <jh...@domek.be>.
>
>
> Yes, except these files really should be able to be localized.
> The Messages*.properties files store all the UI text, see,
> java.util.ResourceBundle.
>
I see. But why does it try to find
org.apache.batik.swing.resources.Messages.class when this class is not
even in the archive? There is a org.apache.batik.swing.Messages however.
And if i set the locale on the canvas to English, why does it still try
to retrieve the OS locale message properties (ie german)?
> It appears that there isn't a clean way to avoid this given
> the design of Applets. What you really want to say is only check
> the contents of the Archives (jar files). But an applet always
> has 'codebase' on the class path - so it will always attempt to
> load 'missing' files from the server (as opposed to simply
> aborting).
Agreed.
> Why is it so bad for the Applet to request these classes? (the
> Server should respond fairly quickly with a 404).
I just like to be a bit more in control of the applet communication
that's all :) It's not really bad behaviour on the part of the batik
applet.
Hope this is still somehow batik relevant :)
Regards
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Locales problem (was Re: batik attempts to download classes
from applet)
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
Jorg Heymans wrote:
> Still having some symptoms of this, batik tries to download
> org.apache.batik.swing.resources.Messages.class (and subsequently,
> "Messages_de_DE" variants of this)
>
> Is this the same problem as with the dtd.properties file before?
Yes, except these files really should be able to be localized.
The Messages*.properties files store all the UI text, see,
java.util.ResourceBundle.
It appears that there isn't a clean way to avoid this given
the design of Applets. What you really want to say is only check
the contents of the Archives (jar files). But an applet always
has 'codebase' on the class path - so it will always attempt to
load 'missing' files from the server (as opposed to simply
aborting).
You might be able to do something with a subclass of ClassLoader
but I would think that it would be hard to know when it was safe
to pass a load request to a parent and when it wasn't.
Why is it so bad for the Applet to request these classes? (the
Server should respond fairly quickly with a 404).
>
> Regards
> Jorg
>
> Thomas DeWeese wrote:
>
>> Jorg Heymans wrote:
>>
>>> Is this Services API something Batik specific ?
>>
>>
>>
>> No, it's not, it's generally called Service Provider
>> Interface:
>>
>> http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html
>>
>> Under Service Provider.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org