what is the difference between <osgi:reference> and <osgi:service> in the xml config file of spring DM.
<osgi:reference> can be used to get a reference to existing OSGi service so your bean can use it.
<osgi:service> can be used to export a bean as an OSGi service so it can be used by others.
Related
I have an older Web-Application using Eclipse RAP 3.0 with Equinox OSGI-Container and Gemini Blueprint 1.0.2.
I can define my JDNI Values in server.xml
link them in context.xml and use them in my web.xml.
In my launch.ini i use the parent classloader fwk so the JNDI configuration is passed to the OSGI-Container.
My Application-Bundles can read those values for example in Bundle-Activator:
String xxx= InitialContext.doLookup("java:comp/env/xxx"); or
String xxx= new InitialContext().lookup("java:comp/env/xxx");
Some Bundle-Configuration is done via Gemini Blueprint xml files and SpringConfiguration Java classes.
<jee:jndi-lookup id="xxx" jndi-name="java:comp/env/xxx" />
This part is not working and i get following error
Error creating bean with name 'xxx': Invocation of init method failed;
nested exception is javax.naming.NameNotFoundException:
Name [java:comp/env/xxx] is not bound in this Context. Unable to find [java:comp].
I get the same Error when i use Spring-Java-Configuration which is invoked from gemini blueprint xml. Then statements like new InitialContext().lookup("java:comp/env/xxx") don't work and i get the same exception.
I think it has to to with the classloaders that are different for Bundle-Activator-Code and Gemini BlueprintExtender Thread but in can't figure it out how to solve this.
I found a Solution that i can use.
If i Move my JNDI-Lookups from xml into my Spring-Configuration-class then i can change the clasloader in init like this:
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
After that i my Lookups work fine.
i found that solution here
Can Spring Boot be used with OSGi? If not, any plans to have an OSGi Spring Boot?.
We have an existing Spring MVC application (non Spring-boot application) with all (or most) of the beans configured in the XML. We wanted to use this as a Spring Cloud Config Client (we have a Spring Boot application acting as config server).
In this regard, what is the XML equivalent of configuring the beans in XML with refresh scope (same as #RefreshScope annotation). Tried configuring the RefreshScope as bean and using scope="refresh" but could see that the beans are not reflected with new values after peforming /refresh endpoint (from actuator)
Any help on this is highly appreciated
As pointed out in other answers 'refresh' scope is just another scope. However there's an issue where the bean properties are not updated with new values after /refresh call - if you define and inject properties in XML. More on the issue here. However the bean (i.e. actually the proxy) is instantiated after each /refresh call - but you need "aop:scoped-proxy" config since bean to which you inject the 'refresh' scoped bean, could be on a different scope. i.e.
<bean name="xmlValueBean" class="me.fahimfarook.xml.XMLValueBean" scope="refresh">
<aop:scoped-proxy proxy-target-class="true" />
</bean>
Well if you want to use #RefreshScope in core Spring(also Spring MVC) as people already pointed out, you have to implement the scope yourself also.
I also had the same dilemma and I did, I also wrote a blog about it, you can find there all the implementation details.
You can also use Spring Boot Configuration Server with your Spring MVC application, if you like to.
#RefreshScope for Spring MVC
#RefreshScope is just another scope. Look at how the RefreshScope class is implemented. It is creating a new scope named "refresh".
That means you should be able to use the new scope in your XML configuration, like this.
<bean id = "..." class = "..." scope = "refresh">
</bean>
Our application uses #Bean to define create beans and load them into the Spring context.
We now need to externalize these, so as to enable the application to be configured without touching the java source code.
We wish to replace the #Bean's with Groovy classes.
Is there a way to annotate a Groovy bean so that it will be picked up by Spring?
Note that we cannot simply reference each Groovy bean in the Spring XML, as we need to add and modify beans without touching the Spring code.
Thanks very much.
Use Spring config inheritance.
Move all shared code in a common "base" project that each individual / specific project depends on. Use Maven for this.
Create a common / base Spring config and put that into the "base" project. This config doesn't contain a definition for ProcessDefinition
In the specific project, create one bean which inherits from ProcessDefinition. Create a Spring config which imports the base config and define the single specific bean in it.
I want to make a call to a Spring bean (a #Component) from my message-driven bean (MDB) but have problems getting a reference to it. I've tried with a class implementing org.springframework.context.ApplicationContextAware which stores the Spring ApplicationContext in a static field in a class MyAppContext. The static field in MyAppContext is then accessed from the MDB. But MyAppContext is loaded from different classloaders. The Spring application context is correctly set in the web module classloader context, but in the MDB's classloader context, it's null.
Can I somehow instruct JBoss to use the same classloader for the web app and the MDB?
Or is there a better way than storing the Spring application context in a static field?
Thanks for any advice!
A static holder for the context is not really a good idea. To make your beans available to other applications in a Java EE environment, you should consider making use of JNDI.
Unfortunately, there is no plain JNDI exporter available out of the box, but it's fairly easy to write one yourself, as shown in this blog post: http://maestro-lab.blogspot.ro/2009/01/how-to-export-spring-managed-bean-to.html
There is however a JndiRmiServiceExporter that you may want to look at.
Once your beans are bound to names in JNDI, they can be referenced using standard CDI in your message bean without worrying about class loading issues.
Why not use "ClassPathXmlApplicationContext" to load and look up for the Spring bean you require in your MBean?
In the spring configuration file applicationConfig.xml, the root node is beans.
But it doesn't contain only beans. In fact, security configuration requires an http element.
My question is: while http is not (seems to me not to be) a bean, is it "bean like" in the sense that it determines the creation of a service, or refers to a running service (say the http listener for the application)?
PS. In "Spring Security Reference documentation" 3.1.0-DRAFT at 2.1.1:
"Web/HTTP Security (...) Sets up the filters and related service beans used to apply the framework authentication mechanisms ..."
Yes, everything in a Spring config is just setting up beans. You could--and in fact used to be forced to--set up all the beans yourself, but along about Spring 2.0, the framework added a nifty feature that they called "Extensible XML Authoring", which gives other people/projects a way to define their own, custom XML syntax that gets translated into Spring beans at startup via a NamespaceHandler.