Klaas van Gelder

In my Spring MVC project I use Tiles to eliminate any redundant page structure code. As a view renderer, I first chose Thymeleaf because it was descreibed as a primising new kid on the block and pretty easy to use.
Unfortuantely, the integration of Thymeleaf with Tiles depends on deprecated Spring (Tiles2) classes, furthermore the only Thymeleaf forum is almost inactive and questions mostly remain unanswered.

Therefore I want to switch to Freemarker because it has a well established user community and is also supported by Spring. But the configuration of the integrated Spring MVC, Tiles3 and Freemarker is apparently not documented and most examples on the internet are using Tiles in combination of JSP or Freemarker without Tiles, but I cannot find a clear, working integrated example.

I am not very experienced with Spring MVC and confugurations, but I think the following issues must be addressed:

-Loading the Tiles definition file. According to some examples, it can be done using following method in the MvcConfig class:

@Configuration @EnableWebMvc @ComponentScan(basePackages = "nl.drsklaus.activiteitensite.web") public class MvcConfig extends WebMvcConfigurerAdapter { ...other methods @Bean public TilesConfigurer tilesConfigurer() { TilesConfigurer tc = new TilesConfigurer(); tc.setDefinitions(new String[] {"/WEB-INF/views/tiles/defs/tiles-defs.xml"}); return tc; } }

-Resolving the returning String from a controller method to a Tiles definition:

This should be done using following method in the MvcConfig class: @Bean public ViewResolver tilesViewResolver() { TilesViewResolver viewResolver = new TilesViewResolver(); viewResolver.setViewClass(TilesView.class); // viewResolver.setOrder(1); return viewResolver; }

My first question is whether this Tiles view resolver should be in some way "Freemarker-aware". According to the Tiles documentation, the attribute 'type="freemarker"' should be added to the <definition> tag as well as to the <put-attribute> tags in the Tiles definition XML file, but is it unclear to me what is the effect of that.
Furthermore, the fragments as referenced in the value attribute of those put-attribute tags must be parsed as Freemarker templates instead of JSP. I do not see how this should be configured.

In fact it is unclear to me how the lookup/resolving proces from a Tiles fragment in Spring works. Is the extension .ftl anough for Spring to know that is should look for a Freemarker template?

Some examples lists code fragments like these:

@Bean public FreeMarkerConfigurer freemarkerConfigurer() { FreeMarkerConfigurer configurer = new FreeMarkerConfigurer(); configurer.setTemplateLoaderPath("/WEB-INF/views/freemarker"); configurer.setDefaultEncoding("utf-8"); return configurer; }

Is this method enough for Spring MVC to load the Freemarker templates from the Tiles definition? How does Spring "know" that a template referenced by Tiles is actually a Freemarker template? There also exists a FreeMarkerViewResolver class which extends UrlBasedViewResolver. But is is unclear to me whether and how we should use this class.

I hope for some clarification and maybe even an integration example

Spring MVC, Signup, Edit personal and Password forms

My Spring MVC application is a website where members can subscribe to indoor and outdoor activities, organized by a member. THe application therefore needs a well-known funcionality to sign up, login and edit/modify personal details. I used Spring MVC in combination with Thymeleaf views. THis works fine but I am struggling with the different forms and try to avoid redundant fields.

The following use cases are required:

Sign up: User chooses a username, password en password confirmation and personal details like birth date, gender, city, personal interests. After submitting the form, form validation checks whether username is not in use and passwords fields are equal.

Edit personal data: When logged in, the user can choose to edit his/her personal data. Username cannot be changed (and is therefore invisible or at least immutable in this form) and password fields are not shown.

Edit password; To change the password, the logged in user enters his existing password for extra security, and the new password and the confirmation of the new password. After committing, the existing password is verified and changed afterwards if and only of the new password and confirmation are matching.

I think this is pretty common functionality. But my issue is that we have only one Member class that can act as the form-backing object (The Spring MVC documentation advises against the use of separate form backing objects). Besides, the password is not stored as the plain entered text, but as the (SHA-256) hash.

For the signup use case, I choose the following approach: THe Member entity object contains one mapped field for the hashed password (which is persisted in the database) and two transient fields for entering the password which are bound to the form and validated for being equal and match other criteria (minimum length, special characters etc):

@Entity @Table(name="member") public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private int id; @Size(min=3, max=25) @Column(name = "loginname", nullable = false, updatable = false) @NotEmpty private String loginName; @Transient private String registerPassword; @Transient private String retypeRegisterPassword; @Column(name = "password_sha256", nullable = false, updatable = false) @NotEmpty private String passwordHash; ... more fields, getters and setters
In the intitial signup form, the new user enters his username, password (Twice) and all other required fields. This works as expected.

But what if the user wants to edit his personal data? We do not want to edit the username and password fields in this scenario. The other fields need to be validated according to the same rules as the signup form. So we should need: 1) A separate form backing object, mimicking the Member object but without username and password fields. This sounds unacceptable to me due to redundancy. 2) Or use the same form backing object but somehow bypassing the username and password fields in the validation. Of course, those fields must be preserved when saving the member object back to the database using Hibernate, but we can make a customized update method in the service layer to handle that.

And the last use case is modifying the password. For this I want a separate form with 3 fields, the original password for extra verification and two fields for the new password and its confirmation. I think I should use a separate form backing object for this containing only those 3 fields, but do not want to duplicate the field and validation definitions.

Is there a clean way to do this without redundant definitions? Hope for some thoughts...

Interesting answer. I also make use of separate Service and DAO layers where each service method is transactional (by use of the Spring @Transactional annotation).

As I understand you correctly, you do advice against the use of lazy fetching of objects with child dependencies. I see some overlap with my suggestion in the first post to remove the collection fields from the Activity and Member classes and create a separate (ActivityMemberSubscription) entitiy class which maps to the link table. Then all queries can be done against a single table (apart from the lookup fields which can be eagerly getched without problems) and within the service method, the results can be combined.

The question is whether the child collections are still modelled in the entity classes. You write
"For example, if I have an A class that relates to a Y class with children of class Z, the service method can do a fetch of a selected A with its associated Y and Zs. This is returned as a detached graph of entities"

Does you mean that child collection fields are still present on the parent entities but only populated in the service methods by using multiple queries in a service method? And therefore write separate service methods to obtain, for example, a "naked" member object without its child activities and another service method to get a fully populated Member object with its activities?
Or

Also I want to mention that the Member object is saved in the session during login. I have the feeling that this should not be a complex object with child entities which can get stale and out of sync very quickly.
MAybe this is a case where a lazy fetch "naked" Member object should be used.

I think this is the way to go and it feels better than the "open session in view" method...

Tim Holloway wrote:Open Session in View is indeed a horrible thing. Because the session is open for the duration of the request/response cycle, you can accidentally zap data in the database, to say nothing of potential performance and security problems.

What I do is to work with a 2-tier persistence architecture. Within those 2 tiers, you have full persistence connectivity. Outside those tiers, you are disconnected (detached). The boundary between the persistence tiers and the higher app tiers (business logic) is also the transaction extent.

The upper persistence tier is the "service" layer. The methods in that layer are all transactional. That is, when you invoke one of those methods, you begin a database transaction and when you exit the method, the transaction is committed (or rolled back, in case of failure).

The lower persistence tier is the DAO layer. A DAO class handles the CRUD and Find functions for a single database table. Or in some cases, a parent/child table. The DAOs inherit their transaction context from the service tier methods that invoke them.

The reason for having 2 tiers is to allow my basic table operations to remain simple. They're all done in the DAOs. The service methods, on the other hand, handle complex table interrelationships. For example, if I have an A class that relates to a Y class with children of class Z, the service method can do a fetch of a selected A with its associated Y and Zs. This is returned as a detached graph of entities. The application code can then display and/or modify this graph. If it modifies the graph, then there's typically a "save" method in the service tier that then takes that updated graph and invokes the DAO methods for the objects in that graph to cause it all to get posted to the database.

In some cases I'll have more than one service-tier fetch method. It will typically be named something like "findXXXWithYYYY" or "findXXXWithChildren". That allows me to define a simple lazy-fetch find to get basic info, and a deep-fetch find when I need details.

The deep-fetch find will either manually reference the secondary objects to force-load them (since it's dealing with connected objects) or in cases where the ORM system supports "fetch sets", it may invoke a fetch set that includes the items that in the default fetch are lazy-load.

Yes I had indeed read about this technique but it seemed pretty much of an ugly hack to me because the Hibernate layer should be abstracted away behind the Service layer, as you also point out in your answer. But I understand it is probably the only way to be able to fetch those lazily initiated collections.

And that leaves the choice between using this technique or remove the many-to-many associations completely and make a domain object for the link table (what I probably have to do anyway because I need to put some addional fields in the link table, like the datetime of subscribing to an activity).
Still not an easy decision... :-s

Karthik Shiraly wrote:The technique I always use to overcome this is the "open session in view" servlet filter. It's a well described solution on the net; just search for it.
It's a servlet filter that opens a hibernate session as soon as request is received, stores it in thread local variable and retains the session until the reponse goes out via same filter.
Just add it to your web.xml.
Hibernate sessions will now remain alive for the lifetime of the entire request-to-response chain, including JSP/other view rendering, rather than lifetime of just the DAO method.

It's not the neatest of solutions because a DAO layer concept is leaking into higher layers, but then hibernate has always been slammed for its leaky abstractions and this is yet another one.
On the plus side, it does keep the OR model clean (without it, one would have to do all the link table trickery you've mentioned), while also optimizing SQL fetching and caching.

Thanks for your reaction. I mean iteration is impossible because the call to the collection variable fails with a LazyInitializationException.

For example in the controller:

@RequestMapping(value = "/{activityId}", method = RequestMethod.GET) public String getActivityDetail(@ModelAttribute("loggedinMember") Member member, @PathVariable("activityId") int id, ModelMap model) { Activity activity = service.findActivityById(id); model.addAttribute("activity", activity); model.addAttribute("canSubscribe", ! (activity.getParticipants().contains(member) || activity.getOrganizer().equals(member))); model.addAttribute("canUnsubscribe", activity.getParticipants().contains(member)); return "activitydetail"; }

The call to activity.getParticipants() already fails because the collection is fetch lazily (and Hibernate session is closed after returning from the DAO method.)
Same problem by accessing activity.participants in the view for showing the participants of an activity.

So basically accessing the colleciton variables is impossible when they are configured as lazily fetched, and setting all fetching to eager is a bit of "fetching the whole database" with all problems this can cause.

Karthik Shiraly wrote:Setting the fetch types to LAZY however make it impossible to iterate over the activities for a member, or the members subsribed to an activity...
Can you elaborate where exactly you are facing this problem? Some code would be helpful.
While I agree lazy init exceptions are a nuisance, I'm not able to think of a scenario where it makes iteration impossible.
Since they occur when hibernate proxies are accessed outside hibernate sessions, they are indicators that something may be lacking in your design.
As I see it, it's the same optimization that we'd do manually when using regular SQL JDBC queries, that is, don't fetch data which is not needed right now.

Many posts are available about the dreary LazyInitializationException and how to prevent it. But the many different answers have not made thing very clear and I am struggling for the right approach.

My web application is centered about the Member and Activity class where the logged in member can organize (in- or outdoor) activities where other member can subscribe for. So there is a n:m (many-to-many) relationship between a MEmber and an Activity, which is mapped by Hibernate to a link table:

@Entity @Table(name="activity") public class Activity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Integer id; @ManyToOne(fetch = FetchType.EAGER, cascade=CascadeType.ALL) @JoinColumn(name="organizer_id") private Member organizer; @Size(min=5, max=50) @Column(name = "title", nullable = false) private String title; @Size(min=5, max=500) @Column(name = "description", nullable = false) private String description; @ManyToOne(fetch = FetchType.EAGER) @JoinColumn(name="category_id") private ActivityCategory category; @ManyToOne(fetch = FetchType.EAGER) @JoinColumn(name="region_id") private ActivityRegion region; @ManyToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY) @JoinTable(name="member_activity_subscription", joinColumns = {@JoinColumn(name="activity_id")}, inverseJoinColumns={@JoinColumn(name="member_id")}) private List<Member> participants = new ArrayList<Member>(); (more field, getters & setters)


@Entity @Table(name="member") public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private int id; @Size(min=3, max=25) @Column(name = "loginname", nullable = false) @NotEmpty private String loginName; @Column(name = "password", nullable = false) @Size(min=6, max=25) @NotEmpty private String password; @NotNull @Column(name = "firstname", nullable = false) private String firstName; @Column(name = "lastname_prefix") private String lastNamePrefix; @NotNull @Column(name = "lastname", nullable = false) private String lastName; @ManyToMany(mappedBy="participants", fetch = FetchType.LAZY) private Set<Activity> activities = new HashSet<Activity>(); (more field, getters & setters)


Because the activities for a member as well as the subscribed members for an activity must be shown in the applicaiton, I modeled it with a bi-directional many-to-many relationship as visible in the Hibernate annotations.

In the code above, the fetchtypes are set to LAZY because I fear an explosion of fetched entities: after obtaining a Member from the DAO, all his subscribed Activities are fetched, with each of those Activities fetching their own subscribed Members respectively. Because the application needs to be scalable to hundreds of Members with hundreds of Activities each, I think this kind of "recursive fetching" can quickly generate a very big object graph and subsequent performance and/or memory problems.

Besides, the logged in Member instance is saved in the session as long as the member is logged in and I am afraid that this can cause synchronization problems.

Setting the fetch types to LAZY however make it impossible to iterate over the activities for a member, or the members subsribed to an activity...

Some solutions are discussed on differnt fora: some advice to always use EAGER fetching (and thereby ignoring potential memoy problems) and other articles advice against the use of xxx-to-many relationships in cases were hundreds of child records need to be fetched.
See http://www.javacodegeeks.com/2011/10/avoid-lazy-jpa-collections.html. THis article discusses the possibility to omit the whole relationship and make separate Hibernate queries for those collections which can be safely obtained using separate DAO calls (maybe within one service method and transaction). Only in the case of simple lookup relationships with a limited number of records, such as the Category and Region fields in my Activity class, eager fetching is adviced.

But then the domain model does not really mirror the real-life relationships anymore. Also, queries for adding Activities to Members and vice versa need to be written manually, maybe by using a separate entity class for the link table .
Any thoughts about this?

Thanks, this was indeeed the information I was looking for!
My implementation of a Formatter is a little different because of the way Thymeleaf compares the list of <select> values with the "value" attribute value to automatically generate the "selected" attribute.

My formatter lo looks like:

public class ActivityCategoryFormatter implements Formatter<ActivityCategory> { @Override public String print(ActivityCategory ac, Locale locale) { // TODO Auto-generated method stub return Integer.toString(ac.getId()); } @Override public ActivityCategory parse(final String text, Locale locale) throws ParseException { // TODO Auto-generated method stub int id = Integer.parseInt(text); ActivityCategory ac = new ActivityCategory(id); return ac; } }

and is registered to Spring (together with the ActivityRegionFormatter for the other lookup field) by:

@Override public void addFormatters(FormatterRegistry registry) { //registry.addConverter(new LookupConverter()); registry.addFormatter(new ActivityCategoryFormatter()); registry.addFormatter(new ActivityRegionFormatter()); }

And now it works as expected!

The only remaining issue is that we have some code duplication because the two Formatter classes are almost the same, they only differ in the generic class that is passed in.
I tried to solve this by using a common interface LookupEntity which is implemented by the two lookup entity classes (ActivityCategory and RegionCategory) and use this common interface to define the formatter but unfortunately that did not work...

And yes I fully agree with you that the Spring documentation is not very clear about this... just as the documentation of many other frameworks and tools!

Karthik Shiraly wrote:Perhaps you can try the Formatter solution described in this blog.

If you are wondering (like me) why Formatters instead of Converters, I found this paragraph in spring docs useful:

consider the type conversion requirements of a typical client environment such as a web or desktop application. In such environments, you typically convert from String to support the client postback process, as well as back to String to support the view rendering process. In addition, you often need to localize String values. The more general core.convert Converter SPI does not address such formatting requirements directly. To directly address them, Spring 3 introduces a convenient Formatter SPI that provides a simple and robust alternative to PropertyEditors for client environments.

In general, use the Converter SPI when you need to implement general-purpose type conversion logic; for example, for converting between a java.util.Date and and java.lang.Long. Use the Formatter SPI when you’re working in a client environment, such as a web application, and need to parse and print localized field values. The ConversionService provides a unified type conversion API for both SPIs.

(Off topic: Is it just me or is Spring documentation one of the most confusing works of software documentation out there?! It confuses me far more often than it clarifies!)

I am still struggling with Spring MVC with what should be a fairly straightforward problem but what seems to be sparsly documented in Spring MVC documentation.

My project uses Spring MVC and Thymeleaf for the views, but the view rendering engine is not really relevant to the problem.

My application is centered around an Activity class which models an (indoor or outdoor) activity which is organized by a member and where fellow members can subscribe to. An Activity has, among others, a Category field and a Region field, which are dropdown fields which are modeled by Hibernate as many-to-one entities to DB lookup tables which contain an id and description field.

The code for the Activity entity class is as follows, the non relevant fields are omitted to shorten the code:

package nl.drsklaus.activiteitensite.model; //imports @Entity @Table(name="activity") public class Activity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Integer id; @ManyToOne(cascade=CascadeType.ALL) @JoinColumn(name="organizer_id") private Member organizer; @Size(min=5, max=50) @Column(name = "title", nullable = false) private String title; @Size(min=5, max=500) @Column(name = "description", nullable = false) private String description; @ManyToOne @JoinColumn(name="category_id") private ActivityCategory category; @ManyToOne @JoinColumn(name="region_id") private ActivityRegion region; @ManyToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER) @JoinTable(name="member_activity_subscription", joinColumns = {@JoinColumn(name="activity_id")}, inverseJoinColumns={@JoinColumn(name="member_id")}) private List<Member> participants = new ArrayList<Member>(); //getters and setters @Override public int hashCode() { ... } @Override public boolean equals(Object obj) { ... } }

In the view, the user should be able to select a Region and Category from a select box. THe options are put in the Model using a @ModelAttribute annotated method on the class level.

THe problem is with the binding of the box to the lookup property fields.

For example the Category field is of the ActivityCategory type, which is an entity class containing an id and a description property.

In the view, the select box is filled with the list of possible options (allCategories which contains ActivityCategory instances), Thymeleaf takes care of selecting the current value by matching the "value" attribute value with the list:

<label>Categorie</label> <select th:field="*{category}"> <option th:each="cat : ${allCategories}" th:value="${cat}" th:text="${cat.description}"> </option> </select>

The generated HTML looks like:

<select id="category" name="category"> <option value="nl.drsklaus.activiteitensite.model.lookup.ActivityCategory@20">Actief en sportief</option> <option value="nl.drsklaus.activiteitensite.model.lookup.ActivityCategory@21">Uitgaan en nachtleven</option> <option value="nl.drsklaus.activiteitensite.model.lookup.ActivityCategory@22" selected="selected">Kunst en cultuur</option> <option value="nl.drsklaus.activiteitensite.model.lookup.ActivityCategory@23">Eten en drinken</option> <option value="nl.drsklaus.activiteitensite.model.lookup.ActivityCategory@24" selected="selected">Ontspanning en gezelligheid</option> </select>
As we see, the value attributes contain a string representation of the object itself which is clearly not desired, to show the id values we could use ${cat.id} instead of ${cat} but then the selection of the current value (setting the 'selected="selected"' attribute) does not work anymore. THerefore I implemented a Converter which converts an ActivityCategory object to an int (the id value). In Thymeleaf, the converter is called by using the double accolades {{}}:

th:value="${{cat}}"

THe converter is created and added to Spring:

public class LookupConverter implements Converter<LookupEntity, String> { public String convert(LookupEntity source) { return String.valueOf(source.getId()); } }

//In MvcConfig class

@Override public void addFormatters(FormatterRegistry registry) { registry.addConverter(new LookupConverter()); }

Now the HTML shows the id values for the options, which is much more logical:

<select id="category" name="category"> <option value="1">Actief en sportief</option> <option value="2">Uitgaan en nachtleven</option> <option value="3" selected="selected">Kunst en cultuur</option> <option value="4">Eten en drinken</option> <option value="5">Ontspanning en gezelligheid</option> </select>

But it still wrong after submitting, the id value cannot be bound to the Activity object which expects a ActivityCategory instead if an integer value, so a typeMismatch validation error is generated.

My handler method looks like:

@RequestMapping(value = "/{id}/submit", method = RequestMethod.POST) public String submitForm(@ModelAttribute("activity") Activity activity, BindingResult result, ModelMap model) { if (result.hasErrors()) { return "activityform"; } else { if (activity.getId() == null) { this.service.saveActivity(activity); } else { this.service.mergeWithExistingAndUpdate(activity); } return "redirect:/activity/" + activity.getId() + "/detail"; } }

I have looked at many posts but still found have no solution for this IMHO pretty trivial issue. How can the String value containing the id be accepted by the handler method and properly converted? Or can we not use the id value for this purpose? Looking for some hints...

I am just starting with Spring/Hibernate integration and have some problems in handling the form commit. My application to develop is concentrated around the domain objects Activity and Member.
The application core functionality consists of members who can create events (like outdoor events, movies, dinners) where other members can subscribe for.

The domain objects are defined as follows with Hibernate annotations (getter and setters omitted):

@Entity @Table(name="member") public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private int id; @Size(min=3, max=15) @Column(name = "loginname", nullable = false) private String loginName; @NotNull @Column(name = "password", nullable = false) private String password; @NotNull @Column(name = "firstname", nullable = false) private String firstName; @Column(name = "lastname_prefix") private String lastNamePrefix; @NotNull @Column(name = "lastname", nullable = false) private String lastName; @NotNull @DateTimeFormat(pattern="dd-MM-yyyy") @Column(name = "birthdate", nullable = false) @Type(type = "org.jadira.usertype.dateandtime.joda.PersistentLocalDate") private LocalDate birthDate; @NotNull @Column(name = "email", nullable = false) private String email; @NotNull @Column(name = "mobilephone", nullable = false) private String mobilePhone; @NotNull @Column(name = "city", nullable = false) private String city; @NotNull @Column(name = "country_id", nullable = false) private int country_id; @Column(name = "interests") private String interests; @Column(name = "summary") private String summary; @Column(name = "active") private boolean active; @ManyToMany(mappedBy="participants") private Set<Activity> activities = new HashSet<Activity>(); @Entity @Table(name="activity") public class Activity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private int id; @ManyToOne(cascade=CascadeType.ALL) @JoinColumn(name="organizer_id") private Member organiser; @Size(min=5, max=50) @Column(name = "title", nullable = false) private String title; @DateTimeFormat(pattern="dd-MM-yyyy") @Type(type="org.jadira.usertype.dateandtime.joda.PersistentLocalDateTime") @Column(name = "datetime_from", nullable = false) private LocalDateTime dateTimeFrom; @DateTimeFormat(pattern="dd-MM-yyyy") @Type(type="org.jadira.usertype.dateandtime.joda.PersistentLocalDateTime") @Column(name = "datetime_to", nullable = false) private LocalDateTime dateTimeTo; @Size(min=5, max=500) @Column(name = "description", nullable = false) private String description; @Size(min=5, max=30) @Column(name = "meetingpoint", nullable = false) private String meetingPoint; @Column(name = "price") private float price; @Enumerated(EnumType.STRING) @Column(name = "category") private ActivityCategory category; @ManyToMany(cascade = CascadeType.ALL) @JoinTable(name="member_activity_subscription", joinColumns = {@JoinColumn(name="activity_id")}, inverseJoinColumns={@JoinColumn(name="member_id")}) private List<Member> participants = new ArrayList<Member>();

I am starting with the functionality of adding and editing activities for the logged in member (which is now hardcoded because the login system still has to be developed).

I am using a Spring annotated controller and Thymeleaf view. THe problem occurs when editing an existing activity.

This is the code for the controller:

package nl.drsklaus.activiteitensite.web.controller; //imports omitted @RequestMapping("/activity") @Controller public class ActivityController { private final ActivityService service; @Autowired public ActivityController(ActivityService service) { this.service = service; } @ModelAttribute("allCategories") public List<ActivityCategory> populateCategories() { return Arrays.asList(ActivityCategory.ALL); } @RequestMapping(value = "/myactivities", method = RequestMethod.GET) public String home(ModelMap model) { List<Activity> activities = service.findSubscribedActivitiesByMembername("klaas1201", true); System.out.println("Handling GET request, activities = " + activities); model.addAttribute("activitiessubscribed", activities); return "home"; } @RequestMapping(value = {"/create"}, method = RequestMethod.GET) public String createActivity(ModelMap model) { Activity activity = new Activity(); model.addAttribute("activity", activity); return "activityform"; } @RequestMapping(value = "/{id}/edit", method = RequestMethod.GET) public String getActivity(@PathVariable("id") int id, ModelMap model) { Activity activity = service.findById(id); model.addAttribute("activity", activity); return "activityform"; } @RequestMapping(value = "/{id}/formsubmit", method = RequestMethod.POST) public String submitForm(@PathVariable("id") int id, @ModelAttribute("activity") Activity activity, BindingResult result, ModelMap model) { //activityValidator.validate(activity, result); //String returnVal = "success"; if (result.hasErrors()) { return "activityform"; } else { this.service.saveActivity(activity); return "redirect:/activity/myactivities"; } } }

The form part of the view file looks like this:

<form action="#" th:action="@{/activity/{activityId}/formsubmit(activityId=${activity.id})}" th:object="${activity}" method="post"> <fieldset> <legend>Activity Data</legend> <div> <label>Titel</label> <input type="text" th:field="*{title}" /> </div> <div> <label>Van</label> <input type="text" th:field="*{dateTimeFrom}" /> </div> <div> <label>Tot</label> <input type="text" th:field="*{dateTimeTo}" /> </div> <div> <label>Omschrijving</label> <textarea cols="5" rows="30" th:field="*{description}" ></textarea> </div> <div> <label>Afspreekpunt</label> <input type="text" th:field="*{meetingPoint}" /> </div> <div> <label></label> <input type="text" th:field="*{price}" /> </div> <div> <label>Categorie</label> <select th:field="*{category}"> <option th:each="category : ${allCategories}" th:value="${category}" th:text="#{${'activity.category.' + category}}"></option> </select> </div> <div> <input type="submit" value="Opslaan" /> </div> </fieldset> </form>

Most tutorials and examples I find on the internet have domain objects without id field and always have input form fields for all of the available domain object fields.

First I noticed that the id field itself was set to null in the submitForm() method when using the "/formsubmit" pattern. I changed it to "/{id}/formsubmit" and extract the id using a PathVAriable annotation. An alternative would be using a hidden id attribute as one sees a lot in legacy web applications.

I am not sure what is the best practice here. But in this way it is working anyway.

But still the "organiser" field is nullified after the submit. THe organiser of an event cannot be modified after the first create and therefore is not in the form. It is probably possible to use a hidden field for this property too but I thought this should not be necessary with Spring MVC and form backing objects.
So I think my question boils down to how to retains the values of domain object fields which are references to other domain objects and -in rthis case- not editable after the first time create and not part of the edit form (and therefore not part of the POST request variables).
Any tips are more than welcome!

Roel De Nijs wrote:I have never used the possibility of generating the database script using the ORM. I always manually create the necessary DDL (and DML) scripts and execute them manually. My JPA entities don't have any annotation required to generate the database script (besides the column names of course )

Thanks for your answer, I think that makes sense. My biggest point is that maintaining the OM and the DB create script completely separately is in fact a violation of the DRY principle. But on the other hand, the DM can not be completely derived from the OM because different kinds of mapping are possible.
So you suggest designing the OM according to the business domain and designing/creating the DDL script separately (but of course with the OM in mind) ?

After diving in some Spring and Hibernate tutorials, I feel ready to start with my first bigger Hibernate project, which is a website for creating and subscribing to in- and outdoor events by and for members.

With former (PHP) projects, I first designed a database, created the schema, started with some dummy data and builded the application around it.
Using Hibernate, the object model (OM) is already defined in the XML files or annotated classed, and the SQL schema can be generated from this OM.
When creating a separate DB create script apart from Hibernate, we introduce a redundancy and the DB schema and OM must be updated separately.

I cannot find much about best practices here. Should I forget about a separate DDL script and always generate the (modified) script from my OM? This also means that I must design the OM first and the DDL is derived from this OM.
I think this boils down to the question which should be leading, the OM or the DDL schema.
Any ideas are very welcome

Ben Souther wrote:Got it.
Google is my friend.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513568

The answer for anyone else reading this is to call getErrorStream if the response code is not 200.


HttpURLConnection httpConn = (HttpURLConnection)_urlConnection; InputStream _is; if (httpConn.getResponseCode() >= 400) { _is = httpConn.getInputStream(); } else { /* error from server */ _is = httpConn.getErrorStream(); }

I thought you needed to call getErrorStream() for all response codes other than 200 OK. In this example, get ErrorSteam will be called for all status codes below 400, including 200.
So in my wrapper for Android I use the test:

if (this.responseCode == HttpURLConnection.HTTP_OK) { inputStream = httpUrlConnection.getInputStream(); } else { inputStream = httpUrlConnection.getErrorStream(); }

Thanks Bill for your reaction. Indeed it looks pretty overwhelming, I just installed the Toolkit on my Linux machine, and got unexpected a new copy of Eclipse... I wonder how the toolkit is bouned to the Eclispe environment.
Still I find it very hard to start and a real hands-on tutorial using the toolkit would be welcome. The video tutorials on the official site seem not to fulfill this and are not of the greates quality in first sight.
I have some plans for a Web application but still look were to begin... my last Java project is some years ago.

I have started to read Spring in Action 3rd edition which has a good press but until now (Ch1) does not use a running example application. But I will see what comes up in the next chapters.

Hi,
I am just reading the book of Rod Johnson "Java Development without EJB", now already 8 years old but due to lots of circumstances I have been out of the programming market for some years and the book was still unread on my bookshelve...
Nevertheless the book gives a good view of the problems that led to the development of Spring and Hibernate. Now I look for a hands on tutorial to make a working Spring application from scractch which addresses most of the concerns.
In the past I spoilt too much time with the wrong books and outdated tutorials (think I am not the only one in this hehe) so I want to shoot at the right target all at once
Any suggestions for a proven tutorial onthe Web or maybe in printed form?
TIA, Klaas