Bean-Testing von Java EE-Anwendungen mit CDI
|
|
- Josef Adenauer
- vor 2 Jahren
- Abrufe
Transkript
1 Bohne und Malz Bean-Testing von Java EE-Anwendungen mit CDI Carlos Barragan, Gerhard Wanner, Dieter Baier Unit-Tests sind der Kern jeder Strategie, qualitativ hochwertige Software herzustellen. Softwaresysteme ohne ausreichende Abdeckung an Unit-Tests degenerieren bei fachlichen oder technischen Änderungen schnell und werden, eher früher als später, unwartbar. Im Umfeld von Java EE erschwert allerdings die Notwendigkeit einer Ablaufumgebung das Unit-Testing. Es gibt zwar verschiedene Ansätze für dieses Problem, aber entweder sind diese aufwendiger als gewohnt oder die Ausführungsdauer der Tests verhindert die übliche Feedback-Geschwindigkeit. Bean-Testing ist ein schnelles und schlankes Testverfahren für Java EE- Anwendungen unter Einsatz von CDI. Im Gegensatz zu Unit-Tests, bei denen die Test-Einheiten üblicherweise einzelne Methoden sind, werden ganze Beans inklusive ihrer Abhängigkeiten getestet. Bean-Tests für Java EE-Anwendungen Ausgangspunkt des vorgestellten Verfahrens war die Entwicklung einer Java EE-Anwendung für Bewerbungspro- E zesse. Im Rahmen dieses Projektes wurde nach Möglichkeiten gesucht, Unit-Tests zu erstellen und durchzuführen. Aus dem Projekt heraus wurden dazu folgende Anforderungen an das Unit-Testing dieser Java EE-Anwendung gestellt: H Das Feedback soll schnell sein, ähnlich zu dem eines normalen JUnit-Tests. H Abhängigkeiten sollten automatisch injiziert werden, so als ob die Anwendung auf dem Applikationsserver laufen würde. Dabei soll das Mocken der Abhängigkeiten nicht notwendig sein. Das erste betrachtete Werkzeug für die Umsetzung der genannten Anforderungen war Arquillian [Arquillian] von JBoss. Eigentlich ist Arquillian eher ein Tool für Integrationstests und weniger fürs Unit-Testing. Grund hierfür ist, dass Arquillian die Anwendung tatsächlich auf einen Applikationsserver deployt, mit dem Vorteil, dass es sich dabei um den ganzen Deployment- Ablauf kümmert. Auf Arquillian basierende Tests ermöglichen es, eine Anwendung ohne größeren Aufwand innerhalb eines Containers zu testen. Allerdings ist dieses Verfahren für Unit- Tests weniger gut geeignet, da wegen des Deployments die erforderliche Feedback-Geschwindigkeit nicht erreicht wird. Eine zweite betrachtete Möglichkeit war der Einsatz des Frameworks Mockito [Mockito]. Mockito wurde in oben genanntem Projekt bereits für den Test der Geschäftslogik eingesetzt. Durch Mockito können die Services gemockt werden, die der Container normalerweise mittels Dependency Injection (DI) zur Verfügung stellt. Je nachdem, was getestet werden soll, fallen bei der Erstellung dieser Mocks in Mockito Aufwände an. Deren Umfang ist zwar nicht allzu groß, jedoch muss beim Einsatz von Mockito klar sein, welche Services gemockt werden sollen und welche nicht. Zudem sinkt zwangsläufig die Testqualität, da das Mocken eines Service eine neue Fehlerquelle darstellt. Für unsere Unit-Tests stellte sich die Frage, wie vorgegangen wird, wenn auch solche gemockten Services getestet werden sollen? Letztendlich besteht ein großer Teil der Geschäftslogik aus der Zusammenarbeit mehrerer solcher Services. CDI Contexts and Dependency Injection CDI ist eine Ende 2009 als JSR 299 [JSR299] veröffentlichte Spezifikation des Java EE-Stacks. Ganz aktuell erschien CDI 1.1 [JSR346] als Teil von Java EE 7. Es gibt mehrere CDI-Implementierungen mit Weld [WeldHome] als Referenzimplementierung. Andere Implementierungen von CDI sind CanDI [Can- DI] und OpenWebBeans [OWB]. Weld ist ein Framework für DI, welches ursprünglich für das Projekt JBoss Seam entwickelt wurde. Aus diesem Framework heraus entstand die CDI-Spezifikation. Eine erweiterte Version von Weld, Weld SE, kann auch außerhalb eines Containers verwendet werden, sodass sich CDI auch bei einer normalen Java SE-Anwendung einsetzen lässt. Bis auf ganz wenige Ausnahmen behält CDI seine volle Funktionalität auch außerhalb des Containers bei, das heißt, nahezu alle Features funktionieren as advertised. Die Dokumentation von Weld schreibt dazu Folgendes: Zusätzlich zur verbesserten Integration des Java EE-Stacks definiert die CDI-Spezifikation ein Framework für typsicheres und zustandsbehaftetes DI, welches einen großen Bereich an Anwendungsarten abdeckt. Weld stellt mit einfachen Mitteln sicher, dass CDI auch unter Java SE ausgeführt werden kann und unabhängig von irgendwelchen Java EE-APIs ist (angelehnt an [Weld]). Dies bedeutet, dass Weld SE bis auf wenige Ausnahmen, beispielweise asynchrone Events, alle CDI-Features unterstützt. CDI als Tool für Bean-Tests Warum ist nun gerade CDI für das Bean-Testing sehr gut geeignet? Am besten zeigt das der Vergleich mit den bereits genannten anderen Möglichkeiten. Im Gegensatz zu Arquillian ist die Ablaufgeschwindigkeit von Tests mit CDI deutlich schneller. Die Tests werden in Millisekunden durchgeführt, denn es muss kein Applikationsserver gestartet werden. Sogar ein Embedded Applikationsserver braucht länger zum Starten als die CDI-Umgebung. Auf Details dazu wird später noch eingegangen. Anders als Mockito werden bei CDI keine Abhängigkeiten gemockt, sondern sie werden von CDI injiziert. Somit kann der Entwickler die EJBs unverändert testen, lediglich eine geringfügige Anpassung der Konfiguration kann notwendig sein. Dadurch wird die Zeit für die Erstellung der Mocks eingespart und mit den Bean-Tests werden die tatsächlichen Abhängigkeiten und der Quellcode getestet. Bei CDI gibt es einen einmaligen Aufwand, um die Umgebung zur Verfügung zu stellen. Wenn die Umgebung vorhanden ist, können die EJBs direkt ohne Mocking getestet werden. Schnelles Feedback JUnit Mockito CDI Bean Testing Unit Testing Großer Umfang Geringer Umfang Integration Testing Arquillian Abb. 1: CDI-Bean-Test im Vergleich zu Unit- und Integrationstest Langsames Feedback 39
2 Abbildung 1 stellt die Bean-Tests den Unit-Tests mit Mockito und den Integrationstests mit Arquillian gegenüber. CDI- Bean-Tests ermöglichen sowohl einen großen Umfang (Test der Abhängigkeiten) als auch ein schnelles Feedback (Tests werden mit ähnlicher Geschwindigkeit wie Unit-Tests durchgeführt). Als weiterer Vorteil kommt hinzu, dass Tests wesentlich schneller zu erstellen sind, da Abhängigkeiten nicht gemockt werden müssen. Beispiel Das Beispiel greift ein typisches Java EE-Szenario auf: EJBs referenzieren andere EJBs und Entitäten werden mittels des EntityManagers persistiert. Das Beispiel besteht aus zwei EJBs: My- EJBService und MyOtherEJBService. MyEJBService referenziert MyOther- EJBService. Beide EJBs greifen auf den EntityManager zu, um Entitäten zu persistieren bzw. zu lesen (s. Abb. 2). Die Referenzen werden zur Laufzeit im Container aufgelöst. Darüber hinaus übernimmt der Container das Transaktionshandling und die Erstellung des EntityManagers. Das Beispiel zeigt, wie CDI eingesetzt werden kann, um eine typische Java EE-Anwendung inklusive ihrer tatsächlichen Abhängigkeiten zu testen. Außerdem wird vorgestellt, wie Services, beispielsweise Transaktionen, die normalerweise vom Container zur Verfügung gestellt werden, auch durch CDI angeboten werden können. <dependencies> <groupid>org.jboss.weld.se</groupid> <artifactid>weld-se</artifactid> <version>2.0.1.final</version> <type>jar</type> <scope>provided</scope> <groupid>org.apache.geronimo.specs</groupid> <artifactid>geronimo-ejb_3.1_spec</artifactid> <version>1.0</version> <scope>provided</scope> <groupid>org.apache.deltaspike.core</groupid> <artifactid>deltaspike-core-impl</artifactid> <version>0.4</version> <scope>test</scope> <groupid>org.apache.deltaspike.cdictrl</groupid> <artifactid>deltaspike-cdictrl-weld</artifactid> <version>0.4</version> <scope>test</scope> </dependencies> Listing 1: Definition der Abhängigkeit in Maven Ganz wichtig dazu ist der Eintrag des JBoss-Repositories in pom.xml, da Weld SE im Maven Central Repository nicht vorhanden ist (Listing 2). MyEJBService EntityManager MyOtherEJBService <repositories> <repository> <id>jboss</id> <name>jboss repository</name> <url>https://repository.jboss.org/nexus/content/groups/public/</url> </repository> </repositories> Listing 2: Erweiterung pom.xml für die Nutzung von Weld SE Abb. 2: Abhängigkeiten der EJBs und Entities im Beispiel Setup der Umgebung Die nachfolgenden Schritte zeigen das Setup der Umgebung. Sie sind nur einmalig durchzuführen und beinhalten die Einrichtung von Maven sowie die Nutzung einer Hilfsklasse zur einfachen Nutzung von Weld. Maven einrichten Für das Beispiel müssen die Abhängigkeiten zu Weld (enthält die Implementierung von CDI) und zum EJB 3.1-API (enthält die CDI- und EJB-Annotationen sowie den BeanManager) definiert werden (Listing 1). Für die zur Laufzeit benötigte Java EE-Implementierung nutzen wir Geronimo [Bien10]. Selbstverständlich würden an dieser Stelle auch die entsprechenden Bibliotheken von beispielsweise JBoss oder Glassfish funktionieren Eine weitere Abhängigkeit definieren wir zu Apache Delta- Spike [DeltaSpike]. Diese Sammlung portabler CDI-Extensions und -Utilities wird später zur Initialisierung des CDI- Containers und zur Modifikation des Metamodells der Beans verwendet. Hilfsklasse für die Weld-Nutzung Die Klasse BeanManagerHelper übernimmt die Initialisierung des Weld-Containers und bietet Methoden zur Erstellung von managed Instanzen an (Listing 3). Die Erstellung von Tests vereinfacht sich dadurch, weil der BeanManagerHelper sich um die Erstellung der Instanzen kümmert. import java.lang.annotation.annotation; import javax.enterprise.inject.spi.beanmanager; import org.apache.deltaspike.cdise.api.cdicontainer; import org.apache.deltaspike.cdise.api.cdicontainerloader; import org.apache.deltaspike.core.api.provider.beanprovider; public class BeanManagerHelper { private CdiContainercdiContainer; public BeanManagerHelper() { cdicontainer = CdiContainerLoader.getCdiContainer(); cdicontainer.boot(); cdicontainer.getcontextcontrol().startcontexts(); public<t> T createinstance(class<t>clazz) { returnbeanprovider.getcontextualreference(clazz); public<t> T createinstance(class<t>clazz, Annotation... annotations) { returnbeanprovider.getcontextualreference(clazz, annotations); public BeanManager getbeanmanager() { returncdicontainer.getbeanmanager(); 5 40 JavaSPEKTRUM 5/2013
3 public void shutdown() { cdicontainer.shutdown(); Listing 3: Vereinfachte Erstellung von managed Instanzen mit dem BeanManagerHelper System.out.println("MyOtherEJBService did something"); public Collection<MyEntity> getallentities() { return em.createquery("select E from MyEntity as E", MyEntity.class).getResultList(); Listing 5: Der zweite Service des Beispiels: MyOtherEJBService Listing 3 zeigt, wie der CDI-Container mit Hilfe der Utility- Klasse CdiContainerLoader aus dem DeltaSpike-Framework im Konstruktor der Klasse initialisiert bzw. in der Methode shutdown() ausgeschaltet wird. Mit Hilfe dieser Utility-Klasse werden auch alle Kontexte (Application-, Request-Kontext usw.) gestartet. Nach dieser Initialisierung können die managed Instanzen in den createinstance-methoden mit Hilfe der Utility-Klasse BeanProvider aus dem DeltaSpike-Framework erstellt werden. Die Beispielanwendung Wir bereits erwähnt, besteht das Beispiel aus zwei EJBs (Listing 4, Listing 5). Die EJBs sind stateless und greifen auf den Entity- Manager zu. MyEJBService hat eine Referenz auf MyOtherEJBService, deren Referenz zusammen mit dem EntityManager zur Laufzeit vom Container aufgelöst werden soll. In der Methode MyEJBService. dosomethingwiththeotherservice() wird die Methode MyOtherEJBService.doSomething() aufgerufen. Durch diesen Aufruf wird demonstriert, dass die Referenz von CDI zur Verfügung gestellt wird. Andernfalls würde eine NullPointerException geworfen werden. In dieser Methode wird auch eine neue Instanz von MyEntity erstellt und persistiert. Dies zeigt, dass der EntityManager durch CDI eingefügt public class MyEJBService MyOtherEJBService public void dosomethingwiththeotherservice() { otherservice.dosomething(); MyEntity entity = new MyEntity(); entity.setname("hello"); em.persist(entity); System.out.println("Entity persisted!"); Listing 4: Der erste Service des Beispiels: MyEJBService Die Methode MyOtherEJBService.doSomething() macht nichts anderes, als eine Nachricht in der Konsole zu zeigen. Die Methode getallentities() gibt alle MyEntity-Einträge mit Hilfe des EntityManagers zurück. Da in MyEJBService eine Instanz von My- Entity persistiert wurde, soll es durch MyOtherEJBService.getAllEntities() möglich sein, diese wieder zu public class MyOtherEJBService public void dosomething() { 5 Bean-Test Der Test wird vom JUnit-Framework ausgeführt. Es handelt sich somit um einen typischen JUnit-Test (Listing 6). Durch die Methode initialisebeanmanager(), die annotiert ist, wird der BeanManagerHelper initialisiert. In der Test-Methode shouldinjectejbascdibean() wird eine Instanz von MyEJBService durch den BeanManagerHelper erstellt und die Methode dosomething- WithOtherService() aufgerufen. Damit wird gezeigt, dass die Referenz auf MyOtherEJBService und den EntityManager vom CDI- Container aufgelöst wurde. Darüber hinaus wird die Test-Methode MyOtherEJBService.get- AllEntities() aufgerufen, um nachzuweisen, dass eine Instanz der Klasse MyEntity in der Datenbank existiert. Da diese Instanz vom MyEJBService persistiert wurde, bedeutet dies, dass sich beide EJBs den gleichen Persistence-Kontext innerhalb des Aufrufs der Test-Methode teilen. Das simuliert das Laufzeitverhalten in einem Container eines Java EE-Applikationsservers. public class TestEJBInjection { private static BeanManagerHelper public static void initialisebeanmanager() { bm = new public void shouldinjectejbascdibean() { MyEJBService myservice = bm.createinstance(myejbservice.class); myservice.dosomethingwiththeotherservice(); MyOtherEJBService myotherservice = bm.createinstance(myotherejbservice.class); asserttrue(myotherservice.getallentities().size() > 0); Listing 6: Bean-Test in TestEJBInjection Der CDI-Container kümmert sich um das DI jeder Bean und des EntityManagers. Allerdings haben wir keine CDI-Beans, sondern EJBs. Wie kann der CDI-Container die EJBs erkennen bzw. injizieren? Dank einem der mächtigsten Features von CDI den CDI-Extensions. Bei der Initialisierung des CDI-Containers wird der ganze Classpath nach möglichen CDI-Beans (eigentlich ist jedes POJO eine potenzielle CDI-Bean), Interceptors, Events usw. gescannt. Auf diese Weise erkennt der CDI- Container, wo die Dependencies zu finden sind. Wie schon erwähnt, haben wir aber keine CDI-Bean. An dieser Stelle kommt die CDI-Extension zum Einsatz (Listing 7). import info.novatec.cdi.test.utils.transactional; import javax.ejb.ejb; import javax.ejb.stateless; import javax.enterprise.context.requestscoped; import javax.enterprise.event.observes; import javax.enterprise.inject.spi.annotatedfield; import javax.enterprise.inject.spi.annotatedtype; import javax.enterprise.inject.spi.extension; import javax.enterprise.inject.spi.processannotatedtype; import javax.inject.inject; 5 41
4 import javax.persistence.persistencecontext; import org.apache.deltaspike.core.util.metadata.annotationinstanceprovider; import org.apache.deltaspike.core.util.metadata.builder.annotatedtypebuilder; public class CDITestExtension implements Extension { public<x> void ProcessAnnotatedType<X> pat) { if(pat.getannotatedtype().isannotationpresent(stateless.class)) { createejbwrapper(pat, pat.getannotatedtype()); private<x> void createejbwrapper(processannotatedtype<x> pat, finalannotatedtype<x> at) { Transactional transactionalannotation= AnnotationInstanceProvider.of(Transactional.class); RequestScopedrequestScopedAnnotation= AnnotationInstanceProvider.of(RequestScoped.class); AnnotatedTypeBuilder<X> builder= newannotatedtypebuilder<x>().readfromtype(at); builder.addtoclass(transactionalannotation). addtoclass(requestscopedannotation) ; Inject injectannotaiont= AnnotationInstanceProvider.of(Inject.class); for(annotatedfield<? super X>field:at.getFields()) { if ((field.isannotationpresent(ejb.class) field.isannotationpresent(persistencecontext.class))&&! field.isannotationpresent(inject.class)) { builder.addtofield(field, injectannotaiont); // Wrapper anstatt der tatsächlichen Bean setzen pat.setannotatedtype(builder.create()); Listing 7: Dependency-Injection mittels CDITestExtension Die Extension wird angewendet, sobald der CDI-Container gestartet wird. Dies passiert noch, bevor die Beans zur Verfügung gestellt werden, sodass Injection-Points, Bean-Definitionen usw. geändert werden können, ohne den Code anpassen zu müssen. Die Extension macht Folgendes: H Es wird überprüft, ob die entsprechende Bean markiert ist. H Es werden die zu der Bean hinzugefügt. Es handelt sich dabei um eine Änderung am Metamodell. Der Bytecode wird also nicht modifiziert. H Es wird überprüft, ob die Bean Felder hat, die markiert sind. Falls ja, werden diese Felder markiert. H Die modifizierte Bean wird anstelle der ursprünglichen Bean zur Verfügung gestellt. Grundsätzlich wird jede EJB in eine CDI-Bean konvertiert. Diese Konvertierung findet statt, ohne dass der Quellcode in irgendeiner Form angepasst werden muss. Für die Modifikation des Metamodells verwenden wir erneut Apache Delta-Spike. Im Prinzip kann der EJB-Wrapper auch manuell, also ohne die Hilfe von DeltaSpike, erstellt werden. Das bedeutet aber viel Boilerplate-Code. Was macht die Das ist keine standardisierte Annotation, sondern lediglich ein ganz normales CDI-InterceptorBinding (Listing 8). Den zugehörigen CDI-Interceptor zeigt Transactional TransactionAttributeType transactionattribute() default TransactionAttributeType.REQUIRED; Listing @Transactional public class private final Logger logger = LoggerFactory.getLogger(TransactionalInterceptor.class); private static final ThreadLocal<Stack<String>> stackholder= new ThreadLocal<Stack<String>>() protected Stack<String> initialvalue() { return new Stack<String>(); public Object managetransaction(invocationcontext ctx) throws Exception { TransactionAttribute transaction = ctx.gettarget().getclass().getannotation( TransactionAttribute.class); logger.debug("entitymanager in interceptor {", em); if (!em.gettransaction().isactive()) { logger.debug("transaction is not active. " + "A new transaction will be activated"); em.gettransaction().begin(); String clazzname = ctx.getmethod().getdeclaringclass().getname(); stackholder.get().push(clazzname + "." + ctx.getmethod().getname()); Object result = ctx.proceed(); if (em.isopen() && em.gettransaction().isactive() && stackholder.get().isempty()) { logger.debug( "Transaction is active and will be commited for {.{", clazzname, ctx.getmethod().getname()); em.gettransaction().commit(); return result; Listing 9: CDI-Interceptor TransactionalInterceptor Der Interceptor startet eine Transaktion und führt ein Commit aus, wenn es keine Aufrufe mehr im Stack gibt. Somit werden die EntityManager-Operationen innerhalb einer Transaktion durchgeführt. Die Implementierung des Interceptors ist für die Durchführung solcher Bean-Tests gedacht. Sie sollte auf keinen Fall in der Produktion eingesetzt werden: Die Implementierung greift auf das Transaction-Objekt des EntityManagers zu, während in einem Java EE-Container eher der TransactionManager verwendet wird. Auch wird die Transaktion im Container anders propagiert. Im Interceptor sowie in den EJBs wird ein EntityManager injiziert. Dazu muss dem CDI-Container mitgeteilt werden, wie der EntityManager zur Verfügung gestellt wird. Hierzu verwenden wir einen CDI-Producer (Listing public class EntityManagerProducer { private EntityManagerFactory emf; private void initializeentitymanagerfactory() { HashMap<String, String> properties = new HashMap<String, String>(); properties.put("hibernate.connection.driver_class", "org.h2.driver"); properties.put("hibernate.connection.url", "jdbc:h2:mem:test;db_close_delay=-1"); properties.put("hibernate.dialect", "org.hibernate.dialect.h2dialect"); properties.put("hibernate.hbm2ddl.auto", "create"); 5 42 JavaSPEKTRUM 5/2013
5 properties.put("hibernate.show_sql", "true"); emf=persistence.createentitymanagerfactory("test", public EntityManager getentitymanager(injectionpoint ip) { PersistenceContext ctx = ip.getannotated().getannotation(persistencecontext.class); //An dieser Stelle hat man die Möglichkeit, //die Konfiguration zur Persistenz zu verändern. if(em == null) { em = emf.createentitymanager(); return em; Listing 10: CDI-Producer EntityManagerProducer Der EntityManager wird durch das JPA-Bootstrapping-Verfahren zur Verfügung gestellt. Darüber hinaus wird er für die Verwendung einer In-Memory-H2-Datenbank konfiguriert. Diese Definitionen könnten beispielweise in eine Datei ausgelagert werden, um je nach Testumgebung eine entsprechende Konfiguration zu verwenden. Es wäre auch möglich, unsere Anwendung mit verschiedenen Persistence-Providern zu testen. Bisher haben wir ausschließlich standardisierte Mittel verwendet, um EJBs zu testen. Die EJBs mussten weder gemockt noch deployt werden. Das heißt, Dependencies werden tatsächlich aufgelöst und Code wird so aufgerufen, wie er auch im Container ablaufen würde. Insgesamt stellt sich die Frage, ob die Tests beim Zusammenspiel all dieser Komponenten nicht zu langsam werden? Immerhin wird ein CDI-Container (Weld) gestartet, die Dependencies werden aufgelöst, Interceptoren aufgerufen usw. Abb. 3: Ausführungsgeschwindigkeit des Bean-Tests Die Ausführungszeit der JUnit-Tests zeigt Abbildung 3. Der Test wird auf einem normalen Entwicklerrechner in unter einer Sekunde ausgeführt. Eine solche Feedback-Geschwindigkeit kann man durchaus als Unit-Testing betrachten. Übrigens: Der Interceptor, die Extension sowie die Konfigurationsdateien (persitence. xml, beans.xml usw.) befinden sich im Test-Verzeichnis (src/test/java ggf. src/test/resources). Der Quellcode und die Konfiguration der Anwendung werden für den Test mittels CDI nie berührt. Fazit In diesem Beitrag wurde gezeigt, dass CDI eine interessante sowie mächtige Vorgehensweise für das Testen einer Java EE- Anwendung schafft. Allerdings hören damit die Möglichkei- JavaSPEKTRUM ist eine Fachpublikation des Verlags: SIGS DATACOM GmbH Lindlaustraße 2c Troisdorf Tel.: / Fax: / ten noch lange nicht auf. Mittels CDI sind beispielsweise Security-Tests sehr einfach realisierbar: Es können Tests mit unterschiedlichen Benutzern und Rollen durchgeführt werden, um so die korrekte Definition der Sicherheitsregeln zu überprüfen. Ein wichtiger Aspekt ist auch, dass CDI das Java EE-Paradigma Convention over Configuration einhält: CDI wird aktiviert, indem eine leere beans.xml-datei im Classpath zur Verfügung gestellt wird. Darüber hinaus bietet CDI ein typsicheres Verfahren für DI an. Das führt dazu, dass Fehler aufgrund nicht existierender bzw. mehrdeutiger Abhängigkeiten bereits bei der Initialisierung der CDI-Implementierung, und nicht erst zur Laufzeit, aufgedeckt werden. In der Version 1.1 von CDI wurden wichtige Features ergänzt und eine verbesserte Integration mit anderen Spezifikationen erreicht. Weld selbst ist eine sehr ausgereifte Implementierung, welche bereits seit langer Zeit bei JBoss Seam eingesetzt wird. Einem produktiven Einsatz steht daher aus Sicht der Autoren nichts im Weg. Links [Arquillian] [Bien10] A. Bien, Trouble with crippled Java EE 6 APIs in Maven repository and the solution, , [CanDI] [DeltaSpike] Apache DeltaSpike, [JSR299] Java Specification Request 299: Contexts and Dependency Injection for the Java TM EE platform, [JSR346] Java Specification Request 346: Contexts and Dependency Injection for Java TM EE 1.1, [Mockito] [OWB] [Weld] JSR-346 Reference Implementation, [WeldHome] Carlos Barragan beschäftigt sich seit über zehn Jahren mit Anwendungsentwicklung. Er ist Senior Consultant bei der NovaTec GmbH und leitet die Competence-Group Enterprise Application Architecture Java EE. Professor Dr. Gerhard Wanner lehrt und forscht an der Hochschule für Technik Stuttgart im Studienbereich Informatik mit den Schwerpunkten Software-Engineering und Middleware-Technologie. Dieter Baier beschäftigt sich seit über zwanzig Jahren mit Anwendungsentwicklung im Enterprise- Umfeld. Als Managing Consultant der NovaTec GmbH liegt sein Arbeitsschwerpunkt in der Integration von Enterprise-Anwendungen
Javaaktuell. Java entwickelt sich weiter. ijug. Neue Frameworks AspectJ, Eclipse Scout, Citrus. Raspberry Pi Projekte mit Java
04-2015 Winter www. ijug.eu Praxis. Wissen. Networking. Das Magazin für Entwickler Aus der Community für die Community Java entwickelt sich weiter Javaaktuell Javaaktuell 4 191978 304903 04 D: 4,90 EUR
Java EE 6 Ein Überblick
Java EE 6 Ein Überblick Bernd Müller Fakultät Informatik Ostfalia Hochschule Braunschweig/Wolfenbüttel GI-Regionalgruppe Braunschweig, 16.2.2012 Bernd Müller, Fakultät Informatik, Ostfalia, 16.2.2012 1/31
EJB3.0 Unit-Testing Reloaded
EJB3.0 Unit-Testing Reloaded Werner Eberling werner.eberling@mathema.de www.mathema.de Werner Eberling, MATHEMA Software GmbH - EJB3.0 - Unit-Testing Reloaded (G4 - Folie 1) Java Forum Stuttgart 2007 Automatisiertes
CDI - Dependency Injection Standard für Java
CDI - Dependency Injection Standard für Java Ein Überblick OIO Orientierungspunkt April 2014 Version: 1.0 Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de info@oio.de Ihr Sprecher
Web-Anwendungen mit Arquillian testen
Michael Kotten open knowledge @michaelkotten @_openknowledge Wozu denn testen? Ich mach doch keine Fehler! Wozu denn testen? > Notwendig bei komplexen Systemen > Sicherung von > Qualität > Funktionalität
Geschäftskomponenten mit EJB 3.1
Geschäftskomponenten mit EJB 3.1 Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen Kurt Fastner Sommersemester 2012 Inhalt Was ist EJB Die verschiedenen EJB-Typen/Komponenten Applikationsserver,
Übungsaufgabe Transaktion als Middleware
Übungsaufgabe Transaktion als Middleware und Java Persistence API Client/Server Abstraktes Komponentenmodell Entscheidende Punkte Erweiterung der Invoke-Methode Context-Verwaltung Transaktionsbehandlung
Contexts and Dependency Injection. W3L AG info@w3l.de
1 Contexts and Dependency Injection W3L AG info@w3l.de 2015 2 Inhaltsverzeichnis Teil 1: Motivation Teil 2: Inversion of Control Teil 3: Contexts and Dependency Injection Teil 4: Beispiel zurück 3 Motivation
Schritt 4: Hallo Enterprise Bean
Prof. Dr. Th. Letschert FB MNI JEE Schritt 4: Hallo Enterprise Bean Einstieg: EJBs erzeugen und nutzen Meine erstes EJB Projekt Enterprise Beans sind eine Backend Technologie, die mit unterschiedlichen
Enterprise JavaBeans Überblick
Enterprise JavaBeans Überblick 1. Überblick Java EE 5 und Komponententechnologien 2. Einführung Java EE 5 Plattform 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5.
Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH
Erfahrungen und Erkenntnisse Klaus Richarz, HBT GmbH Java Enterprise Edition 5.0 JBoss Seam Konsequenzen für Realisierung Qualitätssicherung Build & Deployment Fazit & Empfehlungen JBoss Seam in Projekten,
JBoss Seam. Ein JEE 5 Webframework. Jörg Wüthrich Infopoint, 4. Februar 2009
JBoss Seam Ein JEE 5 Webframework Jörg Wüthrich Infopoint, 4. Februar 2009 Inhalt Einführung Warum Seam? Zentrale Konzepte Demo Validierung Abschliessende Gedanken 04.02.2009 Infopoint - JBoss Seam - Jörg
Testest Du schon? Verfahren und Tools zum Testen von Software
Testest Du schon? Verfahren und Tools zum Testen von Software Martin Kompf Dezember 2010 JAVA USER GROUP DARMSTADT Testing Software Ziel des Softwaretests ist es, Fehler aufzudecken. Nachzuweisen, dass
Spring Dynamic Modules for OSGi Service Platforms
Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick
Java Persistence API 2.x. crud + relationships + jp-ql
Java Persistence API 2.x crud + relationships + jp-ql Grundprinzip 10.02.10 2 Problematik Man muss bei der Persistierung immer das Klassenmodell und dessen Umsetzung im Datenmodell (in der DB) berücksichtigen.
Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung
Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule
OSGi. The Next Generation Java Service Platform. SOA - The Java Way or My classpath is killing me. Michael Greifeneder
Michael Greifeneder OSGi The Next Generation Java Service Platform SOA - The Java Way or My classpath is killing me Bilder von Peter Kriens W-JAX Keynote 2007 und Neil Bartletts Getting Started with OSGi
Workshop Java Webentwicklung Einführung in Hibernate. Ulrich Stärk
Workshop Java Webentwicklung Einführung in Hibernate Ulrich Stärk Ablauf Montag bis Donnerstag 09:00 Uhr s.t. Beginn, bis ca. 17:00 Uhr 1 Stunde Mittagspause Donnerstag Experiment Aufzeichnung der Programmiertätigkeit
Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept
Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,
Softwareentwicklung mit Enterprise JAVA Beans
Softwareentwicklung mit Enterprise JAVA Beans JPA - JAVA Persistence API Problem In JAVA-programmen arbeitet man mit Hauptspeicherobjekten. Nach Beendigung des Programmes sind diese nicht mehr vorhanden.
Oracle Enterprise Scheduler (ESS) Unleashed Carsten Wiesbaum esentri AG Ettlingen Schlüsselworte Einleitung Oracle Enterprise Scheduler (ESS)
Oracle Enterprise Scheduler (ESS) Unleashed Carsten Wiesbaum esentri AG Ettlingen Schlüsselworte Automatisierung, Betrieb, Middleware Einleitung Der Oracle Fusion Middleware Stack beinhaltet eine leistungsstarke
Anwendungsentwicklung mit Spring
Anwendungsentwicklung mit Spring Eberhard Wolff Managing Director Interface21 GmbH Interface21 - Spring from the Source Interface21 Produkte u.a. Spring Framework Spring from the Source Consulting, Training,
Spring Dynamic Modules for OSGi Service Platforms
Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick
Das Interceptor Muster
Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster
Automatisiertes Testen von Java EE-Applikationen mit Arquillian
CONCEPTS DEVELOPMENT INTEGRATION Automatisiertes Testen von Java EE-Applikationen mit Arquillian Sebastian Lammering CDI AG Firmenkurzportrait Die CDI ist ein IT-Beratungsunternehmen mit Sitz in Dortmund.
EJB 3 - Ein Blick über den Tellerrand. Heiko W. Rupp
EJB 3 Ein Blick über den Tellerrand Heiko W. Rupp Agenda Abriss des Standards Blick auf vorhandene Implementierungen Erfahrungen aus der Praxis Verlosung der 2 Bücher Agenda Abriss des
RESTful Services mit Java EE
RESTful Services mit Java EE Thilo Frotscher thilo@frotscher.com Vorstellung Freiberuflicher Softwarearchitekt und Trainer Fachliche Schwerpunkte Java Plattform Services und Integration Kundenspezifische
Entwicklung von Web-Anwendungen auf JAVA EE Basis
Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages
Qualitätssicherung im Container
Neue Kolumne: Docker rockt Java 85 Java Mag 4.2015 magazin Java Architekturen Web Agile Brownies Collections High-Performance Lists für Java www.javamagazin.de Selenium 30 Funktionale Oberflächentests
Oliver Paulus, oliver@code-project.org. 7. Februar 2006. Spring Framework Einführung. Oliver Paulus, oliver@codeproject.org. Was ist Spring?
oliver@code-project.org 7. Februar 2006 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2
JAX-RS 2.0 REST mit Java EE 7
Enterprise Java, Web Services und XML JAX-RS 2.0 REST mit Java EE 7 Java User Group Darmstadt 13. Juni 2013 http://www.frotscher.com thilo@frotscher.com Vorstellung Freiberuflicher Softwarearchitekt und
Programmierung von Client/Server- Anwendungen
Programmierung von Client/Server- Anwendungen Komponenten des Web-Containers (Java EE) SoSe2015 Prof. Dr. Andreas Schmietendorf 1 Übersicht zur Vorlesung Entwicklung der Java Enterprise Edition Servlets,
Softwareentwicklung mit Enterprise JAVA Beans
Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung
Schritt 5: Session Beans
Prof. Dr. Th. Letschert FB MNI JEE Schritt 5: Session Beans Session Beans Übersicht Session Beans dienen dazu serverseitige Geschäftsprozesse zu realisieren. Es gibt sie drei Zustands Varianten: Stateless
Geschäftskomponenten mit EJBs
Geschäftskomponenten mit EJBs FWP Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen Theis Michael - Senior Developer UniCredit Global Information Services S.C.p.A Sommersemester 2012 2
Prozessautomatisierung mit BPMN 2.0 und Java. bernd.ruecker@camunda.com
Prozessautomatisierung mit BPMN 2.0 und Java bernd.ruecker@camunda.com Bernd Rücker camunda services GmbH Demo Was ist Prozessautomatisierung mit BPMN 2.0 Prozessautomatisierung mit Process Engine Monitoring
Bean-Mapping mit MapStruct
Machst Du noch Reflection oder annotierst Du schon? Bean-Mapping mit MapStruct Thomas Much thomas@muchsoft.com www.muchsoft.com 1 20 Jahre Java, 18 Jahre Beans JavaBeans JAXBEntities 2015 2006 2005 2000
COPPER Best Practices
COPPER Best Practices Version 1.0.1 Wann sollte man überhaupt COPPER verwenden? Allgemein genau dann, wenn man von der COPPER Notation oder den COPPER-Features profitieren kann. Ein wesentliches Feature
Dennis Schulte / Tobias Flohre codecentric AG. Enterprise Java Batch mit Spring
Dennis Schulte / Tobias Flohre Enterprise Java Batch mit Spring Dennis Schulte Düsseldorf @denschu www.github.com/denschu blog.codecentric.de/author/dsc tel +49 (0) 1515 _ 288 2395 dennis.schulte@codecentric.de
FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen
FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen Sommersemester 2013 Michael Theis, Lehrbeauftragter Java EE Spezifikation definiert ein Programmiermodell für Applikationen die Eigenschaften
Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013
GTUG Java Arbeitskreis Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung September 2013 Jürgen Depping CommitWork GmbH Seite 1 Info@CommitWork.de www.commitwork.de Agenda Was ist OmnivoBase?
Allgemein: Klassen testbar machen. 5. Mocking. Mocks programmieren. Zusammenspiel von Klassen testen
5. Mocking Allgemein: Klassen testbar machen Wie werden Klassen testbar Entwicklung von Mocks mit der Hand Einführung in JMock Spezifikation von Mocks mit JMock Wann ist Mocking-Werkzeug sinnvoll Literatur:
G s e a s m a t m ar a ch c i h tek e tur u I und IoC
Gesamtarchitektur I und IoC Schichten einer Web-Anwendung Initiiert durch J2EE und Spring: Strukturierte Sicht auf UI und Fachlogik (Domäne) Ergibt 5 Schichten: Man unterscheidet Präsentations- und Domänenmodell!
Annotations in PHP. Von Dokumentation bis Funktionalität. Thorsten Hallwas, Software Engineer Florian Sonnenburg, Project Lead
Annotations in PHP Von Dokumentation bis Funktionalität Thorsten Hallwas, Software Engineer Florian Sonnenburg, Project Lead 1 Über uns Thorsten Hallwas Software Engineer ICANS GmbH Dipl.-Inf. (FH) Zend
Application Frameworks
Seminar Software Engineering 1 Grundlagen Agenda Spring Framework Dependency Injection Aspektorientierte Programmierung Datenbankanbindung Modell View Controller Sicherheit Spring vs. Java EE Zusammenfassung
Enterprise Java Beans Einführung
Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse
Inhaltsverzeichnis. 1 Ein Einstieg mit Profil 1. 2 Aufsetzen der Entwicklungsumgebung 19
xi 1 Ein Einstieg mit Profil 1 1.1 Java EE 7 der Standard für Enterprise Java.................. 1 1.1.1 Struktur einer Enterprise-Java-Anwendung............. 1 1.1.2 Die Java Enterprise Edition (Java EE)..................
Cargo-Tracker: DDD auf Basis von Java EE
Cargo-Tracker: DDD auf Basis von Java EE Dirk Ehms GameDuell GmbH Berlin Schlüsselworte Domain-Driven Design, DDD, Java EE, Cargo Tracker Einleitung Die Herangehensweise des Domain-Driven Designs (DDD)
5. Übung zu Software Engineering
5. Übung zu Software Engineering WS 2009/2010 Henning Heitkötter Desktop-Anwendung AUFGABE 13 1 Schichtenarchitektur Strukturierung komplexer Anwendungen Anforderungen: Flexibilität, Robustheit, Wartbarkeit,
Web-Testen mit JUnit und HttpUnit. Kai Schmitz-Hofbauer Lehrstuhl für Software-Technik Ruhr-Universität Bochum
1 Web-Testen mit JUnit und HttpUnit Kai Schmitz-Hofbauer Lehrstuhl für Software-Technik Ruhr-Universität Bochum 2 Inhalt Entwicklertests in der Praxis Unit-Testing JUnit HttpUnit Praktisches Beispiel Bewertung
Programmierprojekt. Anne0e Bieniusa Sommersemester 2014
Programmierprojekt Anne0e Bieniusa Sommersemester 2014 Phasen der So;ware- Entwicklung Planungsphase DefiniConsphase Entwurfsphase ImplemenCerungsphase Testphase Wasserfall- Modell Einführungs- und Wartungsphase
Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de
s & Servlet Integration Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Motivation Das Interface Stateful und Stateless s Programmierung einer Stateful
JUnit - Test Driven Development. Bernhard Frey, Thorsten Stratmann, Jackson Takam, Michel Müller 1
JUnit - Test Driven Development Bernhard Frey, Thorsten Stratmann, Jackson Takam, Michel Müller 1 Gliederung 1.Einleitung 1.1 Geschichte 1.2 Was sind Unit-Tests? 1.3 Failures/Errors 1.4 Ziele und Nutzen
Architektur im Kontext der Cloud: Patterns und Best Practices 62. Logging. Auswirkung moderner Architektur auf den Betrieb 32
Architektur im Kontext der Cloud: Patterns und Best Practices 62 JAVA Mag Sonderdruck 11.2014 magazin Java Architekturen Web www.javamagazin.de Apache DeltaSpike Portabilität und Community 16 Der Rest
Architektur iterativ auf Basis von OSGi entwickeln
Architektur iterativ auf Basis von OSGi entwickeln Ein Vortrag von Sven Jeppsson (syngenio AG) und Karsten Panier (Signal Iduna Gruppe) 1 Inhalt Motivation Architektur Architektur Evolution OSGi Refactoring
Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013
Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael
Client/Server-Programmierung WS2007/08. EJB/JSP: Schritt-für-Schritt Anleitung
Client/Server-Programmierung WS2007/08 EJB/JSP: Schritt-für-Schritt Anleitung Version 1.1, 26.09.07 Eingesetzte Software: - Apache Tomcat 5.5.9 bzw. 5.5.12 (http://tomcat.apache.org/download-55.cgi#5.5.12)
Dependency Injection in der Praxis: Spring, PicoContainer und Eclipse im Vergleich
Dependency Injection in der Praxis: Spring, PicoContainer und Eclipse im Vergleich Dipl.-Informatiker Martin Lippert Senior IT-Berater martin.lippert@it-agile.de http://www.it-agile.de/ Überblick Motivation
Hivemind Ein leichtgewichteter Container
Hivemind Ein leichtgewichteter Container Manfred Wolff, wolff@manfred-wolff.de, www.manfred-wolff.de Container sind Laufzeitumgebungen für Objekte. Der mächtigste Container im Java-Umfeld der EJB Container
Java für C++ Programmierer
Java für C++ Programmierer Alexander Bernauer bernauer@inf.ethz.ch Einführung in die Übungen zu Informatik II (D ITET) FS2010 ETH Zürich Ziel Allgemeiner Überblick Kennenlernen der Suchbegriffe Warum Java?
Auszug aus JAX-WS Folien
Auszug aus JAXWS Folien Dieses Dokument ist ein Auszug aus unserem Skript zur Java Web Services Schulung. Es dient lediglich als Beispiel für unsere Kursunterlagen. Thomas Bayer Hauptstraße 33 75050 Gemmingen
Komponentenbasierte Softwareentwicklung mit PHP. Oliver Schlicht - bitexpert
Komponentenbasierte Softwareentwicklung mit PHP Oliver Schlicht - bitexpert Überblick 1. Was ist eine Komponente? 2. Entwicklung eines Beispieldesigns 3. Dependency Injection 4. DI Container Garden 5.
Separates Deployment von Produktdaten Cornelius Dirmeier (Dokumentversion 47)
Separates Deployment von Produktdaten Cornelius Dirmeier (Dokumentversion 47) Einleitung Faktor-IPS verwaltet Produktdaten während der Produktentwicklung in XML Dateien. Zur Laufzeit liegen die Produktdaten
REST-Services mit Dropwizard ruck-zuck erstellt, dokumentiert und getestet
.consulting.solutions.partnership REST-Services mit Dropwizard ruck-zuck erstellt, dokumentiert und getestet Alexander Schwartz, Principal IT Consultant Berlin Expert Days 2015 REST-Services ruck-zuck
Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007
Eclipse Equinox als Basis für Smart Client Anwendungen Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Übersicht Definition / Architektur Smart Client Smart Client mit RCP / Equinox Gesamtfazit
Modulare Anwendungen und die Lookup API. Geertjan Wielenga NetBeans Team Deutschsprachige Überarbeitung, Aljoscha Rittner NetBeans Dream Team
Modulare Anwendungen und die Lookup API Geertjan Wielenga NetBeans Team Deutschsprachige Überarbeitung, Aljoscha Rittner NetBeans Dream Team Die Notwendigkeit modularer Anwendungen Die Notwendigkeit modularer
OSGi: Toolunterstützung und Softwareentwicklungsprozess
OSGi: Toolunterstützung und Softwareentwicklungsprozess Thementag OSGi 03.11.2009 Autor: Thorsten Vogel Agenda Herausforderungen der OSGi Entwicklung: Beispiel Webanwendung Was wird entwickelt? - Bundles
Best Practices für flexible und wartbare Codegeneratoren mit openarchitectureware Karsten Thoms Software Architekt 20.04.2009
Best Practices für flexible und wartbare Codegeneratoren mit openarchitectureware Karsten Thoms Software Architekt 20.04.2009 1 Agenda (1) Fornax-Plattform, Cartridges (2) Referenzimplementierung, Referenzmodell
Ausgepackt! Erfahrungen aus meiner Einarbeitung in e4. Marc Teufel
Ausgepackt! Erfahrungen aus meiner Einarbeitung in e4 Marc Teufel Über mich! Software-Entwickler! Java: Eclipse RCP + Webapps! PL/SQL! Visual Basic.NET! Python! Autor! 2 Bücher über Web Services! Artikel
Leichtgewichtig testen
Enterprise JEE Testing Das Testframework Arquillian eine Einführung Leichtgewichtig testen Mit Java EE 6 lässt sich inzwischen leichtgewichtig entwickeln, doch ist das Aufsetzen von Integrationstests immer
BPMN 2.0 gehört in den Werkzeugkasten JEDES Java Entwicklers! bernd.ruecker@camunda.com
BPMN 2.0 gehört in den Werkzeugkasten JEDES Java Entwicklers! bernd.ruecker@camunda.com Bernd Rücker camunda services GmbH Was ist Prozessautomatisierung? Das Ganze ist ein BPMN Prozess Aber auch (und
Operation am offenen Herzen
Operation am offenen Herzen Case Study zur erfolgreichen JEE-7 Migration Dirk Ehms, GameDuell GmbH GameDuell Plattform Topologie Classic Platform Social Platform 64x Frontend Server OpenMQ 16x Frontend
Info: Standard DO-178B. 5. Mocking. Zusammenspiel von Klassen testen. Allgemein: Klassen testbar machen
Info: Standard DO-178B Zertifizierung Federal AviationAdministration (FAA), Software für Luftverkehrssysteme durch Standard DO-178B für requirement-based Tests and Code Coverage Analyse DO-178B-Levels
Asynchrone Webservices mit Axis 1.x in Java
Asynchrone Webservices mit Axis 1.x in Java 1. Übersicht Architektur Da Webservices nach relativ kurzen Timeouts Anfragen abgearbeitet haben müsse, sind komplexe Anfragen wie sie in der Bioinformatik üblich
Programmieren in Java
Programmieren in Java Vorlesung 12: Metawissen Java Bibliotheken, Maven Robert Jakob Albert-Ludwigs-Universität Freiburg, Germany SS 2013 Robert Jakob (Univ. Freiburg) Programmieren in Java JAVA 1 / 33
Next generation open source BPM JBoss jbpm 4. Java Forum Stuttgart 02.07.2009 bernd.ruecker@camunda.com
Next generation open source BPM JBoss jbpm 4 Java Forum Stuttgart 02.07.2009 bernd.ruecker@camunda.com Bernd Rücker / bernd.ruecker@camunda.com / 2 Guten Morgen Berater, Trainer, Coach Softwareentwickler
Einführung in das Microsoft.NET-Framework. Programmiersprache C# MEF Das Managed Extensibility Framework. André Kunz
Einführung in das Microsoft.NET-Framework Programmiersprache C# MEF Das Managed Extensibility Framework André Kunz 21.09.2010 1 In dieser Einführung bekommen Sie einen kurzen Einstieg in das.net-framework
CamelCaseCon 2011 Vortrag von Stefan Glase am 07.09.2011. Statische Code-Analyse für Groovy & Grails mit CodeNarc
Statische Code-Analyse für Groovy & Grails mit CodeNarc CamelCaseCon 2011 Vortrag von Stefan Glase am 07.09.2011 OPITZ CONSULTING GmbH 2011 Folie 1 Stefan Glase, OPITZ CONSULTING Software-Entwickler Java
Metadata Service Respository (MDS) - Sehen, lernen, verstehen!
Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Carsten Wiesbaum esentri AG Schlüsselworte Metadata Service Repository, MDS, Oracle Fusion Middleware Einleitung Früher oder später wird jeder
Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch
Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen Alexander Schunk Henry Trobisch Inhalt 1. Vergleich der Unit-Tests... 2 2. Vergleich der Codeabdeckungs-Tests... 2 3. Vergleich
Einführung in die Informatik Tools
Einführung in die Informatik Tools Werkzeuge zur Erstellung von Softwareprojekten Wolfram Burgard 8.1 Motivation Große Softwareprojekte werden schnell unübersichtlich. Änderungen im Code können leicht
Handbuch für die Erweiterbarkeit
Handbuch für die Erweiterbarkeit Inhalt Pakete für die Erweiterbarkeit... 2 Actions... 2 Items... 2 Itemset... 2 Die UseCaseNewAction... 3 Eigene Shapes... 4 Der Shape Container... 5 User Objects... 6
Kommunikation ist alles
Kommunikation in verteilten Systemen mit Kommunikation ist alles >> alexander ziegler In einem verteilten System müssen die Anwendungsbestandteile miteinander interagieren nur so funktioniert ein großes
Integration von Web Services in J EE Anwendungen mit XFire. 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire
Integration von Web Services in J EE Anwendungen mit XFire 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire univativ : = Umsetzung durch Studenten und Young Professionals.
Objektorientierte Programmierung
Universität der Bundeswehr Fakultät für Informatik Institut 2 Priv.-Doz. Dr. Lothar Schmitz FT 2006 Zusatzaufgaben Lösungsvorschlag Objektorientierte Programmierung Lösung 22 (Java und UML-Klassendiagramm)
Programmieren in Java
Programmieren in Java objektorientierte Programmierung 2 2 Zusammenhang Klasse-Datei In jeder *.java Datei kann es genau eine public-klasse geben wobei Klassen- und Dateiname übereinstimmen. Es können
Das Test-Framework JUnit ETIS SS04
Das Test-Framework JUnit ETIS SS04 Gliederung Motivation TestFirst Grundlagen Assert TestCase Lebenszyklus TestCase UML-Diagramm TestCase TestSuite Zusammenfassung 2 Motivation (I) Kostspielige Folgen
Javaaktuell. Java entwickelt sich weiter. ijug. Neue Frameworks AspectJ, Eclipse Scout, Citrus. Raspberry Pi Projekte mit Java
04-2015 Winter www. ijug.eu Praxis. Wissen. Networking. Das Magazin für Entwickler Aus der Community für die Community Java entwickelt sich weiter Javaaktuell Javaaktuell 4 191978 304903 04 D: 4,90 EUR
Java Batch Der Standard für's Stapeln
Java Batch Der Standard für's Stapeln Berlin Expert Days 18.09.2015 Dirk Weil, GEDOPLAN GmbH Dirk Weil GEDOPLAN GmbH, Bielefeld GEDOPLAN IT Consulting Konzeption und Realisierung von IT-Lösungen GEDOPLAN
Tutorial: Eigene Module und Extensions entwickeln. version: 0.1 Author: Anja Beuth
Tutorial: Eigene Module und Extensions entwickeln version: 0.1 Author: Anja Beuth Table of contents 1 2 2.1 2.2 2.3 2.4 3 4 4.1 4.2 4.3 5 5.1 6 6.1 6.2 Notwendigkeit prüfen... Ein Projekt in Visual Studio
Unit Tests. Programmiermethodik. Eva Zangerle Universität Innsbruck
Unit Tests Programmiermethodik Eva Zangerle Universität Innsbruck Überblick Einführung Java Ein erster Überblick Objektorientierung Vererbung und Polymorphismus Ausnahmebehandlung Pakete und Javadoc Spezielle
Software Engineering II
Software Engineering II Codegenerierung für den SmartIO Editor mit der Modeling Workflow Engine Wintersemester 10/111 Fachgebiet Software Engineering Albert Zündorf / Wiederholung Bisher im Laufe des Semesters
Höhere Programmierkonzepte Testklausur
Höhere Programmierkonzepte Testklausur Prof. Dr. Nikolaus Wulff Zum 15. Januar 2016 1 Ein Google-Map Algorithmus (5 Punkte) 1 2 typedef void X; 3 typedef void Y; 4 5 void map(unsigned int n / tuple length
Anzeige des Java Error Stack in Oracle Forms
Anzeige des Java Error Stack in Oracle Forms (Version 2.0) Juni 2008 Autoren: Jürgen Menge / Thomas Robert Seite 1 von 7 Oracle Forms bietet seit der Version 6i die Möglichkeit, serverseitig Java-Klassen
Unit Tests und Fehlersuche
Unit Tests und Fehlersuche SE 1 - Softwareentwicklungspraktikum Test Deadline! Sinnvolle Tests kompilierbar im CVS d.h. Schnittstellen zu Strategiemethoden etc. schon erstellen Kommentieren! Besser ein
Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de info@oio.de Version: 2014 Orientation 1.0 in Objects GmbH Der Sprecher Erik Bamberg (OIO) 2 1 s Aufgaben des Cachings Datenbank
i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e Servlet Debugging
Servlet Debugging Markus Völter, voelter@acm.org, www.voelter.de Bei der Arbeit mit Servlets kommt man recht schnell an den Punkt, an dem man Servlets vernünftig testen oder debuggen will. Mit Hilfe des
Der IBM Websphere Portalserver
Der IBM Websphere Portalserver Ergebnisse aus dem Universitäts-Praxis-Projekt 2001/2002 Vortrag von Il-Hyun Kim und Horst Rechner am 19. Juli 2002 Weiterer Teilnehmer am UPP: Clemens Oertel Betreuer: Dipl.-Phys.
Warum EJB Technologie (1)?
Datenbanken und Informationssysteme 2 SS 2004 Prof. Dr. Stefan Böttcher Universität Paderborn Datenbanken und Informationssysteme 2 - Prof. Dr. Stefan Böttcher - SS 2004 Folie EJB - 1 Warum EJB Technologie
Testen von graphischen Benutzeroberflächen. 26. Juni 2013
Testen von graphischen Benutzeroberflächen 26. Juni 2013 Überblick Testarten Methoden-, Klassen-, Komponenten-, Systemtests Motivation für automatisches Testen von graphischen Benutzeroberflächen Entwicklungsprinzipien