BJ Grau

Ranch Hand
+ Follow
since Jul 10, 2001
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 BJ Grau

I don't know of a compatibility matrix. I think that you are more concerned with which version of the HTTP spec the browser conforms to and unless you are using an ancient browser you should not have any problems.

I know your customer wants something more reassuring than that so if you can find a compatibility matrix for Apache it will apply to IHS. One of the main differences will be in the SSL implementation.
17 years ago

Originally posted by Marcos Motta:

Yes. I modified Data to throw RemoteException in all methods. And I am not confortable with it, but my point is: Data is an implementation of DataInterface wich is solely a means of allowing clients to work with remote or local databases using common interface.

Data by tislef has nothing to do with remoteness, so I think it would be a bad design choice to do that.
How about this:
Make DataInterface match the method signatures of Data as supplied by Sun. Then write an adapter that allows clients to interact with RemoteData as if it was a DataInterface. So now your clients get a reference to DataInterface, and the actual concrete implementation is either simply Data for local access or RemoteDataAdapter with the adapter class passing along method calls to the contained RemoteData and converting the RemoteExceptions to the appropriate types.
or you can follow Mark's advice of the interface throwing Exception in each method.


Originally posted by Marcos Motta:
Your comments, please.
DataInterface: Declares RemoteException in all
methods. Provides access to the database, hiding
all details about the location of the database file
from its clients allowing the pluggable behaviour
required by the FBN gui client
Data class: implements DataInterface.
[ March 16, 2003: Message edited by: Marcos Motta ]
[ March 17, 2003: Message edited by: Marcos Motta ]

I am curious about your statement above. If DataInterface throws RemoteException in all methods, and Data implements it, then have you modified the methods in Data to throw RemoteException?

Originally posted by aadhi agathi:
so i am having a structure

I'm a little wary of this package structure. I would keep yours similar to what Sun already gave you with suncertify.db.
You absolutely need some way to identify the combo boxes. I laid mine out vertically on the left side like this:

[ March 17, 2003: Message edited by: BJ Grau ]
@throws and @exception are synonymous with each other, @throws was just added after @exception. Personally I use @throws.
Yes, you should list multiple exceptions in alphabetical order.
As far as a static factory method for getting an instance of your FlightControler instead of a constructor, there are advantages and disadvantages to using it. You should consider the benefits of the static method and base your usage of it on the compelling need for one of these.
Some of the advantages are:
1) Allows you to control the number of instances.
2) Effectively allows you to give meaningful names to your methods that construct instances of your class. This comes in handy when you have multiple constructors and would like to describe what they do in some way other than the parameter names.
3) Allows you to return subclasses.
[ March 17, 2003: Message edited by: BJ Grau ]
Just use the same db.db file for both.
I would only use one instance of Data for all clients, but I would avoid enforcing this relationship with the singleton pattern. Search this forum for somne great discussions on this.
As far as "concurrency", all the methods in Data that interact with db.db are synchronized so the point is moot. Don't worry about it. Also, you will not need to modify Data in either case.
Here is a link to an article about applying the factory pattern to getting references to remote objects:
RMI Factory Pattern
[ March 17, 2003: Message edited by: BJ Grau ]

Originally posted by Eugene Kononov:

I happen to believe that ability to support multiple databases is one of these important elements of your design.

Yeah, but how realistic is expanding this cheesey database? I would expect them to move to a commercial product before building more tables for this dog. I would reason that the archtiecture needs ot be designed so that they could move to a commercial product with minimal impact on the rest of the code. Of course, either viewpoint is correct since both have some justification to back them up, I just like the one that requires less work.
Excellent translation Eugene!

Originally posted by brutus zhou:
I wonder whether it is necessary to worry about the increase of database table.

Can you please explain your question some more? I'm not sure what you are asking.
I may not be answering the question that you are actually asking, but here goes:
Are you implementing the hyperLinkUpdate method? If not, let your JFrame implement HyperLinkListener and then supply the implementation of hyperLinkUpdate. (Or something like that). It will respond to hyperlink events, and you specify what page to display in the method.

[ March 14, 2003: Message edited by: BJ Grau ]

Originally posted by Alexander Gunnerhell:
No, I won't implement a full-featured DBMS since there's nothing in the assignment that indicates or states that this is a current or future need/requirement.
However, the requirement for scalability is strongly hinted in the first sentence describing FBN.

Is it really scalability that is strongly hinted at? If so, everyone on this forum is in big trouble. Perhaps it is <i>extensibility</i> that they are hinting at.
If it is scalability, how scalable do you think Data and db.db are as a database?
This assignment is merely <b>symbolic</b> of a real project. If we were to take it literally, there would be so many implied requirements to fullfill that we would never finish.
I think your idea is very interesting, and I am very impressed that you successfully implemented your own thread pool. I almost feel bad for not saying "Go for it", but I have just never heard any advice from any person or forum that suggested anything but keeping this very, very simple. If you do go for it, the worst that will happen is you spend another $250 and have to submit again. If you do go for it, please let us know how it works out for you.
I wish my understanding of RMI went beyond the specification, then I could actually address your questions #1-3.
Alexander -
I agree strongly with Eugene. I think you are going in the wrong direction with the scalability part. The point of this exercise is to satisfy the vague and incomplete requirements as put forth by Sun, not produce a commercial product. If you spend some time reading this forum you will see what I mean.
Also, I have never written my own thread pool, but I know you would be opening an ugly can of worms with that and it could lead to trouble, unless you already have some strong experience with it. If you need to go this route, write a simple unscalable solution for Sun, submit it, and then write a scalable solution for yourself.