At the moment I have some code that uses Google Guice to start a server:
Injector injector = createInjector(
new Module(root, domain, realm),
new TestsArtefactsServiceModule()
final Server server = injector.getInstance(Server.class);
server.acquire();
server.activate();
getRuntime().addShutdownHook(new Thread(() -> stopServer(server)));
I need to change it to use Spring.
Is there an equivalent of the Guice Injector class in Spring? Or, is there some other way to achieve this?
In Spring it's the ApplicationContext you are looking for.
There is a comparison of these two frameworks:
http://www.theserverside.com/feature/Comparing-Spring-vs-Google-Guice-By-Example
Related
I am trying to migrate our Spring-based web app from Tomcat 8 to Undertow.
We use Spring's WebApplicationInitializer for the programmatic configuration of Spring-MVC and HibernateTransactionManager.
There is a ServletContainerInitializerInfo class (Javadoc) that seems to serve my purpose, e.g I can instantiate it and then follow the steps given in Undertow docs (link) to start the server:
ServletContainerInitializerInfo sciInfo =
new ServletContainerInitializerInfo(containerInitializerClass,
instanceFactory, handlesTypes);
DeploymentInfo servletBuilder = Servlets.deployment()
.addServletContainerInitalizer(sciInfo);
DeploymentManager manager = Servlets.defaultContainer()
.addDeployment(servletBuilder);
manager.deploy();
PathHandler path = Handlers.path(Handlers.redirect("/myapp"))
.addPrefixPath("/myapp", manager.start());
Undertow server = Undertow.builder()
.addHttpListener(8080, "localhost")
.setHandler(path)
.build();
server.start();
The problem is that I don't know what to substitute for instanceFactory and handlesTypes arguments in call to ServletcontainerInitializerInfo constructor. In addition, the name of the addServletContainerInitalizer method is mis-spelled (should be Initializer instead of Initalizer).
Can someone please help?
Thanks!
Undertow uses InstanceFactory<T> as an extension point for dependency injection or other customization of an instance of a given class after instantiation.
The handlesTypes argument would be the set of all classes corresponding to the #HandlesTypes annotation on your servlet container initializer.
If your initializer has no #HandlesTypes and does not require dependency injection, you can simply try this:
MyInitializer initializer = new MyInitializer();
InstanceFactory<MyInitializer> instanceFactory
= new ImmediateInstanceFactory<>(initializer);
ServletContainerInitializerInfo sciInfo =
new ServletContainerInitializerInfo(MyInitializer.class,
instanceFactory, new HashSet<Class<?>>());
To clarify my question further:
I have a spring xml file with camel routes. I want to bootstrap this route in a BundleActivator. What are the steps in the OSGI world to initialize and start a SpringContext and register with OSGI registry. I want to do this custom through the api – need to control this rather than use the spring DM. I under stand that I need to use the OSGI classes. Any examples to follow:
This does not start the routes:
ConfigurableApplicationContext ctx = new GenericApplicationContext();
ConfigurableEnvironment environment = ctx.getEnvironment();
//set up the props for the context
XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader((BeanDefinitionRegistry) ctx);
ClassPathResource classPathResource = new ClassPathResource("context.xml",properClassLoader );
xmlReader.loadBeanDefinitions(classPathResource);
ctx.refresh();
ctx.start();
Thanks.
What you are looking for is called Managed Service Factories.
Take a look at the description at eclipse gemini project.
I am creating an application that runs in Karaf as OSGi container, and uses the OSGi HTTP Service and Jersey for exposing REST APIs. I need to add SAML2 authentication and permissions-based authorization. I would like to use the annotation based approach in Shiro for this, as spring seems to be moving away from OSGi. My questions:
Is Shiro with SAML jars a good fit in OSGi environments?
I want to use WSO2 as the identity provider. Are there any caveats of Shiro and WSO2 working together?
For using annotations, the Shiro docs indicate I need to put AspectJ/Spring/Guice jars - Is this still valid in OSGi environments? I would prefer Guice for all my DI needs.
Would be great to have some insights from Shiro users.
UPDATE
I'm using this project: osgi-jax-rs-connector. So, I use Guice-Peaberry to register OSGi services with the interfaces annotated with #Path or #Provider, and the tool takes care of converting them into a REST resource. (Similar to pax-whiteboard?). I was planning to similarly expose my filters as OSGi services, and then dynamically add them along with the resources.
I have had headaches with AspectJ in OSGi in a previous project where I had to switch to vanilla Equinox from Karaf because the equinox weaving hook was not agreeing with Karaf (stack traces from Aries were seen, among other things). So, would doing something like shiro-jersey be better?
I'm sure it is doable, though I already see some restrictions/issues poping up.
for
1) haven't tried it, though you need to make sure that you tell the pax-web and jetty about it, it'll require adding this to the jetty.xml and it might even need to add a fragment bundle to pax-web-jetty so the desired class can be loaded. This will most likely be your first classnotfound issue.
2) don't know of WSO2 so no idea
3) if you want to use annotations, be careful. For Guice you'll mostlikely will need to use Peaberry since afaik Guice isn't "OSGi-fied" yet. Using AspectJ isn't really a good idea in a OSGi environment due to the classloader restrictions. If you have a compile-time weaving it should be fine, but run-time weaving will be a challange.
UPDATE:
Completely forgot about it, but there is a Pax Shiro Project available, maybe this can be a good starting point to get your setup in a correct lineup.
In the interest of readers, I'm sharing the solution I arrived at after some research of existing tools. First, the easy part: Using Shiro annotations in an OSGi environment. I ended up writing the below class since most Shiro-Jersey adapters shared by developers is based on Jersey 1.x.
#Provider
public class ShiroAnnotationResourceFilter implements ContainerRequestFilter {
private static final Map, AuthorizingAnnotationHandler> ANNOTATION_MAP = new HashMap, AuthorizingAnnotationHandler>();
#Context
private ResourceInfo resourceInfo;
public ShiroAnnotationResourceFilter() {
ANNOTATION_MAP.put(RequiresPermissions.class,
new PermissionAnnotationHandler());
ANNOTATION_MAP.put(RequiresRoles.class, new RoleAnnotationHandler());
ANNOTATION_MAP.put(RequiresUser.class, new UserAnnotationHandler());
ANNOTATION_MAP.put(RequiresGuest.class, new GuestAnnotationHandler());
ANNOTATION_MAP.put(RequiresAuthentication.class,
new AuthenticatedAnnotationHandler());
}
public void filter(ContainerRequestContext context) throws IOException {
Class resourceClass = resourceInfo.getResourceClass();
if (resourceClass != null) {
Annotation annotation = fetchAnnotation(resourceClass
.getAnnotations());
if (annotation != null) {
ANNOTATION_MAP.get(annotation.annotationType())
.assertAuthorized(annotation);
}
}
Method method = resourceInfo.getResourceMethod();
if (method != null) {
Annotation annotation = fetchAnnotation(method.getAnnotations());
if (annotation != null) {
ANNOTATION_MAP.get(annotation.annotationType())
.assertAuthorized(annotation);
}
}
}
private static Annotation fetchAnnotation(Annotation[] annotations) {
for (Annotation annotation : annotations) {
if (ANNOTATION_MAP.keySet().contains(annotation.annotationType())) {
return annotation;
}
}
return null;
}
}
The complete project is here.
The above took care of Part 3 of my question.
For Shiro with SAML, I am using the Servicemix wrapped openSAML jar, and it seems to be working okay till now. I did however had to write a bit of code to make Shiro work with SAML2. It's almost on the same lines as shiro-cas, but is a bit more generic to be used with other IdPs. The code is kind of big so sharing a link to the project instead of copying classes to SO. It can be found here.
Now that I have some abstraction between my code and my IdP, WSO2 integration looks a bit simpler.
P.S. Thanks Achim for your comments and suggestions.
I am trying to make this run for days now and I can't figure out how to do it. Perhaps someone else has an idea or has done this already?
I want to deploy my application on a grizzly embedded server. I configured my Spring application using JavaConfig, and that worked out pretty good so far, but now I seem to be stuck. Here is the code I use to deploy my Jersey stuff to grizzly:
HttpServer server = new HttpServer();
NetworkListener listener = new NetworkListener("grizzly2", "localhost", 4433);
server.addListener(listener);
WebappContext ctx = new WebappContext("ctx","/");
final ServletRegistration reg = ctx.addServlet("spring", new SpringServlet());
reg.addMapping("/*");
reg.setInitParameter("com.sun.jersey.config.property.packages", "com.myapp.http.webservices");
ctx.addContextInitParameter("contextConfigLocation", "com/myapp/config/beans.xml");
ctx.addListener("org.springframework.web.context.ContextLoaderListener");
ctx.addListener("org.springframework.web.context.request.RequestContextListener");
ctx.addFilter("springSecurityFilterChain", new DelegatingFilterProxy());
ctx.deploy(server);
server.start();
Now as far as I can tell the following line is the problem.
ctx.addContextInitParameter("contextConfigLocation", "com/myapp/config/beans.xml");
I have a beans.xml in which I configure the spring security stuff, but all the other beans I use are declared via JavaConfig. So, if I only pass the beans.xml, the application will only have access to the beans declared in there. What I really want to so is to pass my ApplicationContext so that all my beans can be retrieved properly.
I there a way to pass my ApplicationContext with the deployment as well? Or has someone a better idea on how to make this work?
Try this
ctx.addContextInitParameter("contextConfigLocation", "classpath:com/myapp/config/beans.xml")
And you should not use com.sun.jersey.config.property.packages anymore as you already use Spring to manage the beans.
I'm writing some JUnit-based integration tests for a RESTful web service using JerseyTest. The JAX-RS resource classes use Spring and I'm currently wiring everything together with a test case like the following code example:
public class HelloResourceTest extends JerseyTest
{
#Override
protected AppDescriptor configure()
{
return new WebAppDescriptor.Builder("com.helloworld")
.contextParam( "contextConfigLocation", "classpath:helloContext.xml")
.servletClass(SpringServlet.class)
.contextListenerClass(ContextLoaderListener.class)
.requestListenerClass(RequestContextListener.class)
.build();
}
#Test
public void test()
{
// test goes here
}
}
This works for wiring the servlet, however, I'd like to be able to share the same context in my test case so that my tests can have access to mock objects, DAOs, etc., which seems to call for SpringJUnit4ClassRunner. Unfortunately, SpringJUnit4ClassRunner creates a separate, parallel application context.
So, anyone know how can I create an application context that is shared between the SpringServlet and my test case?
Thanks!
Override JerseyTest.configure like so:
#Override
protected Application configure() {
ResourceConfig rc = new JerseyConfig();
rc.register(SpringLifecycleListener.class);
rc.register(RequestContextFilter.class);
rc.property("contextConfigLocation", "classpath:helloContext.xml");
return rc;
}
For me the SpringServlet was not required, but if you need that you may be able to call rc.register for that too.
I found a couple of ways to resolve this problem.
First up, over at the geek#riffpie blog there is an excellent description of this problem along with an elegant extension of JerseyTest to solve it:
Unit-testing RESTful Jersey services glued together with Spring
Unfortunately, I'm using a newer version of Spring and/or Jersey (forget which) and couldn't quite get it to work.
In my case, I ended up avoiding the problem by dropping the Jersey Test Framework and using embedded Jetty along with the Jersey Client. This actually made better sense in my situation anyway since I was already using embedded Jetty in my application. yves amsellem has a nice example of unit testing with the Jersey Client and embedded Jetty. For Spring integration, I used a variation of Trimbo's Jersey Tests with Embedded Jetty and Spring