Mark Secrist

Ranch Hand
+ Follow
since Jul 01, 2003
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mark Secrist

I remember when I was trying to get my first validation project working, it seemed like enabling this was a big mystery. In the end, all I had to do was enable <mvc:annotation-driven> + all the things you said you did. I haven't looked but I suspect that this tag actually enables the validator bean you mentioned.

Mark
8 years ago
You might start here:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/transaction.html#transaction-application-server-integration

The basic idea behind Spring Transaction support is to offer consistency in how you apply transactional behavior to your apps. That means you basically configure the appropriate transaction manager (or look it up using JNDI). Once configured, the @Transactional annotation should work the same.

If you are talking about invoking XA type behavior, I don't know of any examples specifically for that. However, also check out:
http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html

8 years ago
Ultimately, it seems like it comes down to the Spring container not being able to locate the class LoginImplementation. Here are a couple of things to consider.
  • You may have mistyped the full path (package + class name) in the bean definition
  • A classfile may not have been generated since it looks like the isValidUserId method on LoginImplementation should return a value since your method signature says it does


  • Mark
    9 years ago
    It would be helpful to see the code you are using. Can you post the relevant parts?
    9 years ago
    I'm not aware of any books of the 'Head First' style for Spring. I mentioned this on another thread but 'Spring Recipes 2nd Edition' is available now and covers Spring 3.0. I'm still waiting for my copy but the first edition had a nice problem/solution approach, which made learing the material pretty easy.

    Mark
    9 years ago
    First, I 100% agree with Mark (Spritzler). If you can, take the class. It's a great way to go from 0 -> compitent in a very short time. From there, you just need to put it into practice to really get productive.

    There are a few books out now based on Spring 3.0. I'm really looking forward to the SIA 3.0 book but there is already the Spring Recipes 2nd edition, which covers Spring 3.0. I have it on order so haven't read through it yet. If it's anything like the first edition, it should be pretty good.

    If you have the tenacity, the Spring 3.0 documentation is quite good but you have to get through a lot of material before really getting to the point of understanding well enough to be productive. I started on Spring 2.5 and migrated over to 3.0 so the reference docs were nearly enough for me.


    Mark
    9 years ago
    This is probably the crux of the matter.

    This is usually because the library containing this class didn't make it into the deployment. It should be found under WEB-INF/lib in the deployment. In this case, the dom4j-<version>.jar file should be there.

    Alternatively, I've seen cases where the JAR file is deployed but the version is missing expected elements.
    9 years ago
    Have you implemented your own hash() method for BusinessLocation? If you haven't overridden the hash method, the typical behavior is every object (even ones that are technically equivalent) would have its own entry. This sounds almost like you are having your hash method return the same hash for multiple - non equivalent entries. In terms of the order, HashSet does not preserver order of adding so that's probably why you are seeing the order change. Unless you truly need a unique set of entries, I'd consider using List & ArrayList.

    Also, in your JSP, I'm curious where locationIndex is being set?
    9 years ago
    Sorry, was thinking of a java.util.Date, which is what the formatDate tag works with. This will be a little more challenging. One approach I've used for one way formatting (i.e. command to JSP only) is to have a getStringDatetime() method that does the formatting on in the command class. If you need to also bind an entered value back to your DateTime, you'll need to use a property editor.
    9 years ago
    In your first attempt, it may simply be a matter of path mapping (i.e. you have no mapping to define '/myChildWindow.jsp' as being in the real location). In your second attempt, this would fail because the user won't have direct access to any files under WEB-INF so you can't reference that way.

    I haven't tried this, but you may be able to get this to come up simply by creating a mapping. For example, in Spring 3.0, you could add the following to your controller config:

    Then, you could try simply referencing it in your JSP as:
    window.open("myChildWindow.htm","childWinName", <window properties>);
    9 years ago
    Sure, you could use the JSTL formatting tag library to format as you like. For example...
    9 years ago
    You may have solved your original problem already but wanted to mention that I've had fairly good success using a persistent object as my command object even when I have non-persistent attributes used solely for the controller/JSPs. The way to get this to work is to add the 'transient' keyword to the attribute (i.e. private transient foo).

    Mark
    9 years ago
    This session issue can definately cause problems for sure. If you were using Spring 3.0+, there's a nifty @ExceptionHandler annotation you could add to a method that could do the work for you. As it is, you'll need to configure an exception resolver in the bean file for SimpleMappingExceptionResolver. One thought I had was that you could simply redirect back to a known good starting point. The one issue with the SimpleMappingExceptionResolver is that it mapps to a view (i.e. JSP). What you really want is to direct this kind of exception to a path (like your starting path). That would allow you to perform initialization via the controller before directing back to the starting view. This is where the @ExceptionHandler annotation is nice.

    However, a few options come to mind. You could have a look at the classes and interfaces associated with the Spring Exception handler and write your own. Petty much all you would need to do is extend SimpleMappingExceptionResolver and override the doResolveException method. You'd still configure it in the bean file, but it allows you to do initialization if you want before directing to the configured view. Another solution would possibly be to create error definitions in the web.xml file that would map to the appropriate URI.
    9 years ago
    I had written and submitted a whole different response but as I read this, it appears you may want to take a different approach. The thing that makes your requirements interesting is the parent/child relationship between the two pages. You may want to consider a different approach like using JavaScript. It doesn't sound like the second page needs to go to the server to fulfil its function so that might be a better way to do this.
    9 years ago
    Hi Nathan,
    You've asked a lot of really good questions. Let me start with the architecture question first.

    You have a lot of flexibility in how you architect a solution using the Spring MVC approach. A lot depends on the complexity. You might decide to compose a service layer that handles aggregating multiple calls to several DAO objects, which would be responsible for fetching your domain objects. If the service functionality isn't that complex, then it may just make sense to roll that into the controller and have it act as your service layer. The service layer should NOT just be a pass through proxy for calls to the DAO. Methods on the service layer should be more granular and provide cohesive business functionality. A good way to approach this is to roughly sketch the page flow from the user perspective on paper or a whiteboard and then simply begin to work it through to the back end in terms of what data you'll need. As you begin to look at required interactions, you may also begin to see logical groupings of functionality that may make a logical service layer. The controller would then simply be responsible for collecting data from the web page, validating and then calling the correct service functionality to perform the next steps.

    Ok, in terms of the controller the Spring annotation way. I suspect you may indeed be getting tripped up by terminology. The term 'command object' comes from the old AbstractFormController/SimpleFormControler and from a broader pattern for doign MVC (I think Struts also uses this term). Another term that is used is 'form backing object'. This object can be a POJO and it could be a domain/model object and could even have persistence annotations (ala JPA or Hibernate). From here, I think your question is about the origin of this object and that has a lot to do with your approach to this series of pages. I assume from what you've said already that a user (me for example) would come to some starting page (/AboutYou.htm?) and begin filling out information over a series of pages. The implication is that there is a starting page, which will usually be accessed via a GET request. Usually this first invocation is where the command object is initialized. As an aside, if I was doing something similar with a specific instance (i.e. editing a product entry, which implies a product id as the key), I might pass in the product id as part of the initial GET request but initialization would probably result in a populated object (likely from a data store of some kind).

    From there, the user would progress from one page to the next through a series of submits (which are POST requests). You would handle the submit for each page by doing whatever you needed to do (i.e. validating, performing calculations, etc) to set up for the next page. I found the POST -> redirect -> GET approach to work pretty well. The POST handles the binding of the data from the form to the command object. From there, I process the result and redirect to a GET request (same controller) where I prepare for the next page before returning the view to render the next form page. What makes this work is that the command object is a session object that is simply kept available to all invocations to the controller. This is made easier by the annotation based approach as there aren't the same restrictions as with the SimpleFormController.

    Based on what you've posted, a controller to do all this might look like the following


    I hope this helps.
    9 years ago