Is it possible to export REST resources with custom (spring data) repositories?
How does it work?
I cannot find any example. I also have not found any claim that it is impossible.
Spring data rest specifically detects and does not export custom implementations on repositories. See the reference to the codebase here and the reason why here.
If you want to expose a custom repository implementation, you will need to use a custom controller. Documentation for how to appropriately use custom controllers is slated for Spring Data Rest 2.4 .
We used these two methods and both work fine so far:
Implement custom controllers to utilize your custom service layer
Implement a custom repository factory (e.g. extending from RepositoryFactoryBeanSupport), build your own PersistentEntityInformation and take care of CRUD ops manually for your custom data storage type.
UPDATE: Look into this chapter of the documentation: Adding custom behavior to all repositories. The idea is to replace the default storage-specific implementation with your own using #EnableJpaRepositories(repositoryBaseClass = MyRepositoryImpl.class).
If you want to build a custom storage SPI that's a different story. You can use a spring-data-keyvalue and implement your own KeyValueOperations bean that you specify for #EnableMapRepositories. Look into spring-data-redis source as an example of that implementation. That's the easiest solution.
Building a complete SPI for own repositories from scratch needs more code. We followed sources from spring-data-elasticsearch. You might need to implement:
Metadata: CustomEntityInformation, CustomEntityMappingContext, CustomPersistentEntity, CustomPersistentProperty.
Integration: #EnableCustomRepositories, CustomRepositoriesRegistrar, CustomRepositoryConfigurationExtension, CustomRepositoryFactory, CustomRepositoryFactoryBean.
Implementation: CustomRepository (Base interface), CustomRepositoryImpl (Default implementation).
And still needs some extra code for spring-data-rest support, for example, search resources are not exposed automatically, so we build search resources manually. Then you might want to add queries support on top, etc.
Summarizing, the answer is yes, possible by implementing own storage SPI, but not easy. Should first look for other solutions including:
projections
resource processors
custom controllers
other spring data rest customization possibilities
In our web project we are using Ninject. Now we are adding plugins to our application. We want plugins to be able to add their own bindings. Ninject modules seems like a logical solution to this problem.
However, I don't see any guidance on how to avoid the following problem. What if a plugin adds a binding to an interface that already had a binding. Now the DependencyResolver will throw an exception when trying to resolve that interface.
I'm trying to make a change to our DependencyResolver that doesn't require rewriting all of the binding statements we've already written in the main application. I don't want a plugin to be able to break my main application. If a plugin needs to apply constraints to make it's bindings work then it is its responsibility.
So here's what I want.
A plugin would not be able to break the core app or another plugin because it added a binding.
It should not be necessary for any change to be made to core application or another plugin when I want to add a new plugin with its own bindings
Where there are multiple instances to choose from it should do the "logical" thing. The core app should get the instance it always would have gotten in the absence of the new plugins. The plugin should get the instance it specifically bound.
It seems like I should be able to override the resolving methods of StandardKernel so that it can implement these rules. It seems like knowing what module a binding was a part of would help resolving. But I can't find module or module name as part of the context, request, bindinginfo, etc.
Any thoughts on how to resolve this issue. I don't see that Ninject seems to answer what seems like a very obvious need for a modular system. A new module shouldn't be able to break an app. (It should only be able to "break" itself.)
You should have a look at Ninject.Extensions.ChildKernel. You could create a ChildKernel per plug-in and then load the plugins' module in their own ChildKernel.
This means that a plugin cannot rely on the bindings of another plugin, but a plugin may rely on the bindings of the Parent Kernel (root / application kernel). So you can provide certain types/services to the plugins.
By the way, if the implementation of Ninject.Extensions.ChildKernel does not match your needs, you might very well choose to implement your own extension. It's not that much code (see ChildKernel source)
I am trying to figure out how to get runtime parameters setting using IOC setup in MVC4.
I have not selected an IOC framework yet and am happy to take suggestions. I would prefer to avoid NInject, as I have heard that it is fairly slow.
I need to specify my IOC After login. So I am thinking that I need to create a FilterAction that will handle this. Is this the best place to do the IOC or is there a better place?
I have seen a lot of IOC examples that do the specification at design time and I but I could not find anything that made the IOC container via a filterAction or some other sort of post-login event.
Any help would be appreciated.
Ideally you should write a custom IDependencyResolver your your favorite DI framework. This resolver will be used by ASP.NET MVC to inject dependencies into common structures such as controllers. And to avoid reinventing the wheels search for a DI framework which already has an MVC extension to id adding this dependency resolver (probably the NuGet package will be suffixed with .MVC, for example Unity.Mvc3 or Ninject.Mvc3, ...). The container setup is then performed in your Application_Start.
I'm using the same DAL infrastructure for a console application and a MVC web application and I need to have things configured for InRequestScope in the MVC web application but need to know what the default fallback for InRequestScope is when the OnePerRequestModule hasn't been configured (as would be the case in my console application).
Edit
My version of Ninject is 3.0.1.10.
Have a read of the Cache and Collect article by Nate Kohari.
Recent versions of Ninject separate out the OnePerRequestModule into a Ninject.Web.Mvc assembly so you wouldn't even be able to see an InRequestScope extension without working in that context.
For a console app, often you're not working lots of requests coming and going that would need to be Disposed, so the default scoping of null which InTransientScope [and not specifying a scope] and/or allowing implicit self-registration of classes leads to might be perfectly appropriate. However in general, you're best off figuring out what your unit of work is and explicitly managing when stuff requiring Disposal needs taking care of (as the objects will not be scoped, no Disposal will take place, just Finalizers will kick in [with timing dictated by Murphy's law]).
The scoping section of the wiki is also worth a read on this topic.
what is the difference between these two terms, thanks in advance for any good simplifications and good examples.
A framework is a group of classes, interfaces and other pre-compiled code upon which or by the use of which applications can be built.
The API is the public face of a framework. A well designed framework only exposes those classes, interfaces, etc that are needed to use the framework. Code that supports the operation of the framework but that is not necessary to users of the framework is kept internal to the framework's assemblies/dlls. This keeps the public face of the framework small and encourages a "pit of success," or the quality of a framework which makes it simple to do the right thing.
(I provide an example from the .NET world)
The SqlConnection class is used to connect to a Sql Server instance. Its public API is pretty simple:
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open();
// Do work here; connection closed on following line.
}
However, this class depends on around 200 methods within the System.Data framework (in this case, an assembly), 3/4 of which are internal and not part of the public API of System.Data. Because the framework's API is kept simple, it becomes easy to use SqlConnection properly. If the user was required to deal with SqlConnectionFactory, SqlDebugContext, DbConnectionPoolGroup or any of the other internal classes required by the SqlConnection class, it would become exponentially more difficult to use SqlConnection properly. Because the API only exposes a small percentage of the framework, it is easier to create and use a connection.
An API is an interface to a (set of) component(s) encapsulating a functionality. For instance, the GoogleMaps API, the DirectX or OpenGL APIs.
A framework is more a set of tools, components aimed at helping the developer to develop his/her project in a given Frame. The framework usually sets some coding standards, provides useful components, ... For instance, Symfony/Cake are PHP web application frameworks. JUnit is a framework for unit tests in Java, ...
Frameworks can often bundle/provide a unified interface to some APIs.
Some APIs can be internally built using a framework.
API - application programming interface -> the contract you must obey when using a library's API
library - a set of classes/modules that solve a specific problem -> has an API
framework - a "bigger" set of libraries with a set of rules on how to use them
Since every library has an API, no point in giving examples.
A popular Java library for time is Joda time.
A popular Java framework is the Spring framework.
You must obey a lot of rules to use Spring well. You don't have to obey as many rules to use Joda time.
An API is something code has, not something it is. A framework has an API, but it is not itself an API.
API "Application Programming Interface" is set of prewritten packages, classes and interfaces with their respective methods. You can use it without much concern about internal implementations. API is used an interface between two or more applications and like REST API.
Framework is a skeleton that contains design patterns, classes, interfaces and libraries that can be used to build applications. Framework provides inversion of control which give the responsibility of program flow to the framework itself, also we can extend the framework without changing its predefined code. For example Spring is a framework that can be used to build web applications.
API's are pre-built-in from SDK (or from which you can include on to). Frameworks are loadable bundles wherein exposed functions of such bundles can be used. You can acquire expose functions of those frameworks by using pointer to functions.
Example:
API:
-stringWithString:
function from framework:
-myExposedMethod:
Framework is use to design an application, ie MVC, MEF. Like a model that you build on, almost a base for a certain set of functionality that you might want in your application.
API is for interaction between applications, your app would use the Facebook API to interact with Facebook.
Hope this is a bit more clear.
Java API simply means ...Application Programming Interface in which all the features describes of product or software.
Java Framework means semi-completed project or code. It provides an architecture to make project . Framework have own classes and methods etc..
An API is simply a library built with a particular language that developers can use to build applications.
Frameworks are a set of libraries, just like APIs however the syntaxes may deffer of the original language. So the developer may be writing a different syntax of PHP for example when using Symphony.
The main or core difference beteen framework and API is that framework allows developer to hook into the life cycle of the objects through lifecycle callback methods mechanism whereas API doesn't do that, API is only intended to perform a functionality only.
Another way to visualize it is this: (true of any programming language)
Any(!) "piece of software that is intended to be used by another piece of software" by-definition must have some "application program interface (API)," which represents the "knobs, switches and dials" that the other piece of software is expected (and, permitted) to use. All of the internal implementation details are not visible and cannot be reached.
"Frameworks" are tools that are designed to make it easier for humans to write a particular, common, type of application – such as a web-page. The framework implements "the stuff that every such application is going to need to be able to do," and does it in one, well-tested way, "precisely so that you (the application author) don't have to." Instead of redundantly writing "the same old thing, one more time, and fretting over whether you did it correctly," you simply leverage what the framework has already done for you.
After all...
Actum Ne Agas: Do Not Do A Thing Already Done.