Tomasz Szymanski

Wouldn't this work?
select u1.name from User u1, User u2 where u1.organization.id = u2.organization.id and u2.name = :name

OK, so you're constructing a real proxy. I was thinking of a simple wrapper, something like ServletRequestWrapper or ServletResponseWrapper. Something like:

class ServletContextWrapper implements ServletContext { private ServletContext ctx; private Map<String, String> myInitParameters; ServletContextWrapper(ServletContext ctx) { this.ctx = ctx; myInitParameters = new HashMap<String, String>(); // init the parameters, iterating through those in ctx and processing them with your ParameterSubstituter } // many methods here, most of them just delegating to the original ctx, eg: public void setAttribute(String name, Object value) { ctx.setAttribute(name, value); } public Object getAttribute(String name) { return ctx.getAttribute(name); } // etc., but of course: public String getInitParameter(String name) { return myInitParameters.get(name); } }

But actually that would be a much longer piece of code than yours, I guess So... what's the problem anyway? Isn't your solution sufficient?

I'm pretty sure you can't manipulate the init parameters in a container-independent way. There is simply no standard API for this.

One of the things I can think of is using your own ServletContext implementation, that would wrap the original one and implement the getInitParameter method appropriately. Is that what you meant by "proxy"? Have you tried it?

So your SUMMARIES table behaves just like for example a table with identity column in MSSQL: when doing an INSERT, you leave the primary key unspecified and it's generated by a database mechanism.
I may be wrong but I think @GeneratedValue with IDENTITY strategy should work well. I'd expect it to issue an INSERT without the PK value and then retrieve it immediately. Have you tried it?

If you can't keep the session open (following the "Open session in view" pattern; check this article out), your service is the one to take care of preparing the transfer object properly. That is - loading all the data you will need in the view layer.
You don't have to return any new, separate collection. You may return just the entity, however forcing Hibernate to fetch the lazy associations you want.
One way you can do it is by using a query hint (select p from parent p join fetch p.children).

Why are you using upper case for the hibernate-configuration, session-factory and mapping tags? Where did that come from? The first thing I would suggest is rewriting them in lower case.

Or you could simply use the RequestDispatcher.include method. Although "simply" might not be the best word, because I guess you would have to pass your own ServletResponse object that would let you capture the result (see the javax.servlet.ServletResponseWrapper class). But it still looks a bit simpler than HttpClient to me.

Why do you expect na error? The servlet produced from your JSP will extend only one class: either your custom class if you specify it in the page directive, or some container-provided class if you don't.

I suppose you are using the single-parameter save() method, right? Something like:

session.save(selectableItem);

That method is overloaded. Maybe you could try using the other version, with the entityName parameter. Like:

session.save(Item.class.getName(), selectableItem);

I haven't used it, so I'm not giving any guarantee, but I have a feeling it might help.

I don't think flush() is actually needed. Commit should do it.

Your question is clear. Apparently my answer wasn't ;-)
So to cut it short, try doing two things:

1. remove the following lines from your code:

employee.setEmpId(1);
department.setDeptId(1);

2. at the end of your code, first commit, then close the session

It depends on what you mean by "it's working"...
Not using a transaction will not get you an exception - in that sense it's working. The problem is that whatever you do, it's cancelled as soon as you close the session (unless you have a non-transactional DB, as Christian mentioned, or you're working in the autocommit mode). Although, to be precise, according to this article, it's not 100% sure.
It seems that's exactly what's happening in your DeleteQuery,

raunak saxena wrote:
IS there any way, when I save employee object then it’s associated department object is automatically saved provided it’s not there department table previously?

Yes, there is: cascading. And it should work in your example, because you've mapped the department with cascade="all" in your employee entity. Why isn't it working? I see one major thing that you're doing wrong: you're manually setting the identifier values in the employee and the department.
Since you've set up the generators for both of them, just let them do their job ;-) You should leave the identifiers at 0, because that's what you've declared as the unsaved-value.

But then... I bet it'll throw another exception, related to the order in which you're finishing the transaction. If it does, you'll probably figure out why.

Varun Nayudu wrote:
My question is why is the standard action and EL not working and displaying the name .......

Because obviously the bean is placed under "pObj" in the request scope. Under what attribute name do you think the standard action and the EL expression are trying to find your bean?

That's what I meant, Jeanne - I was wondering whether you can rely on any particular class loading order. And thus - if it's theoretically possible to "patch" a web application without replacing an old JAR, but by adding a new one, which would kind of override the old one. But from what you both said - it isn't. Thanks, both of you.