I have a project, work with Vaadin 8.6 and Spring 5, and vaadin-spring 3.1.1
In this, there is MainUI extends UI that a bean with scope="prototype" initialized in web-application-context.xml
Problem: when we connect to project from more than one client (browser), there is only one session available.
we search and find some manuals, but we can not use it in our project
<bean id="mainUI" class="ir.fanap.fanitoring.ui.MainUI" scope="prototype">
Vaadin Spring Add-on
how can we solve this problem? we did not use annotations for beans and all beans initialized in web-application-context.xml
Related
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>
I have a fully functional Restlet app that I am trying to add Spring Data Jpa + Hibernate.
Firstly I need to get Spring and Restlet playing together.
The example below is from the Restlet docs, it is trying to set a root property on the Application Class, I can not find this root property, it must be from and old version of the API.
Can someone please post an example of Spring and Restlet 2.2 config, this is very frustrating.
<bean id="basecampAppliction" class="classpath to Application class">
<property name="root" ref="router" />
</bean>
Also, all the examples I have found rely on Spring doing the routing, I would like to keep the routing in the Application code if that is possible.
The docs on the Restlet web site are out of date, please see fix above.
Can anybody tell me what is replacement of
<bean id="authenticationSuccessHandler" class="org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler"/>
in Spring Security 2.0.2.
any help would be appreciated.
The same class in the same package is still there. If you use the namespace configuration, you don't have to declare this bean manually, because the <security:form-login> element will wire it up by default.
I have an enterprise application built with Java 6, Spring Framework 3.1.2 and Mule-ESB 3.3.0, among other libraries not related to this question.
Our beans and services are all declared with #Named and #Inject JSR-330 annotations, respectively for automatic component scanning and for dependency injection (no EJBs, only service beans). When deployed into JBoss 4.2.3 (our test environment) everything works fine. However, when deployed into WebSphere 7, the JSR-330 annotations seem not to be working. The beans marked with #Named are just not detected, at all.
I can assure everything is configured right (since it is working in JBoss). Specifically, the <context:component-scan /> has the base-package attribute correctly defined and the scope-resolver attribute correctly configured to use Jsr330ScopeMetadataResolver (we tried without it too).
I am aware WebSphere 7 (7.0.0.23) may not support such kind of annotations. I am yet to test it with #Component and #Autowired Spring equivalents. Unfortunately, we would very much like to use JSR 330 annotations so our classes wouldn't directly depend on Spring, even though we're using Spring Framework under the hood.
Nevertheless, although I'd spent one full work's day looking for a definite statement that WebSphere 7 does not support JSR 330 annotations, I haven't found anything so far.
Further, I can't see why it would not work, since I'm assuming Spring Framework is the one doing all the work, through the <context:component-scan /> directive in the application-context.xml file.
Can anyone bring some light into this issue?
Is there a way to activate dependency injection via annotations in WebSphere 7?
If I switch back from the JSR 330 #Named / #Inject annotations to Spring's own #Component and #Autowired is it likely to work?
In a desperate attempt, can I extend Spring's ComponentScanBeanDefinitionParser so it will detect JSR 330 annotations even in WebSphere 7?
If nothing works, I will eventually fall back to plain XML configuration. That is highly undesirable, however, because there will be hundreds of beans to be manually configured in the XML.
WebSphere 8 seems to be the correct version to use; it supports EE6 (WebSphere 7 is EE5), which in turn contains CDI 1.0 (hence JSR 299).
Below is a snippet from DeveloperWorks that summarises relationship between WebSphere versions, JSR 299 and JSR 300
Dependency injection is a technology that has surfaced in various
implementations many times before making it into the Java EE world.
The Spring Framework and the Google Guice library are popular
implementations. In JSR 330, an attempt was made to include these
capabilities into the J2SE platform. JSR 299 is a specification that
used the APIs defined in JSR 330 and added more capabilities to
support Java EE needs. IBM WebSphere Application Server V8 and V8.5
(non-Liberty profiles) are fully compliant Java EE 6 containers and
implement JSR 299.
I eventually came up with a workaround by extending both Component Scan and Autowire features of Spring Framework.
First, I added an inclusion filter to the Component Scanner so that #Named annotations were also considered eligible for detection and registration to the Spring Container:
<context:component-scan base-package="com.mycompany.mysystem">
<context:include-filter type="annotation" expression="javax.inject.Named" />
</context:component-scan>
Following that, I also added a bean definition to org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcesso‌​r, extending the autowiring eligibility to #Inject annotations:
<bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor">
<property name="autowiredAnnotationType" value="javax.inject.Inject" />
</bean>
Initially, this worked fine as to "reactivating" the #Named and #Inject annotations. However, I still had some problems of conflicting beans on the autowire candidates resolution process. This was due to the differences in the default resolution process of Spring and of JSR-330. This was no big issue, since only a few beans fell into that scenario. They were all solved by adding some strategically placed #Qualifier annotations.
Now everything is working fine and elegantly, with few extra configurations. Nevertheless, I still don't understand why this happened. All I know is that the following 3 lines do appear when I deploy the application into JBoss 4.2.3. On the other hand, they don't appear in WebSphere:
INFO [org.springframework.context.annotation.ClassPathBeanDefinitionScanner] JSR-330 'javax.inject.Named' annotation found and supported for component scanning
and
DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Creating shared instance of singleton bean 'org.springframework.context.annotation.internalAutowiredAnnotationProcessor'
DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Creating instance of bean 'org.springframework.context.annotation.internalAutowiredAnnotationProcessor'
INFO [org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor] JSR-330 'javax.inject.Inject' annotation found and supported for autowiring
I still have no clue as to why this happens, since, as #Dreamer said, this should be a Spring's responsibility, and thus, out of WebSphere business.
If someone do have such a clue, please enlighten us. Im sure it would be wonderfully clarifying to everyone participating in this discussion.
Agree with duffymo, it should work on WS 7. As Spring is on top of Websphere so Spring annotation is out of webshere's business(sort of).
One thing you probably need to check on WS 7(even though you said every configuration is correct as it works on JBoss) is click your application -> click Class loading and update detection, make sure the Classes loaded with local class loader first (parent last) is checked. That would make the server to take your application's library come first followed by websphere's library.
I use web profile and it does not allow to use Java EE #Schedule functionality. So, I have several ways to solve the problem:
reinstall the server to use full profile. Problems: it's risky (functionality/performance) for my production and burdensome
Use other scheduling functionality like Spring. Problems: I don't know how to link Spring with JavaEE as I want to use CDI beans in my scheduler. Seam-spring module could help me (http://sfwk.org/Seam3/SpringModule) but its documentation is not available at the moment and I don't really know the status of it.
So, which is the best way to enable scheduling inside my glassfish app?
Thanks
We've had a lot of luck using the Quartz open source job scheduler within Spring on other projects so I can highly recommend it for scheduling. You can configure the scheduler to be started from a Servlet (into which CDI beans can be injected) and the scheduled job can call an EJB Stateless Session bean (into which you can also inject CDI beans).
Here are some links - hope this helps!
Initialze a Scheduler in a servlet container
Here's a great article on calling an EJB from Quartz
Ok, I managed to do this using spring module. Would be better to use embedded Scheduler J2EE functionality, but this is not included into Glassfish web profile, only to full (WTF??). As my project is in prod, I don't want to upgrade to full one, especially as there is no flexible way to do this upgrade. Only full server substitute. Very poor JavaEE....
So, first, we need to define some functionality, which will be run at schedule:
#Scope(value="application")
public class ClosePolisesTimer {
BusinessAttirbuteDAO attributeDAO;
#Scheduled(cron="0 0 0 * * *")
public void doCloseObsolete() {
// ...
}
}
Second, we should create the spring configuration file with the following configuration:
<bean id="businessAttributeDAOBean" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:global/KaskoCalculator/BusinessAttirbuteDAO" />
</bean>
<bean id="ClosePolisesTimer" class="com.rstk.kasko.bean.service.ClosePolisesTimer">
<aop:scoped-proxy />
<property name="polisDAO" ref="polisDAOBean" />
<property name="attributeDAO" ref="businessAttributeDAOBean" />
</bean>
<task:annotation-driven scheduler="closePolisExecutor"/>
<task:scheduler id="closePolisExecutor" pool-size="1"/>
That's all. I define EJB beans and use "aop:scoped-proxy" to initialize my scheduler by them. Spring schedule is included into core spring module, so only core spring dependency is necessary