this is a situation I would like to implement.
public class ComponentRepository
{
public void Register(IComponent component)
{
// store component in collection
}
}
<!-- root context -->
<object id="Repository" type="NameSpace.ComponentRepository" />
<!-- child context (0 - n contexts) -->
<object id="Component" type="NameSpace.Component"/>
I would like to register all IComponent objects with ComponentRepository. I suppose it can be done with some kind of publish/subscribe mechanism, but I would like to keep my classes clean (without implementing any of spring.net interfaces).
What is the best way to achieve this?
I understood your question as this:
After the instantiation of the child-context's Component, the Register-method of a ComponentRepository defined in another context should be called.
As far as I know, there is no xml-declarative way to achieve what you want.
I would suggest to either make your ComponentRepository IApplicationContextAware (which is what you explicitly don't want) or to create a new IApplicationContextAware Class which takes a dependency of ComponentRepository.
That way you can call the ApplicationContext's GetObjectsOfType Method and retrieve all IComponent objects to pass to the ComponentRepository.
Related
This involves autofac and c#. I have an interface derived from a parent interface:
public interface IJ4JLogger<out TCalling>
{
}
public interface IJ4JSmsLogger<out TCalling> : IJ4JLogger<TCalling>
{
}
Certain classes depend on being supplied an instance of the parent interface during construction:
public FileHistoryConfiguration( IJ4JLogger<FileHistoryConfiguration> histLogger, IJ4JLogger<FileHistoryService> svcLogger )
{
}
But if I register the type like this with autofac:
builder.RegisterGeneric( typeof(J4JSmsLogger<>) )
.As(typeof(IJ4JSmsLogger<>))
.SingleInstance();
where J4JSmsLogger<> is a class implementing IJ4JSmsLogger<>, then this call fails with an error that it can't find anything registered to provide an IJ4JLogger<> interface:
_fhConfig = _svcProvider.GetRequiredService<IFileHistoryConfiguration>();
I can work around the problem by changing the As<> clause in the registration of J4JSmsLogger<> to treat it as a IJ4JLogger<> instance, and then cast the result of resolving that interface to IJ4JSmsLogger<> whenever I need the extra capabilities of the child interface.
But I don't understand why I have to do that. Is there an additional step I need to take during registration of the types with autofac so that objects implementing the child interface will satisfy a need for the parent interface?
Cleaner Workaround
Reading more about autofac I learned something new: you can define as many As<>() clauses (including AsSelf()) as you want. So changing my autofac configuration to:
builder.RegisterGeneric( typeof(J4JSmsLogger<>) )
.As(typeof(IJ4JSmsLogger<>))
.As(typeof(IJ4JLogger<>))
.SingleInstance();
provides a cleaner solution than constantly casting resolved instances.
I'm not going to submit it as an answer, though, because I am curious why autofac doesn't do this kind of downcasting automatically, and whether any other DI frameworks do.
Autofac won't cast to base types for you like that. It generally assumes wiring is exact. You could run into some real problems if it didn't, like if someone has a constructor like...
public class BadTimes
{
public BadTimes(object input) { }
}
Which object does it put in there? Everything casts down to object.
However, you could always register it as both types and call it a day:
builder.RegisterGeneric(typeof(J4JSmsLogger<>))
.As(typeof(IJ4JSmsLogger<>))
.As(typeof(IJ4JLogger<>))
.SingleInstance();
The Header section (Apache Tiles Attribute) is shared by several views. It has a form that expects an Object when the page is loaded and complains if the Object is missing. At the moment I am placing the Object in a Model and passing it to the View using the Controller every time I create a view that inherits this layout.
This approach seems rather tedious as i have repeated lines all over the Controller. I'd like to be able to add it once and be done with.
I am not too familiar with Apache Tiles there maybe a simple solution that I am not aware of.
Looking for some helpful tips.
Thanks
You can use the HandlerInterceptorAdapter class and the postHandle method to achieve something like that. By cons, you will need to define a rule that will help you to know when the object need to be add to the model, it can be the path or something in the url, it depends on how your template is organized. Here an example of an interceptor that is doing something like that.
The interceptor defenition :
<mvc:interceptors>
<bean class="your.package.HeaderModelInterceptor"/>
</mvc:interceptors>
The interceptor class :
public class HeaderModelInterceptor extends HandlerInterceptorAdapter {
#Override
public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
ModelAndView modelAndView) throws Exception {
// Check if you need to add the object
if (Your rule) {
modelAndView.addObject("headerObject", headerObject);
}
super.postHandle(request, response, handler, modelAndView);
}
}
You have a couple of options to do this. Off the top of my head you could.
Use Tiles view preparers, simple example here
Use a mechanism like Spring interceptors or AOP to automatically add your object to the Model instead of repeating the code everywhere
It really depends on the nature of the object you're adding and how much context it needs.
I'm building a JAX-RS app that consists of a stockroom and a workplace. The stockroom holds a set of Java classes that can be instantiated (via AJAX) to create named instances of those classes in the workplace.
So far I'm able to reference the stockroom and workplace fine by declaring them as "singletons" in the RestEasy application
singletons.add(StockPlace.getInstance());
singletons.add(WorkPlace.getInstance());
I'm unable to understand how to understand how the stockroom content classes should be handled. The effect I'm trying to achieve is that when I dynamically create an instance of one of the stockroom classes, that instance can be dynamically accessed via REST commands. I've tried various permutations of:
classes.add(SomeComponent.class);
I think I'm missing knowledge of how the Java notion of how classes work as factories for making instances, and how both of these relate to what RestEasy calls classes, singletons (singletons ARE classes, yet RestEasy registers them as instances) and resources (instances?).
I suspect I'll wind up needing to dynamically register new instances but can't find a way to do that either. I did find a way to do it given the ServletContext, but am not able to get access to that either. Can someone get me on the right track?
Our eventual answer to this question was to bail out of RestEasy and convert to DropWizard. That problem and many others vanished and everything became easy again.
I believe I know what you are after, but I should at least give you a push in the right direction.
You will need to add the annotated RESTEasy class(es) to the registry. Below is the class I used for a recent project. It adds to the singletons (per what you did) but it also adds to the registry.
public class RESTEasyServerApplication extends javax.ws.rs.core.Application
{
// The RESTEasy registry
#Autowired
protected org.jboss.resteasy.spi.Registry registry;
// The annotated RESTEasy handler classes
private Set<Object> singletons = new HashSet<Object>();
private List<Object> handlers = new ArrayList<Object>();
public RESTEasyServerApplication()
{}
#Override
public Set<Object> getSingletons()
{
return singletons;
}
// Spring injection support
public void setHandlers( List<Object> handlers )
{
for( Object handler : handlers )
{
if( registry != null )
{
// Save a reference to the handler
this.handlers.add( handler );
// Register the handler with RESTEasy
registry.addSingletonResource( handler );
}
singletons.add( handler );
}
}
// Spring injection support
public List<Object> getHandlers()
{
return handlers;
}
}
I used Spring, and here is the relevant configuration:
<!-- RESTeasy/Spring integration -->
<import resource="classpath:springmvc-resteasy.xml" />
<!-- RESTeasy server application -->
<bean id="application" class="blah.blah.resteasy.RESTEasyServerApplication">
<property name="handlers">
<list>
<!-- Application specific handler classes -->
<ref bean="sample"/>
</list>
</property>
</bean>
Should be easy to modify/add a method to accept a single annotated RESTEasy class and make it work dynamically as required. The registry is defined in the springmvc-resteasy.xml file.
Since I've found no answers that don't involve strapping another whole layer of complexity (Spring) onto RestEasy, the solution I found livable is outlined in the final comment above. That is, don't rely on sending remote messages to instances unless the app is truly stateless (e.g. instances don't persist across messages). Only send remote messages to singletons which do persist across requests. Each such message can identify the desired instance (by String id in my case), and the singleton can forward to the identified instance as an ordinary POJO.
I still don't see why RestEasy unconditionally treats non-Singletons (instances) as ephemeral. Statelessness is not a restriction on REST, only a restriction on when GET methods can be used (idempotent calls). PUT and POST calls are neither stateless nor idempotent.
As I understand this, of course, and feel free to correct me. My focus is getting this app on the air, not exploring every corner of RestEasy, REST, and certainly not Spring.
I just got the grip on GWTP and the MVP, GIN and Dispatch.
With dispatch there is a Handler class which defines what the action does and returns something accordingly.
So far I found myself with a case where I have 2 actions that require to execute the same method. For which I believe ActionHandling is not where the bussiness logic goes, but that it should go in a layer behind it which pass something to it somehow
How should I layout my logic? I would like to use Hibernate later on btw.
EDIT:
as a note, applying the answers provided on practice, what needs to be done is:
1.- Create a module class that extends AbstractModule, this contains
bind(Service.class).to(ServiceImpl.class);
2.- on your GuiceServletcontextListener add your serviceModule to the getInjector method return:
return Guice.createInjector(new ServerModule(), new DispatchServletModule(), new ServiceModule());
3.- On yours actionHandlers constructors have something like this
#Inject
TestHandler(Service service) { this.service=service }
Business logic should be in your business objects, which are independent from your Handler classes. Try to design your business layer in a technology-agnostic way.
The handlers delegate all significant processing to the business objects, so they (the handlers) should be pretty thin actually.
You could try to inject the service layer into the handler. The service can be created as a singleton.
#Inject
public MyHandler(MyService service) {
this.service = service;
}
Is MyService an interface? If yes, you forgot to bind it inside Guice.
Personnaly I use DAOs to put my logic between ActionHandlers and my persistence framework (Hybernate, Objectify, Twig-Persist, etc.)
i have 2 concrete types "CategoryFilter" & "StopWordsFilter" that implements
"IWordTokensFilter".
Below is my setup:
ForRequestedType<IWordTokensFilter>().TheDefaultIsConcreteType<CategoryFilter>()
.AddInstances(x =>
{
x.OfConcreteType<StopWordsFilter>();
}
);
The problem is the run-time when structure map auto inject it on my class, bec. i have arguments with same plugin-type:
public ClassA(IWordTokensFilter stopWordsFilter, IWordTokensFilter categoryFilter)
i'm always getting CategoryFilter in my first argument but it should be stopWordsFilter.
How can i setup this in a right way? thanks in advance
There are a number of possible solutions:
1) Does ClassA need to differentiate between the filters, or does it just need to run them both? If not, you can change the constructor to accept an array, which will cause all registered instances of IWordTokensFilter to be injected:
public ClassA(IWordTokensFilter[] filters)
You can then foreach over the filters to apply them.
2) If you do need to differentiate them, because they need to be used differently, you may consider having one implement a marker interface the better describes its purpose. ClassA could then be changed to take in an IWordTokensFilter and an ICategoryFilter (or whatever you name the marker interface). Register CategoryFilter with ICategoryFilter and then both will be injected properly.
public ClassA(IWordTokensFilter stopWordsFilter, ICategoryFilter categoryFilter)
3) You can tell StructureMap explicitly how to create ClassA:
ForRequestedType<ClassA>().TheDefault.Is.ConstructedBy(c => {
return new ClassA(c.GetInstance<StopWordsFilter>(), c.GetInstance<CategoryFilter>());
});
4) You can tell StructureMap to override one of the dependencies for ClassA:
x.ForRequestedType<ClassA>().TheDefault.Is.OfConcreteType<ClassA>()
.CtorDependency<IWordTokensFilter>("stopWordsFilter").Is<StopWordsFilter>();