SEC-826: Support for JPA PersistenceContext annotation broken #1083

spring-issuemaster opened this Issue May 11, 2008 · 11 comments


None yet
1 participant

Mark Hillary(Migrated from SEC-826) said:

When using the intercept-methods tag on a bean, the dao’s used by the userSecurityService and the protected bean are not processed by the
PersistenceAnnotationBeanPostProcessor. This seems to be because the dao gets created before the PostProcessor and so in never seen by it. This like [#SEC-750] causes a null pointer when an attempt is made to authenticate the user.

I believe that this is related to [#SEC-750] and [#SEC-773] however it still occurs in 2.0.0/2.5.4

I have modified the test case form [#SEC-750] to demonstrate the problem. The unmodified test case runs fine on my system.

My real world case is a little more complex in that I have a userSecurityService that uses one of my service components, that in turn uses a DAO that is used by another protected service.

Mark Hillary said:

modified example from [#SEC-750]

Mark Hillary said:

Just to add to the above using does work.

Luke Taylor said:

Thanks for the report. However the attachment doesn’t appear to work. A “mvn test” command first fails with a compilation error and after fixing that the application context fails to load with an “Invalid property ‘BODAO’ of bean class [sample.service.impl.UserServiceImpl]: No property ‘BODAO’ found” error. I will try to analyse the issue you’ve reported but if you could supply a test case that displays the symptoms that would be very useful.

Luke Taylor said:

I think I’ve fixed the context file (at least Im now getting a NPE), so don’t worry about the test case.

Luke Taylor said:

OK. As far as I can see, this is the same issue as SEC-773, which was fixed in 2.0.1.

Your test case is set to run with 2.0.0-RC1 and you say the problem still occurs with 2.0.0, but you have reported the issue against 2.0.1. Have you tried 2.0.1? Once I’d got the test case running, it failed with a NPE, but after switching the security jars to 2.0.1 it runs without any problem.

Please could you make sure you are running against an up to date version and clarify the situation.

Mark Hillary said:

Sorry, that was my fault in packaging it. I just added the files I changed to the existing zip file, hence the configuration was wrong.

For correction I am actually using the 2.0.1 release of spring security.

Mark Hillary said:

Just to add, the issue reported in [#SEC-773] does work for me. And I’ve never tried 2.0.0 only 2.0.1.

Mark Hillary said:

I’ve updated my configuration to use Maven to ensure I am pulling the right dependencies in. Sorry its taken me a while, I’ve not used Maven before.

Attached is my whole eclipse workspace for the test case in which I’m still seeing the null pointer. Not sure if it matters but I’m using JDK6 on windows XP.

Luke Taylor said:

I’ve moved all injection of UserDetailsService objects from a BeanFactoryPostProcessor to a BeanPostProcessor which is more appropriate in any case and should prevent any early instantiation problems. It prevents the NPE in your test, but there appears to be another error in the test (I think due to calling persist() for an entity on which the Id has already been set). However the problem of persistence annotations being missed should now be fixed. Could you try an up-to-date sapshot please and see if you still have any problems?

Mark Hillary said:

Thanks Luke, that has fixed the problem for me. Cheers.

Luke Taylor said:

OK :). Thanks for your feedback. Closing the issue.

spring-issuemaster added this to the 2.0.2 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment