I enabled LTW for my Spring application and as long as the advised bean in question is free of Spring's AOP features, the classes are woven properly - that is, in-method bytecode modification rather than proxies.
However, once I add tx:annotation-driven and #Transactional to that bean, all methods, even those having nothing to do with Spring features, that previously were woven with proper bytecode, now all get called via JDK proxy.
Which probably means I have to let go of tx:annotation-driven and configure AspectJ to use Spring's tx:advice for methods annotated with Spring's #Transactional.
But how do I access Spring beans from AspectJ configuration?
The only solution I found is to add AspectJ compiler to the build toolchain and implement the AbstractTransactionAspect.aj aspect and on Spring startup call TheImplementedAspect.aspectOf().setTransactionManager().
Related
We have a widlfy REST API jaxrs and we want to secure it with keycloak.
The problem is the integration with #SecurityDomain("keycloak") is working only with an EJB entry-point. it is ignored on class with no #Stateless annotation
The issue is the entry point become an EJB and EJB poolManaged what is not really a good thing for a stateless application.
Moreover all methods in EJB are transactional and we do not want this behavior. So yes we can add an annotation transactional to specify to not use transaction in the method, but i think it is a workaround.
We want to work the most we can with CDI. and have entry point with ejb pool management with in wildlfy 20 EJB in same time can be a bottleneck in a big application.
Any idea ? or proper way to implement keycloak security with CDI ?
If you mean declarative security using #RolesAllowed annotation this is not supported on all CDI beans, is only supported by EJBs and Servlets.
As JAX-RS will run on a webapp, you can use declarative security based on url-patterns and HTTP methods using security-constraints in web.xml
You can also implement programmatic security in the JAX-RS methods (or in a filter), using the SecurityContext.
#Context
SecurityContext securityContext;
#GET
public Response get() {
if (securityContext.isUserInRole("ROLE")) {
....
}
....
}
Although not and standard feature, Wildfly JAX-RS implementation, RestEasy, can be configured to support #RolesAllowed annotations. See:
https://docs.jboss.org/resteasy/docs/4.4.2.Final/userguide/html/Securing_JAX-RS_and_RESTeasy.html
In the spring cloud eureka documentation:
The Eureka server is tied to log4j and doesn’t work with logback, so the dependency configuration has to be tweaked compared to a normal Spring Boot app. The spring-cloud-starter-eureka-server does this for you, but if you add logback transitively through another dependency you will need to exclude it manually, e.g. in Maven
From the SLF4J documentation:
The log4j-over-slf4j module will not work when the application calls log4j components that are not present in the bridge. For example, when application code directly references log4j appenders, filters or the PropertyConfigurator, then log4j-over-slf4j would be an insufficient replacement for log4j.
Is this what the eureka server is doing and what prevents us from using log4j-over-slf4j?
In the normal, a logging framework includes an abstraction layer and an implementation, like slf4j-api and slf4j-simple. logback is also an implementation of slf4j. When we use a logger, we use the interface in abstraction layer to do logging. It will find the implementation lib itself.
log4j-over-slf4j means we use interface in log4j, but use the slf4j implementation to do actual logging. If you use logbak as actual logging implementation, it will use log properties of slf4j, which is logbak.xml.
'The Eureka server is tied to log4j' means we use log4j interface, but spring boot add log4j-over-slf4j and logback to use slf4j logging framework.
log4j-over-slf4j module will not work when the application calls log4j components that are not present in the bridge' means you should not use the classes in the log4j implementation lib in your code. Otherwise, you can not use log4j-over-slf4j to use slf4j implementation.
I am using spring aop and have defined some aspects. Spring LTW is enabled on my tomcat.
In my application context:
<context:load-time-weaver/>
<aop:aspectj-autoproxy proxy-target-class="false"/>
Aspects are working fine too! but the target class is proxied! causing ClassCastException: can not convert $Proxy...
Note that I don't my target classes to be proxied!
If you are using AspectJ LTW you only need the tag
<context:load-time-weaver/>
in your Spring context file. So you can remove,
<aop:aspectj-autoproxy proxy-target-class="false"/>
If the target class is proxied is because LTW with AspectJ is not configured in a good way, for this reason is not AspectJ who is handling your advices, and is Spring who is doing that. For this reason you see proxy based target class.
Check this links,
http://static.springsource.org/spring/docs/3.2.2.RELEASE/spring-framework-reference/html/aop.html#aop-aj-ltw
http://static.springsource.org/spring/docs/3.2.2.RELEASE/spring-framework-reference/html/aop.html#aop-aj-ltw-environments
I've searched for an answer to my problem on google and various forums, but couldn't find a solution. I'm currently trying to modify the persistence.xml at runtime by adding a persistence unit to the file.
The solutions for this question were always "pass a Map of properties when creating an EntityManagerFactory (or EntityManager)" but i need to save the new persistence unit in the persistence.xml, because the application is going to have 100 or even more persistence unit's, one for each tenant that will register to the service, each tenant will have his own database. I'm currently using EclipseLink 2.3.3 as my JPA implementation, EJB 3.1 and jboss 7.1.1.Final as my application server.
Is it possible to modify the persistence.xml at runtime (on the fly)?
The persistence.xml is a deployed artifact, so would be difficult to modify at runtime. I think passing a properties map to createEntityManagerFactory is your best solution, what issue are you having with this?
You may also want to try using the PersistenceProvider API, createContainerEntityManagerFactory() that takes a PersistenceUnitInfo.
Also, consider using EclipseLink's multi-tenant support,
http://www.eclipse.org/eclipselink/documentation/2.5/solutions/multitenancy.htm
Why is an application redeployment is needed for JSF managed bean modifications to take effect?
Development environment:
Eclipse Indigo.
JBoss as 7.
JBossAS Tools.
Further explanation:
If I modify a JSF page, I can visualize the modification after simply refreshing the page. But this is not the case for JSF managed bean modifications where I have to redeploy the application to visualize them.
Eclipse/JBoss cannot handle new classes, methods, nor fields during hotpublish/hotdeploy. They can however handle modified method bodies and values of non-static fields with help of JVM hot-swap.
JRebel plugin is able to handle new classes, methods and fields during hotdeploy, but not new managed bean registrations.
Please note that this all is unrelated to JSF. It's related to Java development in general and thus also affects all other kinds of Java frameworks/libraries whose code you basically try to edit "live".
See also:
Changes in .xhtml file not reflected in browser, restart and build needed
I solve like this Project -> Build Automatically