I am trying to integrate the Activiti-BPM Framework into a Java EE Webapplication.
The main goal at the Moment is, to inject an EJB as DelegateExpression into a Servicetask (to handle Database operations).
I read that Activiti does not (yet) work with EJBs, so i annotated the class like this:
#Named
#LocalBean
#Stateless
#Dependent
public class DatabaseWriter implements JavaDelegate {...}
and try to inject it in multiple ways like this:
activiti:delegateExpression="${DatabaseWriter}"
activiti:delegateExpression="DatabaseWriter"
activiti:delegateExpression="$DatabaseWriter"
respectivley to check if it is just a Bug or something:
activiti:expression="${DatabaseWriter.execute(execution)}"
In any case i get exceptions like "could not resolve DatabaseWriter, no bean foudn that implements JavaDelegate with name DatabseWriter ..."
I tested the Class itself - by not using cdi - JPA does nto work, but the class can be instantiated by Activiti and the execute method is executed - so the class code itself is ok.
I also tried injecting the class in a JAX-RS EJB - both with CDI and #EJB - it works. The problem definetly lies with my way of trying to bring it into Activiti.
I also made a Screenshot of the Problem (all code, xml, and a logmessage) for better understanding, if it helps:
http://s29.postimg.org/tmiknudjb/problem.jpg
Thanks for help or tipps!
Regards,
BillDoor
From the Oracle documentation
Annotating the boundary (Cart) with the #Named annotation makes the
Cart immediately visible for expression language (EL) expressions in
JSP and JSF. This #Named annotation takes the simple name of the
annotated class, puts the first character in lowercase, and exposes it
directly to the JSF pages (or JSP).
Activiti uses same expression language(EL) so my guess is to you try with;
activiti:delegateExpression="${databaseWriter}"
Also, I nevered use EJB and Activiti so I'm just guessing, but upper example is how it works with Spring.
Hope it helps.
Related
We have an application that uses javax.enterprise.inject.Instance to find all validators for a service. This seems to work nicely but during testing we would like to swap out a few of those validators with a mock to skip their behaviour so it's easier to reach other validators.
When we try to do this using the 'Old approach' (See Blog-post on this) we notice only the classes with #Mock are injected, not any of the normal ones.
When trying it the 'New approach' we get a javax.enterprise.inject.AmbiguousResolutionException that tells us TypeBValidator is found twice.
This is the setup of a trimmed-down version of our app showing the behaviour:
Validator-interface
TypeAValidator (#ApplicationScoped)
TypeBValidator (#ApplicationScoped)
REST-Service-class that has a #Inject like this: Instance<Validator> validators via the constructor.
In test-scope we have:
TypeBMockValidator (which does have #Mock in old and no #Mock in the new approach)
Test class for REST-Service that is annotated with #QuarkusTest. This test-class calls the REST-service using restassured, right as it's provided when one generates an example project.
See the example project for all details.
I'm looking for a stable and predictable way to replace only the TypeBValidator during my tests. Any help would be highly appreciated.
Turns out that this was not a bug, but the expected behavior of CDI when multiple there is a class hierarchy where multiple classes are beans.
In this case, the simplest solution is to annotate TypeBValidator with #DefaultBean.
See https://github.com/quarkusio/quarkus/issues/19773#issuecomment-909974623 for more details
i Have a job which needs both a dao and 1 factory class
something like this
https://pastebin.com/kK7VcbW1
My question is how to inject them , i get this exception when the code reaches the dao calling getSomething in the Factory class
In the abstractDao i #Inject entityManager which i get from an #ApplicationScoped EnttityManagerProducer its getEntityManager is #RequestScoped
org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:691)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:164)
at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
at org.jboss.weldx.persistence.EntityManager$1070085530$Proxy$_$$_WeldClientProxy.createQuery(Unknown Source)
at com.org.dao.impl.ConcreteDAOImpl.getByName(ConcreteDAOImpl.java:18)
at com.org.dao.impl.ConcreteDAOImp$Proxy$_$$_WeldClientProxy.getByName(Unknown Source)
at com.org.FactoryImpl.getObj(FactoryImpl.java:33)
(the real classes i replaced for the sake of the example)
I tried putting the annotations on both class and interface level i dont know which is preferrable
This type of functionality is built in out of the box with Apache Deltaspike, you can read about the scheduler module. The problem as you're aluding to is that by default, contexts are not started automatically when outside of Java EE. To do that, you need to manually start one. In CDI 2.0 this can be done by adding #ActivateRequestContext to a method/class and a request scope will be started for the duration of that method.
Prior to CDI 2.0, its platform specific. DeltaSpike solves the issue much cleaner.
We're building a framework on top of Spring & Spring MVC. Our framework is quite mature at this point - about 2 years old and is used widely within our organization. Our framework is very modular (much like spring itself is). There are various modules that can be used independently or together. When used together they provide many benefits to the end user. We have built a handful custom spring XML namespaces (NamespaceHandlers, BeanDefinitionParsers, etc). Each module provides their own which brings in its own set of XML configuration elements. This is all working great for us and has been a really big win for us.
What we'd like to do now is move away from XML-based configuration and into java config. My idea/thought is for each module to introduce a set of java config annotations that can be used (something similar to the #EnableCaching, #EnableMBeanExport annotations). My question is this - even if I create my annotations - how do I "wire" them in so that if they are present I can do "stuff"? This would be similar conceptually to the NamespaceHandlers & BeanDefinitionParsers. I can't find any documentation anywhere as to how to get started.
I've thought about creating some custom abstract base classes which do what I need them to do - but the problem is when it comes to the end user's application - they can only extend a single class. I need a flexible way for each module in my framework to expose its own custom configuration that end user applications can use, just like they use our XML namespace elements.
Here's a glimpse as to what we do in XML (not full application context file - just a blurb from it pertaining to our custom XML namespaces):
<atom-web:web/>
<atom-web:logging/>
<atom-web:security entitlementsProvider="XML" xmlRefreshInterval="${cache.refresh.interval.ms}"/>
<atom-profile:profile caching="IN_MEMORY" entryExpiryDelay="${cache.refresh.interval.ms}"/>
<atom-prefs:preferences backingStoreUrl="${pref.backingStore.url}"/>
<atom-content:content contentServerBaseUrl="${content.server.url}" contentServerFileUrl="${content.server.file.url}" site="${site.name}" contentTaskExecutor="contentTaskExecutor" snippetCaching="IN_MEMORY" cacheRefreshInterval="${cache.refresh.interval.ms}"/>
<bean id="contentTaskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor" p:corePoolSize="3" p:maxPoolSize="20"/>
What I'm envisioning is some kind of set of annotations - something like this:
#EnableAtomWebApplication
#EnableAtomWebLogging
#EnableAtomWebSecurity(entitlementsProvider=EntitlementsProvider.XML, xmlRefreshDelay=120000)
#EnableAtomProfile(caching=CachingType.IN_MEMORY, expiryDelay=120000)
// Other annotations for rest of modules
#Configuration
public class ConfigurationClass {
// Rest of configuration in here
}
Any help here would be greatly appreciated. I'm not quite sure where to start and can't really find any documentation anywhere to help me get started.
So after thinking about this a bit I think I've found the correct starting point. I wanted to throw this out there for anyone who might be able to say "yeah thats the right place" or "no you aren't looking in the correct place".
Using my example above
#EnableAtomProfile(caching=CachingType.IN_MEMORY, expiryDelay=120000)
I would create an annotation for the #EnableAtomProfile annotation like this:
#Retention(value=java.lang.annotation.RetentionPolicy.RUNTIME)
#Target(value={java.lang.annotation.ElementType.TYPE})
#Documented
#Import({AtomProfileBeanDefinitionRegistrar.class})
public #interface EnableAtomProfile {
CachingType caching() default CachingType.NONE;
long expiryDelay default 0;
}
The AtomProfileBeanDefinitionRegistrar class would implement org.springframework.context.annotation.ImportBeanDefinitionRegistrar and do any of the necessary stuff that I'm currently doing in my BeanDefinitionParser
You can have a BeanPostProcessor defined, which would basically:
inspect every single bean created
with reflection check if the object's class is annotated with #YourAnnotation
and if it is, then apply some custom logic - e.g. package the object into some other class or something
Reference:
Spring docs on BeanPostProcessors
source code for RequiredAnnotationBeanPostProcessor, which is a BeanPostProcessor which analyzes annotations
I have a bunch of dependencies written as fast binary web services (aka Ejb3.1). Here is the service delcaration:
#Remote
public interface MyService {...}
You would inject an EJB into a servlet or managed bean with the following syntax:
#EJB
MyService myService;
I don't want to use the #EJB injection however. I'd like to use plain vanilla CDI:
#Inject
MyService myService;
One way to accomplish this would be to Create a #Produces method for every EJB:
#Produces MyService produceMyService(InjectionPoint ijp){
//jndi lookup for MyService interface
}
However, InjectionPoint is capable of giving you all the information you need, such as the target class name (MyService in this case).
Is there a way in CDI to do something like this? I'd want to call this producer last, if the required injection point couldn't be fulfilled in any other manner.
#Produces Object produce(InjectionPoint ijp){
Class ejbInterface = ijp.getType();
//jndi lookup for ejbInterface
}
This is a confusing post, so ask clarification questions. Thanks a ton!
Assuming that I understood your question (see comment): No, there is no API for this.
Good news is that there is a way to achieve this - but you probably don't want to do this at runtime, that's rather a task for application startup.
The CDI extension mechanism offers you some well defined hooks into bean processing at container startup. This is a perfect place for logic that decides about enabling / disabling of certain managed beans (probably based on static classpath information).
Have a look at function and implementation of Seam Solder's #Requires. That should be pretty close to your use case...
I created a custom sterotype #Action, and Spring has managed to detect it in the package scan I configured in the configurations.
The next step I would like to do is to tell Spring that all classes with #Action should be created with prototype, instead of Singleton.
My #Action interface is as follows:
#Target({ElementType.TYPE})
#Retention(RetentionPolicy.RUNTIME)
#Documented
#Component
public #interface Action {
}
I tried to mark it with #Scope("prototype") but that does not seem to help.
Is what I desire possible?
Kent
The context:component-scan can be configured with a custom scope-resolver, which implements org.springframework.context.annotation.ScopeMetadataResolver.
I created a custom scope-resolver that not only checks the bean for a #Scope annotation (with the default resolver of org.springframework.context.annotation.AnnotationScopeMetadataResolver), but looks up annotations of annotations too (recursively).
One thing to note though, that looking up annotations recursively might go into an endless loop, as java.lang.annotation.Documented is annotated with java.lang.annotation.Documented. Best to maintain a table that indicates which annotation has been looked up already.
Unfortunately not with spring 2.5.X. Your #Component-annotation describes the role of the bean while the scope is a separate axis, so a role and scope descriptor typically have to be applied separately to the implementation class. When viewed in this way it makes some sense (edit: at least it did so for a few seconds, anyway)
I don't know how this will change i spring 3.x, which is not too far away. There seems to be some room for improvement.