Rosco Duncan

Clearly I'm missing something here, but what makes this a J2EE application. I thought a J2EE application had to have an EJB module, web module, client module or (forgot the fourth one)

There could be many reasons to want to deploy to a J(2)EE application server, but I imagine that they all pretty much boil down to wishing to make use of services provided to code running in such an environment. This could be the services of an ejb container, and/or a web container, or simply to make use of some of its service abstractions such as managed datasources or the transaction manager.

I think Rod Johnson and co were have been fairly successful in their attempts to convince the enterprise java community that there is J(2)EE life outside the ejb container

http://www.amazon.com/Expert-One-One-Development-without/dp/0764558315

Ditto what Mark said about using Spring Security.

However, you might get past this exception if you take the scope="session" off of your login bean

Hi Dan,

Ive just been looking back at the step-by-step example for Spring MVC.

If you havent taken half a day to walkthrough this, I would thouroughly reccommend it to you.

Anyhow, I find http://static.springframework.org/docs/Spring-MVC-step-by-step/part4.html#step4.5 interesting. Note here they are using Spring MVC in a very straight forward manner - no annotations or other trickery. The <form:form> tag does not include the action at all. Its not mandatory for Spring, but probably for HTML. Im guessing Spring generates this.

Also look at the way the controller is configured and coded (here). Note that they are setting sessionForm to true, and specifying the command class. (you are probably doing somethign like this already). In the java for the form controller the method formBackingObject initialises the command object.

Im not sure which bit of the puzzle you are missing, but if you arent making progress, I would get this walkthrough working and compare it to what you have got. If you havent already, the experience is well worth the effort.

Hope that helps.

Rosco

Yep, sounds like you are on the right track.

Your model class will probably start with just getters and setters for the various proerties that your object is modelling. In the case of Person that I used earlier, it would just be getters and setters for firstName and lastName.

For now you just want to put the database access code into the servlet as this is your Controller. When you are just thinking about MVC like this, then the sevlet is the right place because it is doing all of the Controller role. You should note tho that most modern java MVC webapps flesh out the Controller side of things a lot more than just a simple servlet. While there is always one or more servlets involved, data access like what you are doing here with JDBC is usually delegated to a separate layer (or layers) of code. The classes in this layer are often know as Data Access Objects (DAOs), and are simply responsible for persisting and loading the model objects from the database.

These days you are also well advised to familiarise yourself, and probably ultimately use a web framework like Spring MVC or Struts. These take the Model View Controller pattern and give you a lot of support for the sorts of things you will find yourself doing time and again.

Good luck!

Hello there,

That is a very good question with respect to MVC.

As I understand it, generally speaking, the conroller will usually handle the request, resolve your model object and pass it to the view for display. In the scenario you have, the controller handles the request, creates a shell model object (ie it has no data of its own) and is allowing the model object to dynamically access additional data via the database connection. While there is nothing wrong with doing this, you should consider whether or not the data you are looking up is really related to that model object, and if so, whether it could have been loaded up by the controller as part of its resolution of the model object.

Possibly this would be more obvious if your model object was a little more realistic. Consider a Person class which has fields firstName and lastName. If you also had a PersonController class, this would handle the request by looking up the person data (first name and last name) in the database, create a Person object (instance of the Person class) with the firstName and lastName data, and pass this on to the appropriate view. Once you have this, do you really need your particular person to access any more from the database?

IMOP I think you should leave the database access code in the Controllers if you can. There are some architectures where the model object may be able to dynamically lookup (lazy load) some of its properties, perhaps for efficiency reasons, but this is an exception to the rule. In such cases it would then be good practice to pass the model object some sort of interface to a repository rather than the jdbc connection itself. This is because its ususally good practice to shift out any specific persistence logic away from the core classes. Technologies like Hibernate come in handy here.

Does this make sense?

Hello there,

That is a very good question with respect to MVC.

As I understand it, generally speaking, the conroller will usually handle the request, resolve your model object and pass it to the view for display. In the scenario you have, the controller handles the request, creates a shell model object (ie it has no data of its own) and is allowing the model object to dynamically access additional data via the database connection. While there is nothing wrong with doing this, you should consider whether or not the data you are looking up is really related to that model object, and if so, whether it could have been loaded up by the controller as part of its resolution of the model object.

Possibly this would be more obvious if your model object was a little more realistic. Consider a Person class which has fields firstName and lastName. If you also had a PersonController class, this would handle the request by looking up the person data (first name and last name) in the database, create a Person object (instance of the Person class) with the firstName and lastName data, and pass this on to the appropriate view. Once you have this, do you really need your particular person to access any more from the database?

IMOP I think you should leave the database access code in the Controllers if you can. There are some architectures where the model object may be able to dynamically lookup (lazy load) some of its properties, perhaps for efficiency reasons, but this is an exception to the rule. In such cases it would then be good practice to pass the model object some sort of interface to a repository rather than the jdbc connection itself. This is because its ususally good practice to shift out any specific persistence logic away from the core classes. Technologies like Hibernate come in handy here.

Does this make sense?

Hmmm,

I guess you must have a different version of something around the tab lib.

What happens if you set the action=confirmSP.do

Im assuming confirmSPFormController contains the submission hander method where you are hoping to see your hidden fields populated?

Just a thought Dan, but you currently are setting action=""

What happens if you leave out the action attribute altogether?

When I do that, Spring automatically generates one for me that gets me happily into the appropriate controller method. It ends up lookng like this when generated:

action="/myApp/search.htm"

I have a controller the looks like this (using spring 2.5 and attributes):

/** * Setup the search form * * @param request The standard HttpServletRequest * @param model The model * @return */ @RequestMapping(value = "/search.htm", method = RequestMethod.GET) public String setupForm(HttpServletRequest request, ModelMap model) { ... //do some stuff with the model model.addAttribute("myAttribute", "Bob's your Uncle"); ... return "searchForm"; } /** * Handle submission of the search form * * @param modelMap The model * @param searchCriteria The criteria to search on * @param result The place holder for the result * @param status The status of the session * @return The model and its corresponding view (search results) */ @RequestMapping(method = RequestMethod.POST) public ModelAndView processSubmit(ModelMap modelMap, @ModelAttribute("searchCriteria") SearchCriteria searchCriteria, BindingResult result, SessionStatus status) { //do some stuff with the submitted form data }

Hi Emili,

Just a few random things that might be worth checking:

a) Are the http sessions getting closed and disposed of? ie is logout really killing the http session
b) Is your DAO closing hibernate sessions?
c) If you repeatedly log in, and straight away log out without doing anything, do you still see this problem, or does it only occur when the logged in user has tried to do something meaningful?

Not sure I can without profiling tools, but could be a few useful places to start.

Good luck

Hello there,

That is an interesting sounding question.

Can I ask what mechanism/technique you are using to reload the application context?

Vishal Pandya wrote:No, it's not related to Dispatcher Servlet. It would be your war file name i.e. poc.
It seems that you are using Apache Tomcat. You can navigate to Tomcat Manager and you should find your application entry there. Click on that and see what URL comes up.

You can also explicitly Specify you application name using
<display-name>YourAppName</display-name>
entry into web.xml.

@Rosco,
http://localhost:8080/MyApplication/poc
I am unable to understand what would be the value of 'MyApplication'?

Its just a place holder for whatever the war file has been called. So in this case it is 'poc'

I think it would be worth trying to navigate to the following URL if you want to be picked up by the Dispatcher Servlet, as I suspect the '/poc/*' that it is mapped to will fall within the '/poc' context that the application is running as.

http://localhost:8080/poc/poc

I could be wrong.

No, by default it is the name given to your war file. So if you are producing MyApplication.war, try navigating to http://localhost:8080/MyApplication/poc

See if that works for you.

Cheers.

You are missing the web context from you URL


It should look something like http://localhost:8080/{your app name here}/poc/

Good luck

You are missing the web context from you URL


It should look something like http://localhost:8080/<your app name here>/poc/

Good luck

Its difficult to answer this question specifically without knowledge of how both AdvantageGen and your java application access the database.

However generally speaking, you need to be very careful when attempting to share a database between multiple applications. When applications are written, the author usually has in mind whether or not the application is to have exclusive access to the database in question or not. When an application expects to have exclusive access then often it can take additional liberties when it comes to caching data, and optimistic locking for the purposes of optimisation. Attempting to share databases where this is the case, can undermine the existing application.

So sorry no easy answer. You need detailed knoweldge of the data access of both applciations.