In https://docs.spring.io/spring-integration/reference/html/dsl.html#java-dsl-flow-adapter I found this code example:
#Component
public class MyFlow implements IntegrationFlow {
#Override
public void configure(IntegrationFlowDefinition<?> f) {
f.<String, String>transform(String::toUpperCase);
}
}
but no example of how to use it. Can someone please provide an example of how such a class is meant to be used?
Related
I've run to some issues trying to migrate dropwizard from 1.2 to 2.0.24 (and 2.0.25) related to DI, wondering if someone has had same issues or any ideas.
We have one application,
public class Account extends Application<AccountConfiguration> {
public static void main(String[] args) throws Exception {
new Account().run(args);
}
#Override
public void initialize(Bootstrap<Configuration> bootstrap) {
bootstrap.addBundle(new DropwizardBundle<>());
}
#Override
public void run(AccountConfiguration configuration, Environment environment) throws Exception {
...
environment.jersey().register(new SessionResource(authenticationService));
}
}
The DropWizardBundle class binds an instance to a class:
public void run(AccountConfiguration configuration, Environment environment) {
environment.jersey().register(new AbstractBinder() {
#Override
protected void configure() {
bind(configuration.getResponder()).to(Responder.class);
}
});
And the SessionResource looks like
#Path("/sessions")
#Consumes(MediaType.APPLICATION_JSON)
#Produces({MediaType.APPLICATION_JSON, "application/v1+json"})
#RequiredArgsConstructor
#Timed
public class SessionResource {
#Inject
private Responder responder;
private final AuthenticationService authenticationService;
#POST / #GET methods
}
The current code, in Dropwizard 1.2 is running and Responder is injected. Switching to 2.0.24/25 Responder is null. I am wondering if I missed something in the migration..
I'm not sure if this is working the way you intended (or the way you are think it is) in version1.X for you. I do not know what configuration.getResponder() is returning so I can't really test your case. I found for resource classes using DI, a lot of problems I see people face can be solved by registering the class and allow the H2K instantiate the resources for you.
environment.jersey().register(SessionResource.class);
You will have to update how AuthenticationService is passed into the resource by registering it to so it can also be injected. The below is an example of registering it as a AuthenticationService as a singleton.
public void run(AccountConfiguration configuration, Environment environment) {
environment.jersey().register(new AbstractBinder() {
#Override
protected void configure() {
//Not sure how AuthenticationService is instantiate but this is an example
bind(new AuthenticationService()).to(AuthenticationServic.class).in(Singleton.class);
}
});
I am learning Java, but found the following piece of code. I am confused. What is bind(X.class).to(X.class); for?
import org.glassfish.hk2.utilities.binding.AbstractBinder;
public class ApplicationBinder extends AbstractBinder {
#Override
protected void configure() {
bind(X.class).to(X.class);
}
}
Thanks
You're configuring how you want your services to be discovered in the DI (dependency injection) system. bind(Service).to(Contract) is basically saying that you want to provide the Service as an injectable service, and want to "advertise" it as Contract. By "advertise", I mean what you want to be able to inject it as. For instance Service can be UserRepositoryImpl, while Contract can be UserRepository (interface). With this you would only be able #Inject UserRepository as that's what you advertise. The benefit of this is all the benefits that come with programming to an interface.
Example
interface UserRepository {
List<User> findAll();
}
class UserRepositoryImpl implements UserRepository {
#Override
public List<User> findAll() {
return Arrays.asList(new User("username"));
}
}
#Path("users")
class UserResource {
#Inject
private UserRepository repository;
#GET
public List<User> getUsers() {
return repository.findAll();
}
}
class JerseyApp extends ResourceConfig {
public JerseyApp() {
register(UserResource.class);
register(new AbstractBinder() {
#Override
public void configure() {
bind(UserRepositoryImpl.class)
.to(UserRepository.class);
}
});
}
}
Here the UserRepository is injected into the UserResource. When the DI system injects it, it will actually be the UserRepositoryImpl instance.
By doing that you are actually binding a new contract to a service.
bind(Service.class).to(Contract.class);
OR (binding a new contract to a service in Singleton)
bind(Service.class).to(Contract.class)..in(Singleton.class);
In order to initialize the application at startup, I extended ServletContextListener:
#WebListener
public class MyServletContextListener implements javax.servlet.ServletContextListener {
#Override
public void contextInitialized(ServletContextEvent sce) {
... initialization code here
}
#Override
public void contextDestroyed(ServletContextEvent sce) {}
}
Now I want to extract the initialization logic into a standalone StartupManager class, and delegate to this class from MyServletContextListener:
public class StartupManager {
public void performStartup() {
... initialization code here
}
}
I tried to inject StartupManager into ServletContextListener by simply adding #Inject annotation:
#WebListener
public class MyServletContextListener implements javax.servlet.ServletContextListener {
#Inject StartupManager mStartupManager;
#Override
public void contextInitialized(ServletContextEvent sce) {
mStartupManager.performStartup();
}
#Override
public void contextDestroyed(ServletContextEvent sce) {}
}
This did not work - the reference is null when contextInitialized(ServletContextEvent ) is called.
Then I thought that I might have to register a binder:
#ApplicationPath("")
public class MyResourceConfig extends ResourceConfig {
public MyResourceConfig() {
register(new DependencyInjectionBinder());
}
}
public class DependencyInjectionBinder extends AbstractBinder {
#Override
protected void configure() {
bind(StartupManager.class).to(StartupManager.class);
}
}
This did not work either.
My question is how can I perform injection of dependencies into ServletContextListener? Preferably constructor injection, but field injection will also be alright.
It's not going to work, as the servlet listener and Jersey are not linked to the same system. As an alternative, you can use Jersey's Event Listeners. You can implement an ApplicationEventListener where you would be able to initialization and clean up in the same way you would in the servlet listener. You would be able to inject your services into Jersey's listener.
I was wondering if anyone knows an elegant way to get all the roles in the spring security plugin that have access to the current page.
I am using spring security and it's configured to use RequestMap domain objects.
The permissions in my app are pretty complex so I wanted to make a tag at the bottom of each page displaying the roles need to use the page.
I was doing a query for the request map but I want to make sure the way I match the url is the same as the way the plugin does.
Ideally I wouldn't have to run a query at all.
Grails version 2.2.1 Spring Security Plugin version 1.2.7.3
Thanks in advance
I got this to work by adding the following two classes to my src/java.
Class 1
import org.springframework.security.access.ConfigAttribute;
import org.springframework.security.web.FilterInvocation;
import org.springframework.security.web.access.intercept.FilterInvocationSecurityMetadataSource;
import javax.servlet.http.HttpServletRequest;
import java.util.Collection;
public class MyFilterInvocationSecurityMetadataSource implements FilterInvocationSecurityMetadataSource {
FilterInvocationSecurityMetadataSource oldBean;
#Override
public Collection<ConfigAttribute> getAttributes(Object o) throws IllegalArgumentException {
FilterInvocation filterInvocation = (FilterInvocation) o;
HttpServletRequest request = filterInvocation.getHttpRequest();
request.setAttribute("PAGEROLES", oldBean.getAttributes(filterInvocation));
return oldBean.getAttributes(o);
}
#Override
public Collection<ConfigAttribute> getAllConfigAttributes() {
return oldBean.getAllConfigAttributes();
}
#Override
public boolean supports(Class<?> aClass) {
return FilterInvocation.class.isAssignableFrom(aClass);
}
public Object getOldBean() { return oldBean; }
public void setOldBean(FilterInvocationSecurityMetadataSource oldBean) { this.oldBean = oldBean; }
}
Class 2
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.security.web.access.intercept.FilterInvocationSecurityMetadataSource;
public class FilterSecurityMDSExtractor implements BeanPostProcessor, BeanFactoryAware {
private ConfigurableListableBeanFactory bf;
private FilterInvocationSecurityMetadataSource metadataSource = new MyFilterInvocationSecurityMetadataSource();
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
if (bean instanceof FilterInvocationSecurityMetadataSource) {
((MyFilterInvocationSecurityMetadataSource) metadataSource).setOldBean((FilterInvocationSecurityMetadataSource) bean);
return metadataSource;
}
return bean;
}
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
this.bf = (ConfigurableListableBeanFactory)beanFactory;
}
}
I then added the following to resources.groovy
beans = {
filterSecurityMDSExtractor(FilterSecurityMDSExtractor)
}
Basically I am stuffing the user roles into the request
request.setAttribute("PAGEROLES", oldBean.getAttributes(filterInvocation));
then all I have to do is call the following
request.getAttribute("PAGEROLES");
to get the roles back out. I pieced together my solution by stealing from other great posts on Stackoverflow. Someone else might have a better solution but so far this is working for me.
I started exploring Google Guice today to do dependency injection in my application.
I noticed I am not using #Inject annotation anywhere. But it's working. Can not understand this concept. In this example, where #Inject is the best fit in my scenerio? If any one can point me out.
public interface Tweeter {
public void sendTweet(String message);
}
public class SmsTweeter implements Tweeter {
#Override
public void sendTweet(String message) {
System.out.println("You SMS tweet: "+message);
}
}
import com.google.inject.AbstractModule;
public class TweetModule extends AbstractModule{
#Override
protected void configure() {
bind(Tweeter.class).to(SmsTweeter.class);
}
}
import com.google.inject.Guice;
import com.google.inject.Injector;
public class TestTweetClient {
public static void main(String[] args) {
Injector injector = Guice.createInjector(new TweetModule());
Tweeter tweeter = injector.getInstance(Tweeter.class);
tweeter.sendTweet("Hi there");
}
}
It prints (the hidden implementation works):
You SMS tweet: Hi there
There is no best fit for #Inject in your example. The class SmsTweeter has an implicit zero-args constructor. You could make it explicit and add #Inject there but it is not necessary.
public class SmsTweeter implements Tweeter {
#Inject
SmsTweeter() {
// nothing to do
}
#Override
public void sendTweet(String message) {
System.out.println("You SMS tweet: "+message);
}
}