Isaac Shabtay

I am experiencing exactly the same problem, and I agree with what mentioned above.

The EJB specification states that all classes & interfaces required in the client's side of things - be available for the client. Now, mind you, RMI *does* support downloading "remote" classes through the wire. However, EJB apparently doesn't use this feature, regardless of your JVM's security settings (RMI requires a SecurityManager to be installed, with specific permissions to allow remote code download).

In my opinion this is a strong deficiency in the EJB specification. The client-JAR should contain only the client-side of things. A true separation between interface to implementation can only be achieved if the implementation classes are NOT included in the client JAR. This deficiency causes us some good headaches. I am surprised, and disappointed, to see that not a lot has been done in order to mitigate this deficiency.

At least, we would expect WebSphere Application Server to give us some useful indication as to what happened... WebSphere 5.0 didn't even throw an exception! It would just treat the value as "null".

If you found any workaround, please let me know as I'd be happy to know about it.


Cheers.


Isaac

I have an interesting idea regarding the interpretation of the Business Domain Model provided with FlyByNight.

I have read through this forum and it appears that the Segment - Flight - Equipment issue in the BDM caused a lot of trouble to many people.

Notice that what I am writing here is not "the" solution to this problem - we all know that this issue is subject to interpretation and there's no "correct" answer. Therefore I believe that my post is with accordance to the forum's guidelines.

As it turns out, the BDM makes perfect sense if it is looked at from the point of view of one particular moment in time. If looked at from that point of view, suddenly everything falls into place quite neatly:

1) In one instance of time, a customer has zero or more itineraries, and each itinerary is associated with one customer.

2) In one instance of time, a segment (interpreted as a "line" in the itinerary) is associated with one itinerary, and one itinerary is associated with 1 segment or more.

3) In one instance of time, a segment is indeed performed by one flight. Conversely, in one instance of time, one flight serves only one segment.

And so forth.

My question is: Is this a legal way to interpret a business domain model? Usually, when I am presented with a domain model, I am looking at it in a more generalistic way - however such a look renders the multiplicities in the BDM completely bizarre and useless (one can easily deduce that one flight serves only one customer. Follow the "..1" multiplicity from flight back to customer and figure it out).

What do you think would make more sense in the eyes of the examiner? The assumption that this BDM is time-centric, or the alternative way of trying to find hidden meanings and lost entities?

Will appreciate your comments.


Isaac

Hi there.
I am on the verge of defaulting to banging my head hard against the wall.



Please help.

I am using J2EE 1.3 (Servlets 2.3, JSP 1.2).

I am writing a JSP page using the XML format. I have:

<jsp :mrgreen: irective.page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"/>

In the top, and everything's fantastic.

BUT!

If I only add the

<fmt:setBundle>

tag in the page, then from some reason, the response is encoded using ISO8859-1 instead of UTF-8.

Anybody?

Originally posted by Ignacio del Valle:
Hello Isaac
Why are you validating JTextField text when the cancel button is pressed?
I think verifying the data when the user press the ok button, not when the JTextField lose the focus is an easier path.
Regards

[ December 14, 2004: Message edited by: Ignacio del Valle ]

I know it is an easier path. And that is the way I am currently implementing it. I was just considering to switch to using InputVerifier's, because, naturally, this is what SUN has provided for input validation. And this is the way that input validators work: They validate the data when the component loses focus.

Hey all,

anybody here used an InputVerifier when verifying input in a dialog?

Seems like a neat idea, but how would you overcome this?

1) User enters inappropriate data in a JTextField which has an InputVerifier associated with it.

2) User decides that he had enough of URLyBird for today and hits "Cancel".

3) Hitting "Cancel" causes Swing to attempt transferring the focus to the "Cancel" button, thus trying to validate the input field.

4) Validation of the input field fails, so focus stays on the JTextField.

Conclusion: User cannot exit the dialog.


Enlighten my way, please.

Originally posted by Vince Cheung:
I still can't do it, Can someone say how to do detailedly.
thank you

Define the main class to be, say, "suncertify.Main". Then, in suncertify.Main, analyze the argument and invoke the appropriate functionality.

Originally posted by Anton Golovin:

Apparently - and I am giving away half the solution here - two competing threads running the create method may overwrite the same record!!!

Well... If your program ever gets to such a "race condition", then I would say that you might want to rethink your way of synchronizing access to the database.

Hmmmm.

It appears to me (unless I'm missing something) that you are writing an indication about the record being locked - to the database itself. I have never seen such an approach taken - usually, all locks are managed in memory.

But this is quite an interesting approach, now that I think of it. Anybody else here is doing the same?


Isaac

Hello All,

just to make sure I understood correctly:

1) If the program is invoked using the "alone" switch, then the client
GUI is invoked and only allows local files to be used as database
locations.

2) If the program is invoked with no switch (default), then the client
GUI is invoked and only allows network locations (IP addresses) as
database locations.

Meaning, that the client GUI is the same for both cases, and only the
"open database" operation behaves differently.

Am I missing anything?


Thanks

Hello everybody,

Well, although I'm new to this forum, I actually have already written most of my SCJD project (URLyBird). Just going over some of the issues I've been through. So I have several questions, any insight will be greatly appreciated.

My first question would be about the configuration of the data access server.

Clearly, when running in stand-alone mode, no such configuration is needed. The GUI simply prompts the user for a file name (using a JFileChooser) and that's it.

However, some questions arise regarding running the program in "server" mode.

What I did (so far. This is the part that I haven't quite completed yet) is just use hard-coded values for the following items:

* Listening port
* Database file name

And when the program runs as server, a small, empty frame pops up and minimizes itself immediately. This frame creates a thread for running the listener. The reason I chose to use a frame instead of just a console application is the ease of coding the Shutdown Handler. In the "frame" way, when the user chooses to close the frame it's rather easy to shut-down everything tidily; whereas if it was a console application, handling a Ctrl-C event is trickier.

Since the spec did not specify which items (if at all) need to be configurable, then it is theoretically OK to hard-code the listening port (I'm using sockets) and the data filename as I did.

However still it doesn't seem right to me.

How about you guys? Are you showing some GUI when running the program in "server" mode, so the user can configure it?


Thanks,


Isaac