Warum ich so auf das c von cdi stehe

Warum CDI oder
gibt es einen tieferen Sinn dahinter?
warum denn CDI ? ;-)

@SvenRuppert 4/122
Warum CDI oder
oft gehörte Antwort
kürzere Notation.. *oje*
Manchmal ist die Notation per Inject kürzer. Sobald allerdings die einzelnen
Qualifier dazukommen, ist meist der Aufwand zum Aufruf eines Konstruktors
kaum unterschiedlich.
Verkürzen der Notation ist natürlich nicht das Ziel von CDI

@SvenRuppert 5/122
Warum CDI oder
lösen/entfernen von statischen Abhängigkeiten

@SvenRuppert 6/122
Warum CDI oder
Dieser Punkt ist einer der wesentlichen.
Also: Wie kann man zur Entwicklungszeit die Abhängigkeiten zu den anderen
Projektmodulen möglichst gering halten?

@SvenRuppert 7/122
Warum CDI oder
Dieser Punkt ist einer der wesentlichen.
Also: Wie kann man zur Entwicklungszeit die Abhängigkeiten zu den anderen
Projektmodulen möglichst gering halten?
Gehen wir von der Definition einer Liste aus. Als Rückgabewert einer Methode
wird eine Instanz der Implementierung von List verwendet.
publicList<Data>execute(){...}; JAVA

@SvenRuppert 8/122
Warum CDI oder
Damit sind nachfolgende Aufrufer nicht mehr an die Implementierung der List
gebunden.
importjava.util.List;
importjava.util.ArrayList;
publicList<Data>execute(){
finalList<Data>result=newArrayList<>();
//....
returnresult;
}
JAVA

@SvenRuppert 9/122
Warum CDI oder
Damit sind nachfolgende Aufrufer nicht mehr an die Implementierung der List
gebunden.
In der Methode jedoch besteht meist die Abhängigkeit zu der entsprechenden
Implementierung obwohl auch das meist nicht notwendig ist.
//....
returnresult;
}
JAVA

@SvenRuppert 10/122
Warum CDI oder
Gehen wir davon aus, dass keine spezifischen Methoden der ArrayList
verwendet werden. Selten werden Methoden wie z.B. trimToSize() verwendet.

@SvenRuppert 11/122
Warum CDI oder
Somit ist die statische Abhängigkeit zu der ArrayList nicht notwendig.

@SvenRuppert 12/122
Warum CDI oder
Sollte sich zur Laufzeit herausstellen, das die Wahl dieser Implementierung nicht
optimal gewesen ist, muss der Quelltext angepasst und neu verteilt werden.

@SvenRuppert 13/122
Warum CDI oder
Sollte sich zur Laufzeit herausstellen, das die Wahl dieser Implementierung nicht
optimal gewesen ist, muss der Quelltext angepasst und neu verteilt werden.
z.B. Mit std SE Mitteln kann man das durch entsprechende Factories lösen.

@SvenRuppert 14/122
Warum CDI oder
Mit std SE Mitteln kann man das durch entsprechende Factories lösen.
Beispielhaft soll hier folgende Implementierung verwendet werden.
importjava.util.LinkedList;
publicclassListFactory{
publicListcreateArrayList() {returnnewArrayList();}
publicListcreateLinkedList(){returnnewLinkedList();}
publicListcreateList() {returnnewArrayList();}
}
JAVA

@SvenRuppert 15/122
Warum CDI oder
Haben wir damit etwas erreicht?

@SvenRuppert 16/122
Warum CDI oder
... bzw was haben wir damit erreicht?

@SvenRuppert 17/122
Warum CDI oder
z.B. Die Entwickler verwenden nun diese Factory.

@SvenRuppert 18/122
Warum CDI oder
z.B. Die Entwickler verwenden nun diese Factory. -> wenn sie wissen das es diese
gibt! ;-)

@SvenRuppert 19/122
Warum CDI oder
Vorher / Nachher (1/2)
//....
returnresult;
}
JAVA

@SvenRuppert 20/122
Warum CDI oder
Vorher / Nachher (2/2)
//....
returnresult;
}
importorg.rapidpm.demo.ListFactory;
finalListlist=newListFactory().createArrayList();
//....
returnresult;
}
JAVA

@SvenRuppert 21/122
Warum CDI oder
Bisher wurde nun die statische Abhängigkeit zur ArrayList verhindert.

@SvenRuppert 22/122
Warum CDI oder
Die Entscheidung eine ArrayList zu nehmen ist jedoch immer noch explizit
gefallen.

@SvenRuppert 23/122
Warum CDI oder
gefallen.
Die Abhängigkeit zur Factory wurde hinzugefügt.

@SvenRuppert 24/122
Warum CDI oder
gefallen.
Die Abhängigkeit zur Factory wurde hinzugefügt.
Die Implementierung der ListFactory selber hat auch wieder die statischen
Abhängigkeiten zu allen vorgesehenen Implementierungen.

@SvenRuppert 25/122
Warum CDI oder
Anforderung Nr 1: keine statischen Abhängigkeiten zu spezifischen
Implementierungen

@SvenRuppert 26/122
Warum CDI oder
Implementierungen
Anforderung Nr 2: keine statischen Entscheidungen für spezifische
Implementierungen

@SvenRuppert 27/122
Warum CDI oder
Implementierungen
Anforderung Nr 2: keine statischen Entscheidungen für spezifische
Implementierungen
Was ist jetzt eine mögliche Lösung ???

@SvenRuppert 28/122
Lösungsversuch Nr 1
basierend auf Java SE
Eine etwas dynamischere Lösung...

@SvenRuppert 29/122
importjava.util.LinkedList;
importorg.rapidpm.demo.cdi.commons.registry.ContextResolver;
publicclassListFactory{
publicListcreateList(finalContextResolvercontextResolver){
if(contextResolver==null){returncreateArrayList();}
else{
if(contextResolver.resolveContext()){returncreateArrayList();}
else{returncreateLinkedList();}
}
}
}
JAVA

@SvenRuppert 30/122
Die Komplexität der Entscheidung liegt nun im ContextResolver

@SvenRuppert 31/122
Abhängigkeit in der Factory zum ContextResolver hinzugefügt

@SvenRuppert 32/122
Abhängigkeit in der Factory zum ContextResolver hinzugefügt
Gewonnen: zur Laufzeit sich für eine Implementierung entscheiden.

@SvenRuppert 33/122
Möchte man nun die Factory so erstellen, dass diese wiederum keine statischen
Abhängigkeiten zu den jeweiligen Contexten bzw Implementierungen der Liste
hat, muss eine z.B. Registry gebaut werden.

@SvenRuppert 34/122
Dort kann man zur Laufzeit die jeweiligen Implementierungen registrieren und
für eine Auflösung zur Verfügung stellen.

@SvenRuppert 35/122
Dort kann man zur Laufzeit die jeweiligen Implementierungen registrieren und
für eine Auflösung zur Verfügung stellen.
Hier hilft CDI durch seine Konzepte, ohne das man sich mit der
Basisimplementierung der Infrastruktur beschäftigen muss.

@SvenRuppert 36/122
endlich CDI ;-)
basierend auf Weld / WELD-SE
Instanzen werden per @Inject durch den Container zur Verfügung gestellt

@SvenRuppert 37/122
endlich CDI ;-)
@InjectListlist; JAVA

@SvenRuppert 38/122
endlich CDI ;-)
@Inject@CDILegacyTestListlist; JAVA

@SvenRuppert 39/122
endlich CDI ;-)
@Inject@CDILegacyTestListlist;
@Produces@CDILegacyTest
publicListcreateList(...){...}
JAVA

@SvenRuppert 40/122
endlich CDI ;-)
publicListcreateList(InjectionPointinjectionPoint,
BeanManagerbeanManager,ContextResolvercontextResolver){
....
}
JAVA

@SvenRuppert 41/122
endlich CDI ;-)
booleanb=contextResolver.resolveContext(...); //treffenderEntscheidungen...
if(b){returnnewLinkedList();}else{returnnewArrayList();}
}
JAVA

@SvenRuppert 42/122
endlich CDI ;-)
Aber leider ist das immer noch zu dem Zeitpunkt zu dem die umliegende Instanz
erzeugt wird.
}
JAVA

@SvenRuppert 43/122
endlich CDI ;-)
Instanzen können auch erst zum Zeitpunkt der Verwendung instanziiert werden.

@SvenRuppert 44/122
endlich CDI ;-)
Damit sind späte Entscheidungen möglich

@SvenRuppert 45/122
endlich CDI ;-)
@Inject@CDILegacyTestInstance<List>listInstance; JAVA

@SvenRuppert 46/122
endlich CDI ;-)
@Inject@CDILegacyTestInstance<List>listInstance;
//..später
finalListlist=listInstance.get();
JAVA

@SvenRuppert 47/122
endlich CDI ;-)
Instanzen können auch erst zum Zeitpunkt der Verwendung instanziiert werden
damit sind späte Entscheidungen möglich
@Inject@CDILegacyTestInstance<List>listInstance;
//..später
finalListlist=listInstance.get();
}
JAVA

@SvenRuppert 48/122
CDI
was wurde bis jetzt erreicht?
Trennung der statischen Abhängigkeiten auf Klassenebene innerhalb der
Vererbung

@SvenRuppert 49/122
CDI
Vererbung
Keine "allwissende" Factory, die alle statischen Abhängigkeiten besitzt

@SvenRuppert 50/122
CDI
Vererbung
Für jede Entscheidung einen Producer

@SvenRuppert 51/122
CDI
Vererbung
Für jede Entscheidung einen Producer.. wie funktioniert das praktisch?

@SvenRuppert 52/122
CDI
Vererbung
Für jede Entscheidung einen Producer.. wie funktioniert das praktisch?
... sehen wir uns gleich noch an.... Bitte ein wenig Geduld...

@SvenRuppert 53/122
CDI
was wurde dafür in Kauf genommen?
statische Kopplung über AnnotationsLiterale:
@Inject@MyQualifierListliste; JAVA

@SvenRuppert 54/122
CDI
schlechterer Umgang mit Generics

@SvenRuppert 55/122
CDI
schlechterer Umgang mit Generics
keine Komplexitätsreduktion für den Entwickler

@SvenRuppert 56/122
CDI explained by code
HelloLogger zum aufwärmen/wiederholen
klassischer Fall, Logger im System
@Inject@CDILoggerLoggerlogger; JAVA

@SvenRuppert 57/122
@Inject@CDILoggerLoggerlogger;
@Qualifier
@Retention(value=RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD,ElementType.FIELD,ElementType.PARAMETER,ElementType.TYPE})
public@interfaceCDILogger{}
JAVA

@SvenRuppert 58/122
@Qualifier
@Produces@CDILogger
publicLoggerproduceLog4JLogger(InjectionPointiP,BeanManagerbeanManager){
finalClass<?>declaringClass=iP.getMember().getDeclaringClass();
returnnewLogger(declaringClass);
}
JAVA

@SvenRuppert 59/122
@Qualifier
@Produces@CDILogger
publicLoggerproduceLog4JLogger(InjectionPointiP,BeanManagerbeanManager){
finalClass<?>declaringClass=iP.getMember().getDeclaringClass();
returnnewLogger(declaringClass);//Loggernichtgemanaged!!!
}
JAVA

@SvenRuppert 60/122
HelloLogger zum aufwärmen / Hat uns das jetzt richtig weitergebracht?
Referenz auf Factory wird ersetzt durch Qualifier. :-(

@SvenRuppert 61/122
Spezifische Producer losgelöst von den anderen Producern

@SvenRuppert 62/122
Spezifische Producer losgelöst von den anderen Producern
zentrale Stelle für context-bezogene Entscheidungen

@SvenRuppert 63/122
Qualifier und AnnotationsLiterale

@SvenRuppert 64/122
@Producer@CDILoggerLoggercreate(...); JAVA

@SvenRuppert 65/122
@Producer@CDILoggerLoggercreate(..){
AnnotationsLiteral<T>prodAL=contextResolver.resolve(..);
};
JAVA

@SvenRuppert 66/122
@Producer@CDILoggerLoggercreate(BeanManagerbm,ContextResolvercr){
returncreator.getManagedInstance(Logger.class,annotationLiteral);
};
JAVA

@SvenRuppert 67/122
Es wird dynamisch auf ein AnnotationsLiteral aufgelöst.
};
JAVA

@SvenRuppert 68/122
Es wird dynamisch auf ein AnnotationsLiteral aufgelöst.
AnnotationsLiteral und Klasse -> Auswahl des Producers
};
JAVA

@SvenRuppert 69/122
CDI explained by code 1 / 6
ContextResolver / aus der Sicht des Entwicklers
@InjectCDIContextcontext;//z.B.einSingleton
@InjectContextResolvercr;
@Test
publicvoidtestMockedModus001()throwsException{
Assert.assertFalse(context.isMockedModusActive());
finalAnnotationLiteralannotationLiteralProd=cr.resolveContext(this.getClass());
Assert.assertEquals(newAnnotationLiteral<CDICommons>(){},annotationLiteralProd);
}
JAVA

@SvenRuppert 70/122
@Test
((TestContext)context).setTestModus(true);
Assert.assertTrue(context.isMockedModusActive());
}
JAVA

@SvenRuppert 71/122
@Test
((TestContext)context).setTestModus(true);
Assert.assertTrue(context.isMockedModusActive());
finalAnnotationLiteralannotationLiteral=cr.resolveContext(this.getClass());
Assert.assertEquals(newAnnotationLiteral<CDICommonsMocked>(){},annotationLiteral);
}
JAVA

@SvenRuppert 72/122

@SvenRuppert 73/122

@SvenRuppert 74/122
CDI explained by code 2a / 6
ContextResolver
Die Annotation mit @CDINotMapped, um das Interface explizit in den
Namensraum zu setzen
@CDINotMapped
publicinterfaceCDIContext{
publicbooleanisMockedModusActive();
}
JAVA

@SvenRuppert 75/122
CDI explained by code 2b / 6
ContextResolver
Mit klassischen Interzeptoren kann man Querschnittsthemen deklarieren.
Nur allgemein umschalten auf Mocked/NotMocked möglich?
@InterceptorBinding
@Target({ElementType.TYPE,ElementType.METHOD})
@Inherited
public@interfaceCheckMockedContext{}
publicinterfaceContextResolver{
@CheckMockedContext
publicAnnotationLiteralresolveContext(finalClass<?>targetClass);
}
JAVA

@SvenRuppert 76/122
ContextResolver
@Interceptor@CheckMockedContext
publicclassMockedInterceptorimplementsSerializable{
@InjectCDIContextcontext;
private@Inject@CDILoggerLoggerlogger;
@AroundInvoke
publicObjectcheckMockedMode(InvocationContextctx)throwsException{
if(context.isMockedModusActive()){
if(logger.isDebugEnabled()){logger.debug("MockedModusactive");}
returnnewAnnotationLiteral<CDICommonsMocked>(){};
}else{
returnctx.proceed();
}
}
}
JAVA

@SvenRuppert 77/122
ContextResolver
Durch Interzeptoren meist nur allgemeine Umschaltlogik darstellbar

@SvenRuppert 78/122
ContextResolver
Benötigt wird aber evtl differenziertes Umschalten.

@SvenRuppert 79/122
ContextResolver
Benötigt wird aber evtl differenziertes Umschalten.
Interzeptoren werden statisch definiert - schade....

@SvenRuppert 80/122
ContextResolver
@CDICommons
public class DefaultContextResolver implements ContextResolver {
@Inject @CDILogger Logger logger; @Inject BeanManager beanManager;
public Set<ContextResolver> gettAllContextResolver() {
final Set<ContextResolver> resultSet = new HashSet<>();
final Set<Bean<?>> allBeans = beanManager
.getBeans(ContextResolver.class, new AnnotationLiteral<Any>() {});
allBeans.forEach(b-> b.getTypes().stream()
.filter(t -> t.equals(ContextResolver.class))
.filter(r -> !r.getClass().isAnnotationPresent(CDICommonsMocked.class))
.forEach(t -> {
final ContextResolver cr = ((Bean<ContextResolver>) b)
.create(beanManager.createCreationalContext((Bean<ContextResolver>) b));
resultSet.add(cr);
}));
return resultSet;
}
JAVA

@SvenRuppert 81/122
ContextResolver
publicSet<ContextResolver>gettAllMockedContextResolver(){
finalSet<ContextResolver>resultSet=newHashSet<>();
finalSet<Bean<?>>allBeans=beanManager
.getBeans(ContextResolver.class,newAnnotationLiteral<CDICommonsMocked>(){});
allBeans.forEach(b->b.getTypes().forEach(type->{
if(type.equals(ContextResolver.class)){
finalContextResolvert=((Bean<ContextResolver>)b)
.create(beanManager.createCreationalContext((Bean<ContextResolver>)b));
resultSet.add(t);
}
}));
returnresultSet;
}
JAVA

@SvenRuppert 82/122
CDI explained by code 4c / 6
ContextResolver
publicAnnotationLiteralresolveContext(ClasstargetClass){
Stream<ContextResolver>contextResolversMocked=gettAllMockedContextResolver().stream();
Stream<ContextResolver>contextResolvers=gettAllContextResolver().stream();
returncontextResolversMocked
.filter(r->(r.resolveContext(targetClass)!=null))
.map(r->r.resolveContext(targetClass))
.findFirst().orElse(
contextResolvers
.filter(r->!r.getClass().isAnnotationPresent(CDICommonsMocked.class))
.filter(r->!r.getClass().equals(DefaultContextResolver.class))
.filter(r->(r.resolveContext(targetClass)!=null))
.map(r->r.resolveContext(targetClass))
.findFirst().orElse(null)
);
}
JAVA

@SvenRuppert 83/122
ContextResolver
@Singleton
publicclassTestContextimplementsCDIContext{
privatebooleantestModus=false;
@OverridepublicbooleanisMockedModusActive(){returntestModus;}
publicbooleanisTestModus(){returntestModus;}
publicvoidsetTestModus(booleantestModus){this.testModus=testModus;}
}
publicclassTestContextResolverimplementsContextResolver{
@InjectCDIContextcontext;
@CheckMockedContext
@OverridepublicAnnotationLiteralresolveContext(Class<?>targetClass){
//entscheideobDuzuständigbist
returnnewAnnotationLiteral<CDICommons>(){};
}
}
JAVA

@SvenRuppert 84/122
ContextResolver
Wir sind nun in der Lage dynamisch auf den Systemzustand zu reagieren.

@SvenRuppert 85/122
ContextResolver
ContextResolver sind immer nur in ihrem fachlichen Bereich aktiv

@SvenRuppert 86/122
ContextResolver
ContextResolver sind immer nur in ihrem fachlichen Bereich aktiv
Unterscheidung auf z.B. Mandantenebene leicht realisierbar

@SvenRuppert 87/122
CDI managed DynamicObjectAdapter - besserer Decorator
klassischer Decorator in CDI
@Decorator
publicabstractclassCoderDecoratorimplementsCoder{
@Inject@Delegate@AnyCodercoder;
publicStringcodeString(Strings,inttval){
intlen=s.length();
return"""+s+""becomes"+"""+coder.codeString(s,tval)
+"","+len+"charactersinlength";
}
}
Insidebeans.xml
<decorators>
<class>decorators.CoderDecorator</class>
</decorators>
JAVA

@SvenRuppert 88/122
CDI managed DynamicObjectAdapter - der bessere Decorator
Ein Decorator in CDI muss in der beans.xml definiert werden.

@SvenRuppert 89/122
Klasse mit einer speziellen Annotation @Decorator

@SvenRuppert 90/122
Innerhalb des Decorators muss die Instanz des Originals injiziert werden

@SvenRuppert 91/122
Decorator muss von der Original-Implementierung oder dem Interface ableiten

@SvenRuppert 92/122
Decorator muss von der Original-Implementierung oder dem Interface ableiten
... geht das auch schöner ?

@SvenRuppert 93/122
Aus der Sicht des Entwicklers
@CDINotMapped
publicinterfaceDemoLogic{
publicdefaultintadd(inta,intb){ returna+b;}
publicdefaultintsub(inta,intb){ returna-b;}
}
@CDINotMapped
publicclassDemoLogicAdapter_AimplementsDemoLogic{
publicintadd(inta,intb){
returna+b+100;
}
}
@Singleton //sollteschonbekanntsein;-)
publicclassContext{publicbooleanoriginal=true;}
JAVA

@SvenRuppert 94/122
Injizieren der Referenz auf DemoLogic

@SvenRuppert 95/122
Holen einer Instanz der DemoLogic

@SvenRuppert 96/122
Aufruf der Methode add(1,1)

@SvenRuppert 97/122
Überprüfung ob das Ergebnis den Erwartungen entspricht, hier der Wert 2.

@SvenRuppert 98/122
Context-Switch auf mandantenabhängige Implementierung

@SvenRuppert 99/122

@SvenRuppert 100/122

Kaffee trinken.

@Inject@DynamicDecoratorTestInstance<DemoLogic>demoLogic;
@InjectContextcontext;
@Test
publicvoidtestDemoLogicOriginalTest()throwsException{
Assert.assertNotNull(demoLogic);
finalDemoLogicdemoLogic1=demoLogic.get();
finalintadd=demoLogic1.add(1,1);
Assert.assertEquals(2,add);
System.out.println("add="+add);
context.original=false;
finalDemoLogicdemoLogic2=demoLogic.get();
finalintaddAdapted=demoLogic2.add(1,1);
Assert.assertEquals(102,addAdapted);
System.out.println("addAdapted="+addAdapted);
}
JAVA

CDI explained by code 4c / 7
manuelles aktivieren von CDI.. yepp das geht
public<T>TactivateCDI(Tt){
finalClassaClass=t.getClass();
if(logger.isDebugEnabled()){logger.debug("activateCDI->"+aClass);}
AnnotatedTypeannotationType=beanManager.createAnnotatedType(aClass);
InjectionTargetinjectionTarget=beanManager.createInjectionTarget(annotationType);
CreationalContextcreationalContext=beanManager.createCreationalContext(null);
injectionTarget.inject(t,creationalContext);
injectionTarget.postConstruct(t);
returnt;
}
JAVA

public class DemoLogicProducer {
@Inject Instance<DynamicObjectAdapterFactory> dOAFInstance;
@Inject Context context;
@Produces @DynamicDecoratorTest
public DemoLogic create(ManagedInstanceCreator instanceCreator){
final DemoLogic demoLogic = instanceCreator.activateCDI(new DemoLogic() {});
final DynamicObjectAdapterFactory dynamicObjectAdapterFactory = dOAFInstance.get();
final Object adapter;
if (context.original){ adapter = new Object(); }
else { //kann hier beliebig komplex werden
adapter = instanceCreator.activateCDI(new DemoLogicAdapter_A());
}
//hier interface notwendig... see insight
return dynamicObjectAdapterFactory.adapt(demoLogic, DemoLogic.class, adapter);
}
JAVA

publicclassDynamicObjectAdapterFactory{
@InjectInstance<CDIInvocationHandler>cdiInvocationHandlerInstance;
public<T>Tadapt(finalObjectadaptee,finalClass<T>target,finalObjectadapter){
finalCDIInvocationHandlerinvocationHandler=
cdiInvocationHandlerInstance.get().adapter(adapter).adaptee(adaptee);
return(T)Proxy.newProxyInstance(
target.getClassLoader(),
newClass[]{target}, //hierInterfacenotwendig!
invocationHandler
);
}
}
JAVA

CDI explained by code 7a / 7c
publicclassMethodIdentifier{
privatefinalStringname;
privatefinalClass[]parameters;
publicMethodIdentifier(Methodm){
name=m.getName();parameters=m.getParameterTypes();
}
//wecansavetimebyassumingthatweonlycompareagainst
//otherMethodIdentifierobjects
publicbooleanequals(Objecto){
MethodIdentifiermid=(MethodIdentifier)o;
returnname.equals(mid.name)&&Arrays.equals(parameters,mid.parameters);
}
publicinthashCode(){ returnname.hashCode();}
}
JAVA

CDI explained by code 7b / 7c
publicclassCDIInvocationHandlerimplementsInvocationHandler{
privateMap<MethodIdentifier,Method>adaptedMethods=newHashMap<>();
privateObjectadapter;privateObjectadaptee;
publicObjectinvoke(Objectproxy,Methodmethod,Object[]args)throwsThrowable{
if(adaptedMethods.isEmpty()){
Method[]methods=adapter.getClass().getDeclaredMethods();
for(Methodm:methods){ adaptedMethods.put(newMethodIdentifier(m),m);}
}
try{
Methodother=adaptedMethods.get(newMethodIdentifier(method));
if(other!=null) {returnother.invoke(adapter,args);}
else {returnmethod.invoke(adaptee,args); }
}catch(InvocationTargetExceptione){throwe.getTargetException();}
}...
JAVA

CDI explained by code 7c / 7c
Mit diesem Pattern sind wir in der Lage die Unzulänglichkeiten des CDI
Decorators auszugleichen.

Spätere Änderungen an dem Interface führen nicht dazu, dass alle Adapter
angepasst werden müssen

Spätere Änderungen an dem Interface führen nicht dazu, dass alle Adapter
angepasst werden müssen
Alle Komponenten sind von dem verwendeten CDI-Container verwaltet

Cross Language Injection
.. am Beispiel von Kotlin..
classDemoLogicKotlin(){
publicfunworkOnString():String{
return"DemoLogicKotlin"
}
}
JAVA

entweder : Adapter mit Delegator
@CDINotMapped
publicclassDemoLogicKotlinWrapperimplementsDemoLogic{
private@InjectDemoLogicKotlinkotlin;
publicStringworkOnString(){
returnkotlin.workOnString();
}
}
JAVA

oder mittels Producer direkt verfügbar machen
@CDINotMapped
publicclassDemoLogicKotlinProducer{
@InjectManagedInstanceCreatorcreator;
//@InjectDemoLogicKotlinkotlin;
@Produces@KotlinImpl
publicDemoLogiccreate(){
finalDemoLogiclogic=newDemoLogicKotlinWrapper();
returncreator.activateCDI(logic);
}
}
JAVA

CDI und TDD
... kaskadierte MOCKS
Service A injected Service B injected Service C

CDI und TDD
Service A (mocked) injected Service B injected Service C

CDI und TDD
Service A injected Service B (mocked) injected Service C

CDI und TDD
Service A (mocked) injected Service B (mocked) injected Service C

CDI und TDD
Service A (mocked) injected Service B (mocked) injected Service C
beliebige Kombinationen können so dynamisch zusammen geschaltet werden.

finally at amazon..
my book with Dr, Heinz Kabutz
Book about Reflection - part one
Dynamic Proxies z.B. ...dynamic static proxies... ;-)

<Thank You!>
g+ www.google.com/+SvenRuppert
twitter @SvenRuppert
www www.rapidpm.org

www www.rapidpm.org
github github.com/svenruppert

Warum ich so auf das c von cdi stehe

Recommandé

Recommandé

Contenu connexe

Similaire à Warum ich so auf das c von cdi stehe

Similaire à Warum ich so auf das c von cdi stehe (20)

Plus de Sven Ruppert

Plus de Sven Ruppert (16)

Warum ich so auf das c von cdi stehe