I’m sorry. I’ll write about API changes.
Thank you! You are doing very nice work with this addon! Making my work alot easier!
Thanks for the plug-in, it appears to work well and it is pretty simple to setup.
My one request is that you look at removing the use of <context:spring-configured />. I’d prefer not to have load-time weaving enable for non-spring managed beans in my application but that isn’t possible right now with this plug-in. Looking at the code, it appears that only SpringUIProvider and DiscoveryNavigator are using the Configurable annotation. In both of these cases, they are using the annotation to locate the application context.
SpringUIProvider is created in the SpringVaadinServlet so you already have access to the application context and can simply pass it in the constructor. The DiscoveryNavigator could be injected into the UI by the spring configuration and could therefore just implement ApplicationContextAware.
It seems like these two simple changes are worth it to remove the dependency on load-time weaving and would make it even easier for people to use the plugin because they wouldn’t need to use the spring-configured element in the context.
I could look at making the changes and sending a patch if you’re interested.
Thanks again,
-mike
Sorry for my English. I try to explain about <context:spring-configured />.
A big problem is deserialization.
After deserialization the application context in SpringUIProvider and DiscoveryNavigator is null.
It doesn’t matter how to locate the application context, use @PostConstruct or implement ApplicationContextAware.
If you reload your web page after deserialization, there is no problem. New UI instance will be created.
But. If you try to use exists web page, click a button for example, your will have a very big problem. NullPointerException.
I don’t like LTW too.
This problem is between non-spring managed beans, spring singlton, spring session beans and prototype beans.
Here you are, 1.5.1 experimental version.
Without AspectJ, but with static access to the application context.
Thanks for the quick reply. I forgot about session serialization as I don’t currently use that feature.
I updated to 1.5.1 and removed the context:spring-configured tag and everything looks good. I didn’t test session serialization at all though. Do you have the new code available someplace? I didn’t see it in github.
-mike
Serialization works quite well, in my project.
No, I don’t publish it yet in github.
I published new version with new feature. UI scopes.
I tried the new UI scope feature but found that it doesn’t work as a true Spring scope. I get the error:
java.lang.IllegalStateException: No Scope registered for scope 'ui'
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:325)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:274)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1106)
at ru.xpoft.vaadin.DiscoveryNavigator.getView(DiscoveryNavigator.java:132)
...It looks like it is only a scope hint to the ViewProvider but not a true Spring scope because you still have the view labeled as a prototype in Spring. To be a true Spring scope, you need to implement Spring’s Scope interface: http://static.springsource.org/spring/docs/3.0.0.M3/reference/html/ch04s04.html (look for Custom Scopes)
Let me describe my use case:
I’m not using the VaadinView annotation because I don’t want all my views discovered automatically for security purposes. I only want to put the views the user has permission to in the navigator. So I’m putting my views in my Spring context XML with a scope of “prototype” like:
<bean name="search" scope="prototype"
class="org.mpilone.ui.view.SearchView" />I then use DiscoveryNavigator.addBeanView to add the view when my UI is being initialized. The problem is that I can’t use:
<bean name="search" scope="ui"
class="org.mpilone.ui.view.SearchView" />because the “ui” scope is not a true Spring scope. I would suggest implementing “ui” as a true spring scope or don’t use the term “scope” on the VaadinView annotation because you end up with two scopes on the view, “prototype” for Spring and “ui” for Vaadin.
I suppose I could reconsider just doing automatic view discovery and auto injection and then implement security in the “enter()” callback of the navigator.
-mike
No. It’s not Spring scope. It’s scope for Vaadin View.
This scope context is different from Spring and can’t be implemented there.
Also custom scope implements need AOP. And you don’t like it.
I think it’s too difficult to implement Spring’s Scope with non-Spring managed classes. But I try to do that.
How do you check the user permission?
Does this addon work well with Spring Roo 1.2 to create domains (beans) among other things?
Ah, I didn’t realize Spring’s custom scopes required AOP. I can understand not wanting to implement it at the Spring level, but I think it might cause some confusion to have both a view “scope” and a Spring “scope”. If you can’t get a true Spring scope to work you might want to change the VaadinView annotation to have a “cached” flag or a “mode” rather than a “scope” just two keep the two concepts separate.
Security wise I use Apache Shiro to authenticate the user and load permissions. Based on the user permissions, I only add permitted views to the Navigator. This ensures that no matter how bad our code it, a user can’t get to a view they shouldn’t be allowed to see. I could probably get the same results using the “enter()” callback to deny a view change if the user doesn’t have permission, but it is more likely that something will slip through the cracks.
It might be worth looking at writing a future add-on to allow a view level annotation that integrates with Shiro or Spring Security. Maybe in my free time 
-mike
I don’t know. I never use Spring Roo.
You are right. I’ll rename “scope” to “cached” tomorrow.
Could you make a simple project with Apache Shiro for me? I would like to try enhance addon.
Hi Alexander
That would be a killer feature !!! I really like apache Shiro security framework. Vaadin + Spring + Shiro = Xplosive Combination !!! After such an integration you could even rename the Original Addon from SpringVaadinIntegration To VSS, boom ! lol . More seriouly it will be very interesting to have this three play nicely together . If you could do it with the same elegance as you did for vaadin spring that would be Awsome.
By the way here is two github project that have combine vaadin spring and shiro , but it’s based on vaadin 6.xxx branch. at least it can give you some idea .
https://github.com/eneuwirt/fbs
https://github.com/eneuwirt/vaadin-shiro-simple
And one more lynk specific to shiro spring integration from the official apache shiro website : http://shiro.apache.org/spring.html.
It would be nice if we could use shiro annotation like for example : @RequiresRoles or @RequiresPermissions on some vaadin component, views , method etc …
This features requires using Shiro’s spring AOP , but i noticed that you guys have concerned about spring AOP, aspectj weaving in generale, which is not my case . By the way implementation of the plugin with aspectj was pretty good i didn’t really bother having dependancy on aspectj. but i guess there is some good reason for removing it.
Cheers
René
I don’t have a complete example but you could take some advice from the existing integration into JSP pages. Shiro has documentation here:
http://shiro.apache.org/jsp-tag-library.html
I’m not 100% sure it makes sense to have your spring-vaadin module also do the Shiro stuff given that there are probably plenty of Vaadin+Spring users who are not Shiro users. However a separate but compatible shiro-vaadin module would be greatly appreciated.
For now we just have some if/else checks in our UI when we’re constructing the Navigator. For example (from memory):
if (securityContext.getSubject.hasPermission(“manage_customer”)) {
navigator.addView(CreateCustomerView.NAME, CreateCustomerView.class);
navigator.addView(ReadCustomerView.NAME, ReadCustomerView.class);
navigator.addView(UpdateCustomerView.NAME, UpdateCustomerView.class);
}
-mike
I have updated add-on.
New feature: ShiroSecurityNavigator. This Navigator use @RequiresRoles, It doesn’t use AspectJ. Simple roles check.
New Sample projects are here.
https://github.com/xpoft/vaadin-samples
.
There are samples: Spring Vaadin Integration, Spring Security and Apache Shiro.
This is Awesome Alexander,
thank you so much, i 'll try it out right away and let you know how it goes for me !!
Cheers
Ok. It doesn’t support Logical attribute now, I’ll add it later. Does it need @RequiresPermissions support?