The SpringApplicationContextLoader assumes that the application is either using 100% XML or 100% Java config. This is because #ContextConfiguration allows either a list of classes or locations/value, not both. If any is specified, SpringApplicationContextLoader ignores the Application class that creates and starts the SpringApplication.
Trying to make Boot work with a 100% Groovy/no-XML pet project, I ran across the above issue. My Application class has #EnableAutoConfiguration and #ComponentScan annotations on it, the former required by Boot to set up a Web server. The later I had to keep because of SPR-11627. On the other hand, if I omitted the locations/value on #ContextConfiguration, dependencies weren't set up (duh!).
I give the code below along with a patch that I locally made to SpringApplicationContextLoader. If there's a better way, please let me know.
MovieDatabaseRESTClientIntegrationTest.groovy
RunWith(SpringJUnit4ClassRunner)
#ContextConfiguration(value = ['classpath:client-config.groovy', 'classpath:integ-test-config.groovy'],
loader = PatchedSpringApplicationContextLoader)
#SpringApplicationConfiguration(classes = MovieDatabaseApplication)
#WebAppConfiguration
#IntegrationTest
class MovieDatabaseRESTClientIntegrationTest {
MovieDatabaseApplication.groovy
#EnableAutoConfiguration
#ComponentScan
class MovieDatabaseApplication {
SpringApplicationContextLoader.java fix
private Set<Object> getSources(MergedContextConfiguration mergedConfig) {
Set<Object> sources = new LinkedHashSet<Object>();
sources.addAll(Arrays.asList(mergedConfig.getClasses()));
sources.addAll(Arrays.asList(mergedConfig.getLocations()));
/* The Spring application class may have annotations on it too. If such a class is declared on the test class,
* add it as a source too. */
SpringApplicationConfiguration springAppConfig = AnnotationUtils.findAnnotation(mergedConfig.getTestClass(),
SpringApplicationConfiguration.class);
if (springAppConfig != null) {
sources.addAll(Arrays.asList(springAppConfig.classes()));
}
if (sources.isEmpty()) {
throw new IllegalStateException(
"No configuration classes or locations found in #SpringApplicationConfiguration. "
+ "For default configuration detection to work you need Spring 4.0.3 or better (found "
+ SpringVersion.getVersion() + ").");
}
return sources;
}
Also posted on Spring forum.
I could be wrong but I don't think there is any support for beans{} configuration in #ContextConfiguration and #SpringContextConfiguration is just an extension of that. A feature request in JIRA would be appropriate. Also there has never been any support for mixed configuration format (as the entry point at least) - you always have to choose either XML or #Configuration, or else supply your own ContextLoader. You also shouldn't have both #ContextConfiguration and #SpringContextConfiguration on the same class (the behaviour is undefined).
Related
I'm developing a wizard that implements the org.eclipse.pde.ui.IPluginContentWizard interface. Thus it gets added as plug-in project template in the end of the plug-in project wizard. All files will be created just fine, but there is one error in the project. The plug-in is not declared to be a singleton which it must be when extending extension points.
How do I do that within the wizard? I figured it needs to be done in performFinish(IProject project, IPluginModelBase model, IProgressMonitor monitor) but neither the project nor the model gives me a possibility to do so.
Edit: For future readers: My mistake was, that I didn't add the extension via the API but rather via generating the plugin.xml "by hand". This caused no mechanism in the background to do their job and thus the singleton directive wasn't set.
This way will be too long, let's use more PDE API:
First, define the template section
import org.eclipse.pde.ui.templates.OptionTemplateSection;
public class YourTemplateSection extends OptionTemplateSection {
//implement abstract methods according your needs
#Override
protected void updateModel(IProgressMonitor monitor) throws CoreException {
IPluginBase plugin = model.getPluginBase();
//do what is needed
plugin.add(extension);//here the "singleton" directive will be set
}
}
then use the section with wizard
import org.eclipse.pde.ui.templates.ITemplateSection;
import org.eclipse.pde.ui.templates.NewPluginTemplateWizard;
public class YourContentWizard extends NewPluginTemplateWizard {
#Override
public ITemplateSection[] createTemplateSections() {
return new ITemplateSection[] { new YourTemplateSection() };
}
}
In case one does the same rookie mistake then me, I wanted to post my solution I came up after revisiting the project later:
Don't create the plugin.xml manually, use the PDE API of the plugin model to add extensions.
In the org.eclipse.pde.ui.IPluginContentWizard implementions's performFinish(...) method do this:
try {
IPluginExtension extension = model.getExtensions().getModel().getFactory().createExtension();
extension.setPoint("org.eclipse.elk.core.layoutProviders");
IPluginElement provider = model.getPluginFactory().createElement(extension);
provider.setName("provider");
provider.setAttribute("class", id + "." + algorithmName + "MetadataProvider");
extension.add(provider);
model.getExtensions().add(extension);
} catch (CoreException e) {
e.printStackTrace();
}
Please forgive my non-native English:
In short, What is the best way for a tenant to override default IEnumerable<T> registration?
TL;DR So I have a service ServiceToBeResove(IEnumerable<IShitty> svcs) need an IEnumerable<IShitty> dependency, but we found not all our tenants have services registered as IShitty, so in our application container we create an not implemented NoImplementShitty and register it as a TypeService of IShitty to server as a default one to make resolve process happy, we do get tenant-specific if tenant have registration and this default non-implemented if tenant forgot to register. But we soon find the ServiceToBeResove will have both tenants implemented registered IShitty and the default NoImplementShitty for its dependence of IEnumerable. What I really want for the IEnumerable<IShitty> dependency is just used tenant registered (registered 1 or more), if tenant not registered, just use the default NoImplementShitty as the IEnumerable<IShitty>. I have played with .OnlyIf(), OnlyIfRegistered(), .PreventDefault() on the app container and it really not helps since autofac will build default first and then tenant. I can certainly use the NoImplementShitty for all the tenant that missing registration of IShitty but it doesn't seem to take the advantage of multiple tenant's override-default features.
To be more specific, In our base AgreementModule, we have
builder.RegisterType<NoOpAgreementHandler>() //NoOpAgreementHandler is the IShitty
.As<IAgreementHandler>()
.InstancePerLifetimeScope();
In our tenantA, we have
public class TenantAContainerBuilder : ITenantContainerBuilder
{
public virtual object TenantId => "1";
public virtual void Build(ContainerBuilder builder)
{
builder.RegisterType<TenantAAgreementHandler>()
.As<IAgreementHandler>()
.InstancePerLifetimeScope();
}
}
We build container as below:
var appContainer = builder.Build();
var tenantIdentifier = new ManualTenantIdentificationStrategy(); //We have our own strategy here I just use the ManualTenantIdentificationStrategy for example
var multiTenantContainer = new MultitenantContainer(tenantIdentifier, appContainer);
//GetTenantContainerBuilders will basically give you all TenantBuilder like TenantAContainerBuilder above
foreach (IGrouping<object, ITenantContainerBuilder> source in GetTenantContainerBuilders().GroupBy(x => x.TenantId))
{
var configurationActionBuilder = new ConfigurationActionBuilder();
configurationActionBuilder.AddRange(source.Select(x => new Action<ContainerBuilder>(x.Build)));
multiTenantContainer.ConfigureTenant(source.Key, configurationActionBuilder.Build());
}
When try to resolving the service, if we do:
public DisbursementAgreementManager(IEnumerable<IAgreementHandler> agreementHandlers)
{
_agreementHandlers = agreementHandlers;
}
The agreementHandlers will be an IEnumerable of NoOpAgreementHandler and TenantAAgreementHandler, seems wierd to have NoOpAgreementHandler and I thought we will only get TenantAAgreementHandler. But if we change the DisbursementAgreementManager to
public DisbursementAgreementManager(IAgreementHandler agreementHandler)
{
_agreementHandler = agreementHandler;
}
We will get only the TenantAAgreementHandler which is expected.
The default behavior of Autofac is there for a reason. Asking it to do it differently would be adding application logic at the dependency-injection level, which violates the separation of concerns (DI should only inject dependencies) and leads directly to surprising behavior ("Why did DI not inject every available component?") and undercuts the maintainability of the system.
This may be a non-issue.
The logic is self-contained inside each IAgreementHandler.
If so, at the point where they are invoked by DisbursementAgreementManager, they are all called and then perform their own logic (which may include a decision whether to do anything all). E.g.:
foreach (var ah in _agreementHandlers) ah.Agree(disbursementInfo);
or maybe something like
foreach (var ah in _agreementHandlers.Where(a => a.ShouldRun(data) || overridingCondition))
{
var agreement = ah.Agree(info);
this.Process(agreement);
}
or whatever. The point is that if NoOpAgreementHandler is doing what it is supposed to (that is, nothing) then it should have no effect when it is called. No problem.
If the situation is other than described, then NoOpAgreementHandler and possibly IAgreementHandler need to be refactored.
There is another point of concern:
The reason we add the no-op is we have unit tests for registration/resolve in order to make sure all registration is properly configured.
Your testing requirements are bleeding into your primary logic. These DI configuration tests should be independent of the production DI configuration. NoOpAgreementHandler shouldn't even be in your primary project, just a member of the unit test project.
I have a jpa configuration file with #EnableJpaRepositories annotaion. I set this annotaion value from application.properties file like this :
#EnableJpaRepositories("${jpa.repository.packages}")
public class JPAConfiguration {
....
}
and here is my application.properties file:
jpa.repository.packages=com.epms.model
and it works perfect. but i want to specify multiple packages for #EnableJpaRepositories . so i changed my config file to this :
jpa.repository.packages=com.epms.model,com.ecms.model
and also configuration file to this :
#EnableJpaRepositories("#{'${jpa.repository.packages}'.split(',')}")
public class JPAConfiguration {
}
but it's not working . any idea ? how can i do this in my configuration file?
As #amicoderozer is asking, if your classes share a common base package you only must indicate that root package.
If it's not your case (despite you are loading from a config file or you are declaring them manually) maybe the problem (will help posting any Exception or Runtime trace) is the way the split method is used. It returns an array, and I guess the generated code will be like this:
#EnableJpaRepositories("jpa.repository.packages1","jpa.repository.packages2")
That code doesn't compile.
Never tried Spring EL inside the annotation of a component, but despite this, maybe you should indicate the basePackages this way:
#EnableJpaRepositories(basePackages = "#{'${jpa.repository.packages}'.split(',')}")
If doesn't work, I recomend you first test it by manual array declaration:
#EnableJpaRepositories(basePackages = { "com.epms.model","com.ecms.model" })
Be sure all works as you expect, and then try again reading and parsing from config file.
UPDATE:
After some readings, I've concluded that is not possible do what you want. The SpEL is allowed in many places but for annotations there is only documentation and working examples with #Value annotation.
I'm working on a Java web app which utilises Spring's ConversionService API.
Converters look like this:
public class MyCustomConverter implements Converter<MySourceClass, MyTargetClass> {
#Override
public MyTargetClass convert(final MySourceClass source) {
// ...conversion code...
return myTargetClass;
}
}
and are registered in the application config, e.g:
#PostConstruct
public void addConverters() {
genericConversionService.addConverter(myCustomConverter);
// ...others...
}
A conversion can then be applied like this:
MyTargetClass result = conversionService.convert(mySource, MyTarget.class);
The problem I'm having is finding usage within the code of a particular converter (such as the example directly above). Am using Eclipse IDE - could anyone suggest a way to do this?
If you want to see all the references made to the method ConversionService.convert, you can highlight the convert method and use the Eclipse short-cut Ctrl + Shift + G. This will search the method inside your entire workspace. To search only in the project, you can right-click on the method and select References > Project.
To restrict the references search with a specific method parameter, see this answer : https://stackoverflow.com/a/11836545/1743880.
I want to use the default XML editor (org.eclipse.wst.xml.ui) of Eclipse in an RCP application. I need to read the DOM of the xml file currently open. The plugin doesn't offer any extension point, so I'm trying to access the internal classes. I am aware that the I should not access the internal classes, but I don't have another option.
My approach is to create a fragment and an extension point to be able to read data from the plugin. I'm trying not to recompile the plugin, that's why I thought that a fragment was necessary. I just want to load it and extract the data at runtime.
So, my question is: is there another way to access the classes of a plugin? if yes, how?
Any tutorial, doc page or useful link for any of the methods is welcome.
Since nobody answered my question and I found the answer after long searches, I will post the answer for others to use if they bump into this problem.
To access a plugin at runtime you must create and extension point and an extension attached to it into the plugin that you are trying to access.
Adding classes to a plugin using a fragment is not recommended if you want to access those classes from outside of the plugin.
So, the best solution for this is to get the plugin source from the CVS Repository and make the modifications directly into the source of the plugin. Add extension points, extensions and the code for functionality.
Tutorials:
Getting the plugin from the CVS Repository:
http://www.eclipse.org/webtools/community/tutorials/DevelopingWTP/DevelopingWTP.html
Creating extensions and extension points and accessing them:
http://www.vogella.de/articles/EclipseExtensionPoint/article.html
http://www.eclipsezone.com/eclipse/forums/t97608.rhtml
I ended up extending XMLMultiPageEditorPart like this:
public class MultiPageEditor extends XMLMultiPageEditorPart implements
IResourceChangeListener {
#Override
public void resourceChanged(IResourceChangeEvent event) {
// TODO Auto-generated method stub
setActivePage(3);
}
public Document getDOM() {
int activePageIndex = getActivePage();
setActivePage(1);
StructuredTextEditor fTextEditor = (StructuredTextEditor) getSelectedPage();
IDocument document = fTextEditor.getDocumentProvider().getDocument(
fTextEditor.getEditorInput());
IStructuredModel model = StructuredModelManager.getModelManager()
.getExistingModelForRead(document);
Document modelDocument = null;
try {
if (model instanceof IDOMModel) {
// cast the structured model to a DOM Model
modelDocument = (Document) (((IDOMModel) model).getDocument());
}
} finally {
if (model != null) {
model.releaseFromRead();
}
}
setActivePage(activePageIndex);
return modelDocument;
}
}
This is not a clean implementation, but it gets the job done.