Search Results

Search found 2 results on 1 pages for 'thestijn'.

Page 1/1 | 1 

  • Occasional Date or timezone discrepancy in hudson or maven with jodatime

    - by TheStijn
    hi, I hope following explanation will make sense because it's a weird problem we're facing and hard to describe. We have a maven project which gets build in hudson and that contains some unit tests where dates are used and asserted. The hudson server runs on solaris. Now, occasionally (like 30% of the times) the unit tests using dates fail because 3,5 hours are deducted from the specified time in the unit test and hence asserts start failing. The other 70% everything works fine although nothing at all changed in the code and we run the hudson job several times an hour. I add following code to a unittest to check the time: @Test public void testDate() { System.out.println("new DateMidnight(2011, 1, 5).toDate();"); System.out.println(new DateMidnight(2011, 1, 5).toDate()); System.out.println(new DateMidnight(2011, 1, 5).toDate().getTime()); Calendar cal = Calendar.getInstance(); cal.set(Calendar.YEAR, 2011); cal.set(Calendar.MONTH, 0); cal.set(Calendar.DAY_OF_MONTH, 5); cal.set(Calendar.HOUR, 0); cal.set(Calendar.MINUTE, 0); cal.set(Calendar.SECOND, 0); cal.set(Calendar.MILLISECOND, 0); System.out.println("cal.getTime();"); System.out.println(cal.getTime()); System.out.println(cal.getTime().getTime()); } So basically it should print the same thing when using jodatime or plain old Calendar. This is the case in 70% of the runs; for the other 30% I get following printouts: Running TestSuite new DateMidnight(2011, 1, 5).toDate(); Tue Jan 04 21:30:00 MET 2011 1294173000000 cal.getTime(); Wed Jan 05 12:00:00 MET 2011 1294225200000 Local maven tests never appear the pose this problem and we can't figure out what could be the cause of it. Especially, we can't think of a single reason why the tests sometimes pass and sometimes fail without changing any code nor hudson or server setting. Also, we run the maven install with cobertura which means that the unit tests are run twice. It happens also that they pass the first time and fail the second time or the other way around or that they fail both times. Thanks for any help, Stijn

    Read the article

  • Spring MVC with annotations: how to beget that method always is called

    - by TheStijn
    hi, I'm currently migrating a project that is using Spring MVC without annotations to Spring MVC with annotations. This is causing less problems than expected but I did come across one issue. In my project I have set up an access mechanisme. Whether or not a User has access to a certain view depends on more than just the role of the User (e.g. it also depends on the status of the entity, the mode (view/edit), ...). To address this I had created an abstract parent controller which has a method hasAccess. This method calls also other methods like getAllowedEditStatuses which are here and there overridden by the child controllers. The hasAccess method gets called from the showForm method (below code was minimized for your readability): @Override protected ModelAndView showForm(final HttpServletRequest request, final HttpServletResponse response, final BindException errors) throws Exception { Integer id = Integer.valueOf(request.getParameter("ID")); Project project = this.getProject(id); if (!this.hasAccess(project, this.getActiveUser())) { return new ModelAndView("errorNoAccess", "code", project != null ? project.getCode() : null); } return this.showForm(request, response, project, errors); } So, if the User has no access to the view then he gets redirected to an error page. Now the 'pickle': how to set this up when using annotations. There no longer is a showForm or other method that is always called by the framework. My (and maybe your) first thought was: simply call this method from within each controller before going to the view. This would of course work but I was hoping for a nicer, more generic solution (less code duplication). The only other solution I could think of is preceeding the hasAccess method with the @ModelAttribute annotation but this feels a lot like raping the framework :-). So, does anyone have a (better) idea? thanks, Stijn

    Read the article

1