Pete Ihlenfeldt

Greenhorn
+ Follow
since Jan 24, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Pete Ihlenfeldt

We have a Swing app deployed via JNLP. The JNLP file specifies JRE 1.5+.
Apple LaF is in play.
There is an error that occurs ONLY on Mac OSX desktops. When the user clicks in the open area of a frame, they get a NullPointerException. Stack looks like:



I've been able to gather very little from the web on this, other than a recognition of the bug, with a partially-described solution that I don't understand.

If anyone has seen this problem, or has any helpful information, it would be greatly appreciated.

Pete
15 years ago
Ok, I believe you may have to convert that field to a TIMESTAMP in order for it to register with querying drivers as a field that contains both Date and Time portions. 10g also has TIMESTAMP WITH TIME ZONE and TIMESTAMP WITH LOCAL TIMEZONE types, but I'll leave that determination to you.

TIMESTAMP is an extension of the DATE datatype, designed to include the additional information. Technically the DATE datatype in Oracle does store time information, but I believe the standardized solution for you is to make the datatype universally visible as a date/Time structure. The ANSI literal for DATE does not include time information ('2008-05-28'), so you end up having to use special Oracle-specific functions (TO_DATE) to specify time information. You don't want to do that. You want your application to be as portable as possible. TIMESTAMP also offers further granularity. DATE's time information only goes down to the second. TIMESTAMP to the millisecond. Better for determining intervals between operations recorded inside of a second.

If you want to read a little more, see...
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/sql_elements001.htm
Find the text "DATE Datatype" and read that and the "TIMESTAMP Datatype" below it.

I think if you use TIMESTAMP, and then use the code I posted earlier, you'll be good to go. I almost always have time fields in business objects declared as java.sql.Timestamp for this very reason.

Good luck... let me know if you have anything else.
nomad
Which database are you using (want to know before I respond)?
I assume that you are certain the database field is of type datetime. If you are uncertain (i.e. if you did not do the database implementation or do not have direct access) you can check using the ResultSetMetaData class:

(after calling rs = stmt.executeQuery()...)


if you are sure it is, then you should be able to get the full timestamp using



That doesn't work?
What you're talking about is the composite pattern.

The composite is a design structure that allows you to define objects that contain other objects, some of which may in turn contain more objects, and some which may not ("leaf nodes" in your menu tree).

I wish I could draw a UML diagram for you, but This Java World article explains it and has a diagram.

Basically you define a base class that is abstract and defines the contract for a primitive element in your containment structure. then, you extend that base class with two descendants, one that simply implements the contract specified by the base class (this will be your leaf node), and one that is a composite (a node that can contain other nodes).

Just a note too, after seeing your code... adhere to bean standards... no public members unless absolutely necessary... use accessor/mutator pairs. So your code would look something like this:

Base class


Leaf node class:


Composite node class:


Then all you have to do is run your DB query or whatever, and materialize the structure. Your primary containment for your main menu items is a Composite (CompositeMenuItem). Then just start adding components. If the component you're adding has sub-nodes, add a composite. If it doesn't, add a Leaf.

Play with that and see how it works.
Good luck
16 years ago
The answer: for anyone who needs it:

I read some tech notes and found that the proper way to do this is NOT to use getSystemResourceAsStream. Rather you should use "getResource".

Obviously you would re-arrange this code with the proper try/catch/finally blocks, but the condensed form is:



hope this helps someone.
[ February 05, 2008: Message edited by: Pete Ihlenfeldt ]
16 years ago
I don't completely understand the Dark Arts of how the plugin facilitates the connection between an applet and the jars in the plugin cache... making them part of the applet's classpath. But i do know that with all the auxiliary jars I have, the applet has been finding the classes it needs.

Now I have a rather large spreadsheet, that I wanted to deploy as an uncompressed jar, because it takes too long to stream it over the wire off the server. I wanted to avoid putting the spreadsheet in the applet jar itself. So, I did a jar cvf0, put the spreadsheet in there, included it in my project classpath (e.g. project properties -> compile -> libraries -> add new Jar).

Locally it works great.



works perfect.

For the applet, I added an entry in the <OBJECT> tag on the serving HTML page, and deployed. When I start the applet, the plugin retrieves the file perfectly, and I checked it in the cache... all good.

Problem: getSystemResourceAsStream returns null.

I am moderately experienced with the other Dark Arts of ClassLoaders, but does anyone see a glaring, obvious blunder I am committing?
[ January 29, 2008: Message edited by: Pete Ihlenfeldt ]
16 years ago
I found the answer, at least in this case, so I thought I would post it for future seekers.

In the object tag (on the applet-serving HTML page), you specify auxiliary jars needed by the applet, and their associated versions, just like shown in my first post.

The java plugin then forces the download of those jars if you do not have them. They are recorded with whatever version number you gave them in the object tag, and whatever "originating URL" you gave them.

Thereafter, when the applet is started, it first gets the applet jar (if necessary, and then as the applet starts up, and references classes in your auxiliary jars, it looks at the jars that contain those classes. For each one (only once) it will open a URLConnection to the originating URL for that jar, and read the last mod timestamp on the file on the server. if the last mod indicates the cache has the latest version, it should terminate the connection.

What I was seeing was that the plugin would download the file anyway... all 9 of them in my case.

Why? Check this out. In you're application code, when writing an applet, you will likely have one or more spots where you yourself open URLConnections to the server. And more often than not, the initialization code for the URLConnection looks like:



however there is another call that people will often habitually make in their code, perhaps not knowing of it's effect:



When you do this, ANYWHERE in your code, it sets a static variable on URLConnection that affects all other URLconnections' defaults. Since the plugin is effectively in the same JVM as your application, if you make that call, from that point forward the default is to not use the cache, even if the plugin itself is set to "use cache".

I looked in my [inherited] source, and sure enough... 7-8 different places, seeming out of habit rather than any particular purpose, there were calls to .

I removed them, and just like that, the plugin functions as expected. Jars are only downloaded when needed, and the app startup time has been greatly reduced.

Hope this helps someone.
16 years ago
I'm maintaining an applet. All jars are signed. Aside from the applet jar itself, it requires 9 additional jars totalling >30MB (I didn't originate this design).

I know Swing, but next to nothing about applet deployment.

Security is web-based (SiteMinder)

The serving page's <OBJECT> entry looks like this:


(It does not use the cache_archive_ex tag, which I have seen mentioned in forums and articles, but do not completely understand)

I have the 1.5 plugin. I open the cache and clear it, but keep it open to watch the arrival of the jars. I also have FileMon running to watch the access of the files in the cache.

So, hit the applet page, and in the console you see several blocks of output, where it's retrieving each jar specified in the <OBJECT> tag of the serving page. Each block passes by, stalling as the file downloads. When the log continues, the file has appeared in the cache. All good. I understand that much.

The cache viewer now shows all 10 jars, and the URL for each one is the SERVER url of the jar, as specified in the HTML page that served the applet.

So now, the app starts to load. By this point I've seen thousands of hits on the locally cached jars, meaning the applet is using them as it initializes.

Now, in the console, what I see for each jar again is a block of code. Different from the first blocks, where the console was saying



over and over... now it's saying:



And with each such block there is a pause. That pause is congruent with the size of the jar. essd9 (Actuate's eSpreadsheet jar) is 19MB... the pause is 2 minutes. xerces.... maybe 5 seconds, and so on.

My Question:

If you set up an applet-serving page to force the download of a bunch of jars... and caching is turned on in the plugin....and FileMon shows that the application is using those jars...

Then why does the console appear to be downloading the jars on the server again.... why is it hitting those originating URLs... and not just referencing them for a second... long enough that it FEELS like a download (even though the cached versions don't change)?

ANY help at all would be very much appreciated.

Thanks in advance.
digital_nomad

(UD: added linebreaks to preserve layout)
[ January 25, 2008: Message edited by: Ulf Dittmer ]
16 years ago