bsd5tu1 wrote:
>I was hoping that I could jar up the properties file (along with
>others), reference the archive in the HTML page, and then read them, but
>I get a security exception.
Using what Java code? Where is the security exception happening?
I've definitely used Class.getResourceAsStream() in applets to get a jarred
file, and it works fine. I've even used it to read a Properties file,
which sounds like exactly what you want. If it's not working for you,
you'll have to be specific about exactly what you're doing, the
resource-name, etc.
Once the Properties is loaded, you can't put it in the System properties,
because of the security implications. My solution is below.
>Is there an easier way of doing this? Actually, putting the PARAMS in
>the HTML page isn't that big a deal, but I would rather use a Properties
>class or some variant of it to extract the data from the HTML page and
>do it in a manner that doesn't add tons of code just for the applet.
>Does such a thing exist?
Yes. I wrote one. It's not that hard, and I suggest doing it yourself
because what I consider essential isn't what you will, and it's
straightforward enough that you can work from a simple design outline.
First, I subclassed Properties to search an Applet's params. This one's
simple enough I'll give it to you almost verbatim. All code hereby
released into the public domain, AS-IS AND WITHOUT WARRANTY:
/**
** AppletProps provides an applet-friendly way of getting and setting
** properties, which does not run afoul of applet security restrictions.
** Since an applet has named parameters, those can be represented as
** searchable Properties elements by wrapping an Applet into a Properties.
** This class does that for the getProperty() method.
**
** @author Gregory Guerin
*/
public class AppletProps
extends Properties
{
private Applet applet;
/** Create. The Properties can safely be null. */
public AppletProps( Applet applet, Properties also )
{
super( also ); // stored in protected field 'defaults'
this.applet = applet;
}
/** Calls Applet.getParam(), then looks in super, then in also. */
public String getProperty( String key )
{
String value = applet.getParameter( key );
if ( value != null )
return ( value );
return ( super.getProperty( key ) );
}
/** Fail. */
public void load( InputStream in )
throws IOException
{ throw new IOException( "NOT IMPLEMENTED" ); }
/** Fail. */
public void save( OutputStream out, String header )
{ throw new RuntimeException( "NOT IMPLEMENTED" ); }
// OPTIONAL: repeat save()'s body for propertyNames() and both list()'s
}
Second, to replace the static System-properties methods, define a new class
(I called mine Props) that does the following:
1) Provides static methods to get properties as various types.
2) Searches a static Properties first, but..
3) ..falls back to searching System properties, but...
4) ..catches all SecurityExceptions and returns null.
You can add other static methods as you see fit, such as setProp().
With no other code, and nothing assigned to the local singleton, Props will
behave just like System.getPropery(), so it works fine in applets OR in
stand-alone apps OR JNLP OR whatever.
#1 is at least:
public static String getProp( String name )
From that one method, you can add methods for as many other return types,
use of default values, etc. as you wish. Since what you need in this area
will be specific to your needs, it's best if you determine these.
Then go convert all uses of System.getProperty() to Props.getProp(). And
don't forget Integer.getInteger(), Color.getColor(), etc. for all the
return-types you care about.
#2 is at least:
public static void setProps( Properties newSingleton )
public static Properties getProps()
#3 and #4 are in getProp(), which all other static methods call. It's easy:
public static String getProp( String propName )
{
String value = getProps().getProperty( propName );
if ( value != null )
return ( value );
try
{ return ( System.getProperty( propName ) ); }
catch ( SecurityException fallsThru )
{ ; }
return ( null );
}
There's one caution in this regarding applets.
If you have multiple applets at the same URL (web page), a browser may
decide to give them all a single ClassLoader. As a result, they will then
share static variables, such as the static singleton of Props.
If the applets then all call Props.setProps() with themselves wrapped in
AppletProps, a getProp() will end up searching all applets on that page,
which may be inappropriate, or even a serious bug.
A solution to this is left as an exercise for the interested reader.
>... In any case, the data we
>receive and convert can be done much more quickly than the JVM can draw
>it, and after tracing the activities out, we found that some of the
>frames of data were being skipped.
One point here:
If the data is always arriving faster than it can be drawn, you will
eventually run out of buffering or CPU and HAVE to skip SOMETHING.
You can't have a producer whose mean production speed exceeds its
consumer's mean consumption speed, because on average, the consumer will
always get more backlogged, never less.
>What we did to correct this is
>synchronize a portion of the run() method that's running this thread and
>then, after repaint() is issued, we call wait(). A block of the code in
>the paintComponent() method is synchronized, and when complete, it calls
>notify(). This appears to work great (REALLY great, in fact).
I agree, especially on a dual CPU machine:
<http://www.amug.org/~glguerin/other/#Miasma>
You can also do double-buffering (filling A while painting B), to further
maximize CPU concurrency.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
