David Bridgewater

Thanks for that, Henrique.

I think your example code should read "from User where :role in elements(roles)", but I got the picture just fine from what you said. And sure enough, when I extend the code to read something like:

Query query = session.createQuery("from Roles where description = 'manager'");
Role manager = (Role)query.uniqueResult();
query = session.createQuery("from Roles where description = 'systemadmin'");
Role systemadmin = (Role) query.uniqueResult();
query = session.createQuery("from User where :manager in elements(roles) and :systemadmin in elements(roles)");
query.setEntity("manager", manager);
query.setEntity("systemadmin", systemadmin);
List users = query.list();

... it works just fine. (Apologies if the code above doesn't work as written - my real example is in a different business domain, so I'm translating - I think it's roughly right).
The resulting SQL doesn't even look that disgusting - there are a couple of subselects involved, but it's much as I would think of handcoding. The SQL may not be to everyone's taste, but then that's part of the fun of an O/R framework (increasing your DBA's blood pressure...)

Best,

David.

Hi Henrique...
I found your question and posted code enormously helpful.
Now that you are six months on with Hibernate, I'm hoping you might be able to help me with two questions on the "Users and Roles" set up.
(1) What is the best way to answer this question: which users belong in the manager role? (I think I can see my way through on this one - have a set for users defined on Role; just the reverse of what you already have for User).
(2) Trickier: what is the best way to get a list of users belonging both to the manager AND the systemadmin role? If I were writing the SQL directly I would have no problem... but how best to make Hibernate do the work?
Any thoughts you have would be gratefully acknowledged!
Many thanks,
David Bridgewater.

Hi,

No, I don't see why answer D is correct. It might make sense for SmilyTag to implement the BodyTag interface, but it doesn't have to - it can legally implement (just) the Tag interface.

Furthermore, there's nothing in the question to indicate that SmilyTag couldn't be a simple tag - in which case it could not implement the BodyTag interface, and tagdependent would be the natural choice for <body-content>.

Don't take my word for it though... I may be missing something vital. Anybody else out there agree / disagree?

Best,

D.

Hi...

Interesting thread. I have just managed to complete my first book, and wanted to pick up on some of the themes here.

I checked my personal timesheet... 916 hours and 54 minutes. Time will tell whether the book is any good or not - but I concur with Bert's 1000 hours. I could not (or would not) have done it along side a full-time job; the rest of my life (family, health, sanity...) would have suffered too much.

I found the book "On Writing Well" (by William Zinsser) very helpful. He addresses the question that Rick Portugal brings up - how to write clearly and yet remain interesting. He also explains how to write non-fiction without having to losing your own voice in the process. For that reason, I'm a huge admirer of the "Head First" series - because they combine accurate and compelling writing with huge (and sassy) personality. But I don't figure on trying to emulate the "Head First" style, because it wouldn't sound right (not from a straight-laced Brit like me!).

And Marzo - good luck. The will to write the book is the most important thing!

Best,

David.

Jack...

Are you including or forwarding from a.jsp to b.jsp?

I think you are on a hiding to nothing if you try to mix two encodings in the same response; that's what I understand by this line from the JSP spec...

"Note that the response character encoding can only be changed until the
response is committed."

So my guess is that you will be OK with forwarding, but die a horrible death (or not get the response you want) with including.

Anybody?

D.

Alex...

I would recommend that you give a few more details of the code (servlet or JSP?) which is receiving the uploaded file.

Also, even though it hasn't been updated in a while, I would check out the famous multipart upload free code written by Jason Hunter (co-author of Java Servlet Programming, O'Reilly).

HTH -

David.

Vlad...

I would go for a trusted applet embedded in the JSP page.

Whether or not this is a good approach for you depends a bit on your user base (will they get along OK with applets? Will they have an up-to-date plug-in their browser?).

But at least with an applet you can avoid altogther the Open/Save/Cancel dialog normally presented by your browser.

HTH -

David.

Rewa,

That will depend on the application server you are dealing with.

I happen to be familiar with IBM WebSphere Application Server. As an administrator, you can switch on session replication across the running instances of your distributed application (and there are different options with different performance/failover trade-offs). You also have some configuration to do in the associated web server (usually IBM Http Server).

I don't know the answer for open source application servers, but I think you will find plenty of resources to help you. Here is a thread which talks about clustering with Tomcat (as the web container) and Apache (as the web server):

ServerSide.com discussion on Tomcat / Apache clustering

Whichever tools you are using, you shouldn't have to alter your coding approach - the session object should be up-to-date and available to whichever running instance your requests go to.

HTH -

David.

Hi...

On 1 - as I understand it, encodeURL() and encodeRedirectURL() just affect the Strings passed in (they may or may not append jsessionid information); they definitely don't perform any redirection themselves. The reason for having two methods, not one, can be found in the API documentation for HttpServletResponse.encodeRedirectURL():

"Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged. The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL. Because the rules for making this determination can differ from those used to decide whether to encode a normal link, this method is separete from the encodeURL method."

On 2 - use of jsp:root is one of three approaches for telling a web application that it is dealing with a JSP document. Most web containers running at servlet 2.4/jsp 2.0 level will automatically interpret a file with a .jspx extension as a JSP document. Also, you can manualy specify in the deployment descriptor (using the <jsp-config> tag) which URL patterns should be interpreted as JSP documents.

Sadly, I can't help with 3.

HTH -

David.

Hi Dave,

I can't point you to any articles or tried-and-tested approaches, but your question is interesting.

Here is a thought off the top of my head - how about storing some kind of Map (keyed by user id) of user information in the application context? This would work (a) if all the activity is confined to a single web application, and (b) if there is one running instance in your application server. However, on (b) - you mention the word "cluster" - and whereas application servers usually provide session replication across members of a cluster, none that I know of provide context replication. Mind you, I have led a sheltered life.

I would probably go for a database approach, though. Instead of fighting through an EJB layer, could you go for a separate, light-weight database server located close to (preferably on the same machine as) your application server? Its sole purpose would be to accumulate your user's "session" information which hasn't yet been committed to the real database.

Let us know what architecture you opt for in the end.

Best regards,

David.

Afterthought (having read the original question more carefully)... what is wanted here is for the database to update information within the web applicaton. If the database supports it, I would add a trigger which fires when a row is added. The trigger program could send an HTTP request to a servlet, probably including data from the newly added row. This saves the bother of the servlet re-reading the table.

Also, you don't then need a separate program which wastefully polls the table when nothing has changed.

Hope that makes sense.

Best,

David.

I'm probably way out of line here... but looking at William's point (start your own thread)... don't some web containers resent you starting your own user-defined threads? I can't find anything in the J2EE servlet spec that says you can't do this, mind (I just recall an IBM development tool that identifies this as "bad form").

If there are compelling reasons to place the "every minute" processing in a servlet, I could think of a couple of approaches...

(1) Have a servlet which loads-on-startup, but has no servlet mapping. The every-minute process is called by the init(ServletConfig config) method, which runs a perpetual loop that performs the process and puts its thread to sleep for a minute.

(2) Have the process in a regular servlet. Have a completely separate piece of Java code (an application running in its own JVM). A process in this wakes up every minute, and fires an HTTP request to run the servlet.

Best,

David.

Anand,

Maybe you could explain why you want a singleton servlet - what is the requirement driving you towards a singleton servlet as a solution?

Apart from David O'Meara's point (you shouldn't try to force servlets to be singletons, or you may break the web container), singletons in general become difficult or impossible to manage if you decide to make your web application distributed.

Best,

David.

Hi Vishnu:

"Only in the 3rd step valueUnbound() is called which use "this.breed". Here the result should be "Great Dane" but how we are getting Beagle"

There are two, separate Dog objects. The Dog objects themselves are also separate HttpSessionBindingListeners.

Maybe you are thinking that the valueBound()/valueUnbound() methods are being called all on the same object?

Best,

David.

Hi Vishnu...

If you are running the original ListenerTester code, then I think this is what happens. Here are the relevant lines from ListenerTester:

21: session.setAttribute("foo", new Dog("Beagle"));
22: session.setAttribute("foo", new Dog("Great Dane"));
23: session.setAttribute("foo", new String("z"));

At 21, "foo" is set with a new instance of Dog (breed Beagle). valueBound() is called on this Beagle instance.

At 22, "foo" is reset with another new instance of Dog (breed Great Dane).
valueBound() is called on this new Great Dane instance (this.breed == Great Dane)
valueUnbound() is called on the previous Beagle instance (this.breed == Beagle)

At 23, "foo" is set up as a String, not a Dog.
valueUnbound() is called on the Great Dane instance (this.breed == Great Dane).

Please let me know if you agree with this!

Best,

David.