Vincent Hernandez

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

Recent posts by Vincent Hernandez

Your current technique is certainly in violation of the EJB spec. Load the file into a ResourceBundle, there is plenty of documentation on how to do this.

I see you're the person who stated the same fact in the thread I listed in my original post, but can you please point me to where exactly this is stated in the EJB spec?

Also, I'm curious about the ResourceBundle. Isn't this intended for Locale-specific settings with regard to language?
Thank you very much Valentin! I was very concerned about the classpath issue as well, and I can say from my end I don't allow for multiple versions of the properties file to be lying around in the system.

I still would appreciate if anyone else can provide additional feedback.

Before going on with this post, I apologize if this isn't the best place to put this question, but after reading the thread .properties vs JNDI, I see my question is related.

I'm trying to load a .properties file from within an .ear file. In other words, I have a properties file inside my .ear file, and I'm trying to find the right way of loading the file. Currently my solution which works is utilizing the getResourceAsStream() method which returns an InputStream object which will be used in Properties.load(InputStream), therefore loading the properties. This works flawlessly either when the ear is exploded or running locally or when it's deployed.

However, when I read the above mentioned thread, I see using goes against the EJB specs. First of all, is this true? Secondly, if it is true, is my current technique in violation of this?

I'm finding some conflict with this because I also have seen threads regarding the use of Struts where the struts-specific files make use of getResourceAsStream. This is partly where I'm finding some confusion.

I will stress I am using this properties file for READING ONLY. I am NOT writing to it in any way shape or form. Thanks a bunch.

PS -- If any Moderator feels that this is not appropriate for this forum, please move it. Thank you
I'm not trolling. It's just that I'm wondering if anyone does the above mentioned, and if so, what tools do they use (preferrably free), and what's their strategy with it for this SCJD project.

I don't think this is a troll post. I'm not saying "you should use X and Y or you're a Z".

If the admin feels this is a bad post, please take it down. I'm not asking about the topic in general, but how they would apply it specifically for this project. Thank you.
The topic pretty much speaks for itself. Any pointers?

Edit: What I mean by "the topic speaks for itself" is "My question is regarding source control and nightly build uploads. Does anyone do that?"
[ February 08, 2005: Message edited by: Vincent Hernandez ]

Reply from Sun Microsystems: Don't worry about automated tests. We stopped using automated testing several years ago. Your assignment specs probably mentioned about software testing. The software testing only tests the following:

1) Your JAR file contents. They must conform to the specs (such as the folders you must have and so on).

2) Test if you illegally modify the interface given to you, and test if your implementation class implements that interface (once again, indirect implementation is allowed).

I have never seen a post that had an official reply or statement on this matter. Very refreshing and comforting to see this. Thank you for posting this Stephen!

At least in my case, the answer is no. I looked at the adaptor pattern and saw how it was utilized within the Habibi book, but looking ahead I saw I would have many complications with my business logic layer.

For instance there's a situation in my business code where I need to do the following:

1. lock the record to be updated.
2. read the record.
3. verify the record has not been updated in a particular field.
4. update the record.
5. lock the record.

Now, let's say I wanted to use an adaptor class. Ideally, this is what I'd want to see in a complimentary business method:

1. read a record (assume it's a safe, clean read which is done in the code).

After 1 is done, your record is unlocked...
<<someone in another thread updates before 2 can be run!>>

2. update a record (lock and unlock done in data adaptor).

Now, I thought about creating a data adaptor class, but then I started to see that there were special rules involved with that, like the check to see if the owner id was filled, etc. That sounded to me more like a business rule, so I decided to put my business logic layer on top of the data access layer.

I'd like to hear how others handled this part.

More than that, for this use there is a real reason not to use a synchronized collection. You need to have you own synchronized methods or blocks so that you can use wait and notifyAll. These blocks will access the collection. If the collection is also synchronized, you will have nested synch blocks, which are a bad idea since they encourage deadlocks and they interfere with performance.

I have to disagree with this. As the Habibi book explicitly points out, all a synchronized class guarantees is that it's actions are atomic. If one thread calls for an add operation to a sychronized structure and another calls for a read, one operation will be done before the other. However, because it's a question of which occurs first, there needs to be synchronization in order to manage the structure in multi-threaded situations.

As for encouraging deadlocks, calling a sychronized method such as Vector's add inside a sycrhonized block on the vector object will not cause deadlock. once the IP hits the sychronized block line, the thread that exectued it owns a lock on the object. When the add is called, the same thread still owns the object.

Hashtable is somehow a "legacy" data structure in Java.

I do not see any label to Hashtable indicating it is depricated. However, seeing how you used your HashMap, you took all the proper precautions that were necessary.
Aha! Ok that makes sense to me now. Thanks Ryan.

As for the second reply you make, my interface is different than yours, and unlock does not throw RecordNotFoundException, only SecurityException. This makes much more sense.

Just out of curiousity, why did you chooese HashMap over Hashtable?
Hi Dennis,

I believe this is something you will need to point out in your choices.txt. From what I've read on these Javaranch forums is that the testers won't assume anything you do, and that you should probably state it. I think whichever choice you make...7 or should state why you did that and let them know which index corresponds to which field value.

For me, I have 6, because I don't pass the delete flag. I do use the delete flag within my data system, but when it's regarding data retrieval, I don't see the need for it.

I'm sure others will have 7 or 8.

The other thing is I'm not sure which assignment you're doing, so you may have more fields in your database schema, so the numbers will vary.

In summary, just document it!

As for the verification of the values passed in data[], you'll have to make a decision. I have made a decision on how to handle this matter, and it will be different for other people.

I wouldn't risk this. Looking at the instructions:

When you submit your assignment, each part (client and server) must be executable using a command of this exact form:

You would get an auto fail for this. In addition, using a bat file would imply windows dependency. I would not advice risking this.
Hi Ryan. Thanks for posting some insight into your locking strategy.

I'm a bit confused on a couple points you make within. Perhaps it was your wording, but I want to see if you can clarify.

From what I can gather I can assume a couple things, which sounds fine:
1) You lock a record before calling an update or delete operation.
2) You unlock a record after calling an update or delete operation.

For update, first I check if the record is being locked by the specified cookie within the HashMap sync block. Then I perform the actual I/O update out of the sync block.

Are you synchronizing on your HashMap within your update method? If so, why? It makes no sense to me to do such if all you are doing is a lookup. My understanding is that you should only synchronize the HashMap (or whatever locking structure you may have) during times you plan to delete (during unlock) or add (during lock) operations.

For delete, I do similarly as update, but include another HashMap sync block after delete to remove the locked record.

Again, I'm not sure what you mean by this. Are you talking about your unlock record operation? Also, shouldn't unlockRecord handle the deletion of the locked record number?
Ok, thanks for the current feedback guys, but aside from some of the brief comments, most of this has gone off into a tangent. Can I get some feedback on my original question:

Which leads me to 2 options:
A) create an abstract class or interface and have 3 different "option window" types that extend/implement that. A factory object can crank out the right one, depending on the mode.

B) create only one window type for options and use the mode flag to determine which fields are shown.

A sounds cleaner, but I think it may be overkill.

B sounds like less code and probably less repetitive code, but it may be messy.

What do you guys think? Any feedback is appreciated.

And this is my current list of options which I plan to have listed:


Network Client:
Server IP
Server Port

Standalone Client:

After scanning through my instructions, I will agree with you Reza It makes better sense to reduce the amount of input the user provides as much as legally possible. Reduces complexity and overhead. For thank, thanks!

But yes, feedback on the original question is still needed. Thank you in advance!

Do you really need the file location either?

From the instructions I have, under "network connections".

Your choice of RMI or serialized objects will not affect your grade, but no other approach is acceptable. In either case, the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely.

I understand it's under the "network connections" section, meaning the user should only specify the IP/Port location of the server if it's in Network Client mode.

I can see what you mean by your question/statement, but I will agree with you somewhat by saying that declaring the file location within the options seems like something that is optional, and that if i wanted to, not even prompt the user for such.
I see what you mean, and yes you're right. So with that aside,

File Location

Network Client:
Server IP
Server Port

Standalone Client:
File Location