TL;DR
Is there a way to mix Spring Web Security configuration with both annotations and xml?
Full Story
For our legacy spring web application we are looking into using annotation driven configuration for part of our web security.
Currently all our web security (<security:http>) is driven by xml based configuration. But we are adding a new login mechanism (SAML 2.0) that seems like it would be much easier to configure via annotations than xml.
We have been attempting to mix the use of annotations and xml, but it seems as though only one or the other works. Meaning that when any xml based web security is referenced, either via an xml (<import resource="classpath:web-security.xml"/> or via the #ImportResource annotation, the annotation based web security is ignored.
If we remove references to the xml based configuration our annotation configuration gets called.
Any friendly suggestions or advice is appreciated.
Mixing the Spring Web Security XML and annotation configurations would mean that that the same bean instance, viz., security:http is being configured via XML as well as JavaConfig. It would be configured with some intercept URL patterns using XML and some other Ant matchers using JavaConfig. But please note that intercept URL patterns are always evaluated in the order they are defined and also the matchers are considered in order. So, Spring Security only considers the XML configurations and ignores the JavaConfig ones as, if it considers both, it won't have any sense of order of URL definitions. I couldn't find any documentation that directly supports this theory. If you share the Spring Boot log statements that are produced when the application boots up, we may get a better view of what Spring Boot is doing.
So, I don't think that you can mix Spring Annotations with XML Configuration when configuring Spring Web Security and will advise to migrate legacy XML configurations to JavaConfig.
Related
I have a java project in which many .xml files are present.
All these xml files contain many beans.
The test for unused is:
A bean that is defined but never injected.
A bean that is injected but is never called in the code.
A bean that is defined but never loaded into the Spring context.
Questions
How do I identify which bean is used or not?
Is there a utility to do that?
There is no tools for detecting the unused springbeans in xml file. You can use the Spring Tools Suite for detecting. But it is taking too much time for checking.
I think that you can use spring actuator to check the opposite problem - which beans have been loaded in your context.
https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html
Actuator endpoints allow you to monitor and interact with your
application. Spring Boot includes a number of built-in endpoints and
you can also add your own. For example the health endpoint provides
basic application health information.
The way that endpoints are exposed will depend on the type of
technology that you choose. Most applications choose HTTP monitoring,
where the ID of the endpoint is mapped to a URL. For example, by
default, the health endpoint will be mapped to /health.
beans Displays a complete list of all the Spring beans in your application.
Looking for all the beans which are unused requires scanning XML files within application, then you can compare it with the list of beans produced by actuator.
I want to create a REST web service using Jersey. I also want to use Spring in the project. Now, my questions is the following:
I don't see any reason for integrating these 2 together in my application. So, I should be able to use Spring for bean management and Jersey for creating the web service. Am I correct, or Spring and Jersey somehow have to be integrated.
I see that there is a jersey-spring maven project, and so, I assume that this is for the purpose of integrating jersey and spring together. My question here is do I get any benefit of using this integrated form rather than simply use Jersey and Spring separately each for its own functionality?
Thanks,
Cyrus
You can absolutely combine the two projects. However, I would encourage you to look at Spring-MVC for doing REST as it is very powerful and easy to use. If memory serves, the jersey-spring project was helpful in integration of JAXB and other touch points. Again, this is all built into Spring. And if you use Spring-Boot it is amazingly simple to get running.
The jersey-spring project provides integration between Jersey and Spring. It allows you to wire in any beans in your Spring context into Jersey and vice-versa.
For instance, if you are using spring-security, it will provide your spring-security principal when wiring the Jersey specific SecurityContext into any of your REST resources.
If you want to access Spring beans from your Jersey REST endpoints (or use Spring Beans as implementations for your JAX-RS interfaces) you need to integrate Spring and Jersey, otherwise it won't work. If you don't have any connections between Spring beans and your REST endpoints, then it is not necessary.
I think your first statement is correct. I have used Jersey and Sprint as separate entities.
Jersey is really awesome to create a web server.
Spring is useful for dependency injection (beans) and other cools stuff.
About your second statement, I do not know anything jersey-spring maven project.
My suggestion/opinion is to do as your first comment. Use them in a separate way. You will have the best of both worlds. Using jersey-spring maven project might be a complication and maybe it is not what you want. Libraries usually are intend to be independent.
I want to add a couple of filters to my spring web app, but there won't be anything about security in them, at least for now. So. All I'm able to do without spring-security is to define multiple filters in web.xml (old way of defining filters). It seems strange that to be able to use spring filter chains, I need to add spring-security as a dependency for my project. Maybe I'm doing something wrong and there are indeed filter chains that can be used without spring-security dependency?
Spring Security is able to bundle multiple filters into a single Filter using the FilterChainProxy which is included within Spring Security. Since the code exists within Spring Security, you cannot use it without adding a dependency on spring-security-web short of copy pasting the code into your own project (which is acceptable by the license). The FilterChainProxy is indeed the Spring Bean defined Filter that the DelegatingFilterProxy delegates to. So it looks like this
DelegatingFilterProxy
-> delegates to FilterChainProxy
-> delegates to multiple Filter's defined on the FilterChainProxy
You can use DelegatingFilterProxy. This Spring Forum Entry has a good example of how to use it.
I'm currently working with Spring 3.0.4 and Spring Security 3.0.2 (latest stable release at the moment). I'm kind of struggling migrating from Spring 2.5 to this new version, but that's a different subject.
The real question is coming, inside the <http> tag you can put the <intercept-url>, but it seems like it can also be used inside Security Filters (as seen here : Core web filters).
Can someone tell me the difference between these two? Why using it inside the http tag instead of inside in a security filter?
Thanks
Using <http> tag is a convenient way to configure security filters. When you use it, you typically don't need to configure individual filters.
However, in the complex cases you may configure filters manually as shown in the docs you referenced.
So, they do basically the same thing, but <http> tag is simplier and therefore it's a preferred way to configure Spring Security.
I am using Spring to manage my DAO & Services. And JSF for UI. I want to use dependency injection in my JSF backing-bean. There is an article that explained how I can do that.
But I have two separate projects: one for Service and one for UI. The Spring configuration file is located in Service project.
How can I connect both project with Spring? I want to annotate my JSF pages for DI.
You can achieve this by using Spring Web Flow.
Spring have examples which show:
A JSF centric approach where your Spring and JSF beans are managed/configured the JSF way (faces-config) and a
Spring centric approach where your beans (including ManagedBeans) are managed in the Spring Context.
See Spring Flow Web Home
If you mean that you have one WAR with web services defined in it, and another separate WAR with the JSF stuff, I think it's really two separate projects each with their own Spring configuration.
The web service WAR will use either Spring web services or perhaps HTTP remoting to expose your service interfaces to clients via HTTP. This will have one set of application context configuration, either XML or annotations.
The JSF WAR will have the JSPs and controllers. The controllers will be injected with clients that will interact with the remote services to accomplish what you wish. That's all they need to know about the service WAR. There doesn't need to be any duplication of configuration at all.
It's actually a nice design, because it completely decouples the view from the rest of the problem.
Thank for everyone I did it. My mistake was with bean initialization. I tried to access my injected bean in constructor, but must must did in #PostConstruct method. And all that time i tried to find mistake in my config file. But it was in such simply place :)
I find some solution one:
Sample Application using JSF, Spring 2.5, and Java Persistence APIs with Glassfish v2
. But I have problem with it.
I can post this problem hear or must create new topic? Sorry for stupid question, i'm newbie her.