Contexts & Dependency Injection for Java

CDI 2.0 Second Face to face meeting feedback

Posted by Antoine Sabot-Durand on Sep 29, 2015 | Comments

Last week we had our second CDI 2.0 Face to Face meeting in Paris (France). This is a summary of the point discussed and leads we’d like to follow. Of course each point we’ll lead to a proposal later and discussed on the mailing list.


CDI 2.0 is still planned for 1st half 2016. We’ll focus on new feature and SE support for this release.

CDI 2.1 should start after 2.0 release and focus Java EE 8 specific enhancement. We’ll probably focus a bit more on modularity since Java 9 will be around the corner giving us a better visibility of how anticipate its new module approach. Content of 2.1 will be defined in the coming weeks

CDI SE review

CDI bootstrap on Java SE is one of the feature released in our first early draft. The Java SE support needed extra work to be complete and we wanted to review the boot api included to see how it could be enhanced.

bootstrap API

We’d like to review the proposed bootstrap API to make it a bit richer and have the boot process in a specific class. The idea is to get inspiration from the new Weld Se bootstrap with a builder pattern (see Weld and WeldContainer classes) and the possibility to explicitly choose the implementation if multiple impl should be in classpath.

Context control

This feature seemed a bit risky to specify. We’d preferred an approach based on existing built-in scope: RequestScoped and an interceptor activating it for a given invocation and unactivating it just after . something like this:

public void doSomethigWithRequestScopedBeans() {

This could give users the possibility to start and stop a context without explicitly adding these methods in the SPI We also discussed the possibility to have a Conversation-like context activated thru a built-in scope.

Bean discovery mode

The new bootstrap api should prevent us to specify a new bean discovery mode since the builder api will contains a mean to deactivate bean discovery and create a synthetic bean archive by adding class and packages of beans.

Async event review

There was discussion about exceptions handling and the issues raised from mixing sync and async observers. So the leads we’d like to follow are the following

  • stop calling sync observer from fireAsync() (fire() is for @Observes and fireAsync() is for @ObservesAsync)

  • Remove FireAsyncException in favor of CompletionException since an exception during async events pipeline execution is noting more than that.

To sum it up:

Table 1. async and sync events rules
Event method @Observes notified @ObservesAsync notified


yes, in the same thread




yes, in a different thread

CDI Lite

As you know, CDI lite is one of the expected features for CDI 2.0. Yet, adding it with the SE / EE split for 2.0 could bring a lot of glitches and could reveal itself a catastrophe without speaking of specific impl and TCK for it.

That’s why we choose to add it in the annexe of the spec as a proposal for a next CDI version. Implementation will be allowed to create their CDI lite version based on this subset of CDI features:

  • JSR 330 with CDI type resolution rules

  • CDI qualifiers usage

  • Producers and disposers

  • Programmatic lookup

  • @Singleton and @Dependent pseudo-scopes support

  • SE bootstrap

We choose not to include events and spi to keep the impl lite. Of course this could be change during our discussion.

AOP on producer and custom beans

The goal was to propose a solution to apply Interceptors and Decorators on produced beans or custom beans. For producers we also have the problem of applying interceptor binding only on some method and not on the whole class. We looked for a solution that could be used in both case and that was more an "advanced users" approach than an out of box one.

The idea is to provide a class or a built-in bean to help produced bean instances using AnnotatedType to allow override of annotation on instance class. This suppose the addition of AnnotatedTypeBuilder to the SPI to ease the use of building a synthetic AnnotatedType. This would follow the same idea than the Unmanaged class which provide a way to inject bean in a non bean (non managed) class.

That would give something like:

public class MyAdvancedProducerBean {

    public BeanInstanceBuilder<MyClass> bib = new BeanInstanceBuilder<>();

    public MyClass produceTransactionalMyClass() {

        AnnotatedTypeBuilder<MyClass> atb = new AnnotatedTypeBuilder<>()
            , new TransactionalLiteral());

        return bib.readFromType(
            .build(); //instance of the bean with requested interceptors / decorators

    public void disposeMyClass (@Disposes Myclass td) {



A similar mechanism could be used in the create() method of custom beans.


Of course, all these points will be described in more detail in coming proposal documents. You’ll only find here general ideas of what we like to propose.

We also worked on other points in Jira for clarification or fix. This will go to the mailing list.

This post will be updated with new information or clarification if needed.

CDI 2.0 Early Draft Review 1 released

Posted by Antoine Sabot-Durand on Jul 03, 2015 | Comments

After eight months of work, the CDI 2.0 expert group is pleased to release this first draft of CDI 2.0 specification for community review. This draft contains important and long awaited features that will change CDI as we know it.

But these features are still proposals and we really need your feedback to know if the way we specified them fits your needs. Let’s check what’s on the menu.

CDI runs now in Java SE

One of the oldest request was the support of Java SE in CDI. Since the beginning the two main implementations (JBoss Weld and Apache OpenWebBeans) proposed proprietary solutions to use CDI in Java SE.

Then, Apache DeltaSpike came in and provided an absract solution to boot either implementations, but this wasn’t never standardized at spec level, until now…​

Why this important?

So, if implementation and a third party project already provide this Java SE support, what’s the big deal to have it at spec level? The answer is "increase adoption by other specifications".

A lot of Java EE specification provide a Java SE support (like JPA or JAX-RS). Since CDI doesn’t provide this support as well, they can’t rely totally on it since it is not available in Java SE. So, the side effect of this new Java SE support will be a better CDI integration in Java EE. If we add to this a broader adoption by third parties framework, we see that the benefits for CDI and its users goes far beyond the simple feature.

Preparing Java SE support (API split)

Adding such a straight forward feature to CDI seems quite easy on paper but, trust me, it wasn’t.

If you check the current 1.2 specification, you’ll see that EJB is everywhere in the spec. You also have reference to JSF, servlet or Expression Language all accross the document.

So the first work was to split the spec to put he Java EE specific feature in a dedicated part to have all CDI core feature (no tie to other spec) in its own part. This specification has now 3 parts plus an introduction as explain in the foreword section.

This work was done as carefully as possible to avoid destroying, duplicating or modifying rules, yet, your double check here is most welcome to be sure that we didn’t forget something in the rewriting.

Yes it’s rather long work to read (or re-read) the whole specification but it’s also the ocasion to see it with a fresh eye with this new organisation. You migh want grab the pdf version (whose look has been updated) of the spec to go through it.

Booting CDI in Java SE

After all this work (invisible for end users), we introduced the Java SE support by adding a bootstrap API for Java SE. The solution make use of already existing CDIProvider interface and CDI class.

Code for booting CDI in Java SE looks like this:

public static void main(String... args) {
    try(CDI<Object> cdi = CDI.getCDIProvider().initialize()) {
        // start the container, retrieve a bean and do work with it
        MyBean myBean =;
    // shuts down automatically after the try with resources block.

Go check the Bootstrapping a CDI container in Java SE chapter in the specification and tell us what do you think.

Still work to do

Java SE support needs more work and we are still working on the feature. The two main aspect are:

Again, your feedback and ideas are most welcome to help us for these part specification.

Ordering event observers

One of the oldest requested feature for CDI was resolved in this EDR : observer ordering.

The feature was simply design by using @Priority annotation (from commons annotation) and will be used like this:

void afterLogin(@Observes @Priority(APPLICATION) LoggedInEvent event) { ... }

The use of @Priority was rather obvious since we already use this annotaion for interceptor, decorator or alternatives activation and ordering. The only issue here is that the annotation only targets types right now. We asked for a review of JSR-250 to add parameter as accepted target for @Priority.

Check the section dealing with observer ordering to have all the details.

Asynchronous events

Another important feature requested by many of you. Introducing Asynchronous event wasn’t an easy thing, because we needed to keep backward compatibilty with existing events. We also wanted to leverage new asynchronous API in Java 8 to provide the most up to date approach in the spec.

The solution we choose was to introduce @ObservesAsync and add methods fireAsync() in the Event interface. So the exisitng observer (defined with @Observes) will stay synhcronous and new observer defined by @ObservesAsync will be called asynchronously if the event was triggered with fireAsync() (and won’t be called from a classical fire()).

So asynchronous event usage will look like this:

@Inject Event<LoggedInEvent> loggedInEvent;

public void login() {
    loggedInEvent.fireAsync( new LoggedInEvent(user) );


public void asyncAfterLogin(@ObservesAsync LoggedInEvent event) { ... }

The best is to re-read all the event chapter in the spec to get the details.

Why this double activation is needed?

For the producer (fire()) side it’s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there’s no debate on fireAsync().

On the observer side, the reason is for backward compatibility. CDI events are a great way to cross boundaries of our own code and activate unknown code at runtime in another module of the app (i.e. another jar) that we don’t own. This other code can be a framework, a code developed by an other team in a big project or a legacy jar that we don’t want to touch.

Imagine the following use cases (all code running on CDI 2)

  • I’m compiling in CDI 1.x and one of the Jar (framework for instance) already migrated to CDI 2.0 firing async event where it use to fire sync events. Without activation on the observer side, I have all the chance to see my observer break. And if I decide to upgrade to CDI 2.0 I must have a way to activate / deactivate async call on given observers

  • I’m compiling in CDI 2.0 but use jar1 in CDI 1.0 and jar2 in CDI 2.0 coming from other teams. jar2 and jar1 are old related pieces of code communicating the event. The guys in jar2 had time to migrate to CDI 2.0 and switch most fire() to fireAsync(). Observer in jar1 will be called asynchronously if the default is to have async activated for all observers.

These example looks like corner cases but the side effect will be that no framework developers will switch to fireAsync() for the sake of defensive programming. So async event would have a serious adoption problem withotu this double activation. More than that, as we are designing a Java EE specification we must be committed to backward compatibility and cannot change behavior of old code, like it would do if we chose to not have activation on observer side.

Other change, corrections and clarifications

You can check the release notes of this early draft to discover the more minor changes we also introduced in the spec.

Implementation and TCK

TCK team and JBoss Weld team are currently working hard to provide a Reference Implementation for this draft. You’ll be notified as soon as there’ll be released.

We need you

To go on on this Early draft, we really need your feedback. The review period will be launch in the coming days by the JCP and will run for 90 days. You can give your feedback in many way:

Thank you for helping us making CDI one of the best programming model for Java and Java EE.

CDI 2.0 - A glimpse at the future

Posted by Thorben Janssen on Feb 23, 2015 | Comments


Before we have a look at the changes in the upcoming CDI 2.0 specification, lets talk about where they come from. Did you know that they were provided by the community, so maybe by you?

Before the work on JSR 365 started, former expert group members, the expert group members of other specifications and the community were asked which changes they would like to see in CDI 2.0. 260 developers provided their feedback in the community survey. Based on these information, the 6 main topics were defined:

  • modularity,

  • enhancements of the event system,

  • improvements for interceptors and decorators,

  • CDI for Java SE,

  • usage of Java 8 features and

  • SPI and context enhancements.

The work on these topic is organized in 6 workshops, one for each main topic. This allows the members to focus their efforts and the group to work on several topics in parallel. The work of each workshop is tracked in a publicly available workshop document. You can find a reference to each document in the following paragraphs.

The 3.0.0.Alpha releases of Weld, the CDI reference implementation, provide prototype implementations for the discussed features. The goal is to create an early proof of concept and to give the community a chance to try the new features and to provide feedback.
But please be aware, that these releases should not be used for production. They are only prototypes and the following releases are likely to contain incompatible changes.

Main Topics for CDI 2.0

OK, enough banter for now. Lets have a more detailed look at the current status of work and some new features in the following subsection.


One of the main topics for CDI 2.0 is modularization. In general, no one likes to consume a huge and heavy spec, if only a small part of it is required for the job. To make CDI easier to consume, the plan is to split the specification into different parts that provide different subsets of it. A project or JSR could then decide which parts it likes to use and define its dependencies accordingly.

The work on this topic is still in a very early state and so far, there are just some ideas on how the specification shall be modularized. The documented suggestion of 5 different parts that depend on each other will most likely not be the final version.
The new idea is to split the specification into 3 parts: CDI full with Java EE support, CDI full and CDI light. CDI full with Java EE support will provide the full feature set of the specification. CDI full and CDI light will only provide a subset of it. The Java EE support will be missing in both of them. Additionally, the support for Contexts and AOP will be missing in CDI light. We will have to see, if this will be the final version.

These are the current ideas on how to create a modular CDI specification. If you like to get more details or follow future discussions on this topic, you can find the workshop document here.

Enhancements of the events system

The enhancement of the existing event mechanics seems to be in heavy demand of the community and is one of the bigger topics for CDI 2.0. The main features requested by the community were to support asynchronous events and to get a better control about events and event observers. There are several ideas that are discussed at the moment and the latest Weld 3.0.0 Alpha releases provided prototype implementations for some of them.

Lets have a look at two of the momentarily discussed features. And again, the work is still ongoing and everything can still change.

Ordering of events

One of the requested enhancements is an option to order the event observers. The currently agreed solution is to use an approach similar to the priority definition for interceptors. The @Priority annotation can be used to define the priority of an event observer. The observers will process the event in ascending order of their priority. A working prototype for this feature was released with Weld 3.0.0.Alpha1. You can find more information about it in the release announcement.

Asynchronous events:

Up to now, events in CDI were processed synchronously. There are some workarounds to trigger asynchronous processing, e.g. using asynchronous EJBs, but this was outside the CDI specification and shall be changed with CDI 2.0.
The Weld 3.0.0.Alpha3 release provides a working prototype, which adds the method fireAsync to the Event interface. The processing of an asynchronous event is similar to the processing of a synchronous one. The event object is mutable and thread-safe and the event observers will process the event in the defined order. You can read more about it in the release announcement of Weld 3.0.0.Alpha3.

You can get an overview about all discussed changes and ideas in the workshop document.

Improvements for interceptors and decorators

There are several enhancements to interceptors and decorators in CDI that are planned for CDI 2.0. Some of them are to support AOP on custom or produced beans, to support AOP on inner calls and to improve the interceptor chaining. The work on these topics has not started yet. But there are some small enhancements that were already implemented with Weld 3.0.0.Alpha1.
As Jozef Hartinger described in his release announcement, support for repeatable annotations was added for qualifiers and interceptor bindings. And the javax.interceptor.InvocationContext interface was extended to make it easier to access the interceptor binding in the interceptor.

You will find more information about it in the workshop document as soon as the work has started.

CDI for Java SE

CDI requires an up and running CDI container to process its components. This is usually no problem in an Java EE environment because the application server is taking care of the CDI container. But this is different in an Java SE environment, where the container has to be booted by the application. The main problem is, that the specification does not define an API to boot the container. Therefore Weld and Open Web Beans provide its own proprietary APIs to do it and Apache DeltaSpike offers an uniform API on top of that. Beginning with CDI 2.0 the start of the container shall be defined in the standard.

The work on this topic is still ongoing and there are several open questions that need to be answered in the upcoming discussions. You can read about it in the workshop document.

Usage of Java 8 features

Java 8 was released in March 2014 and is therefore not used by the Java EE 7 specifications which were released in 2013. This will change with Java EE 8 and this means that CDI 2.0 can also make use of the new features.
The discussions about the influence of the new Java features on CDI are still in an early state, but there are several JEPs that seem to be applicable to improve the specification. Some of them, like the CompletionStage API and repeating annotations, are already used in the proposals for asynchronous events and repeatable interceptor bindings. But the usage of the new Java 8 features will not be limited to the new CDI features, there will also be talks on how to improve the existing parts of the specification.
The current ideas can be found in this document.

SPI and context enhancements

The work on SPI changes has also not started yet. Some goals of the CDI 2.0 specification will be to improve the access to all meta data created by CDI and to provide a way to add beans at runtime. The requested changes to provide a better control about contexts, especially to activate and deactivate them, will also require some SPI enhancements.
An additional huge topic will be the changes caused by the adoption of Java 8 and how to keep the SPI binary backward compatible.
The changes will be described in the workshop document.


As described in the previous paragraphs, the work on the CDI 2.0 specification is ongoing and there are lots of things that need further discussions. An early draft of the specification, which will contain the most stable new features, shall be completed in Q1 of 2015. The public review shall start in Q3 of 2015 and provide feedback for the final release. The final version of the CDI 2.0 specification shall be released in Q1 of 2016.

CDI 2.0 first Face to face meeting feedback!

Posted by Antoine Sabot-Durand on Oct 20, 2014 | Comments

Last week we had the first CDI 2.0 Face to Face meeting in Brno (Czech Republic). Check what was discussed and the first CDI 2.0 orientations

Meeting Agenda

As you may know, CDI 2.0 project was launched only six weeks ago, so we are still in early discussion stage regarding CDI 2.0 design. Yet our workshop organisation was a good entry point to start going in more deep discussion. So we based our discussion on existing workshop documents. Here are the main decisions that came out from our discussion.

Parts introduction

Parts concept is not the most visible change we would introduce in CDI 2.0 but since it’s probably the one with more impact on spec organisation, we started with this point to know if we should go in that direction. That answer was yes. We also decided that each part would be independent from the other (i.e a bigger part wouldn’t depend from a smaller one but would integrate it) to solve API splitting issues. Having this principles accepted we talked about the possible parts and their content:

  • CDI Light: a lightweight version of CDI without Normal Scopes, Interceptors and Decorators that would allow proxy-free implementations. We worked on the API present in this Part, you can have a look to what we proposed on this branch

  • CDI Full: CDI as we know it today except for all the other spec integration (servlet, JSF, EJB, etc…​).

  • CDI Java EE : CDI full including integration with other specs

Events enhancement

The 2 main topics here were ordering and asynchronous events.

Asynchronous events.

The main idea was to adopt a different approach than the one in EJB today. Instead of using a @Asynchronous annotation and manage a Future<T> to deal with he end of asynchronous treatment, we looked for a way to provide callback to the event trigering.

The idea could be to add a fireAsync() method to the Event<T> and use Java 8 lambdas and add a functional interface like this :

public interface EventCallBack<T> {

    void doCallback(T callBack);

and use later like this

Event<Payload> evt;

public void fireAsyncWithCallBack() {

    evt.fireAsync(new Payload(), callBack -> System.out.println("Job done”));

Off course this approach has to be more deeply investigate (we’ll do it on our coming event meeting) but it has a lot of advantages :

  • Introduce a more modern approach of async events processing like we have in other framework or technologies

  • Complete the EJB approach instead of duplicating it

  • Avoid asking Java EE EG to extract @Asynchronous form EJB to put it somewhere else (where?)

Events priority

Discussion on event priority was open some weeks ago. We tried to have a fresh look to the idea. The main point was about using @Priority annotation or not. The question is still not closed but we’re more in favor of the use of a value in @Observes annotation. This value would give the order of the observer (the lowest being the first). The main reason to choose this approach instead of @Priority is the fact that while being part of java common annotation (JSR 250) spec, @Priority is not present in Java SE. So using it would :

  • force us to ask for JSR 250 Maintenance release to allow priority on paramaters

  • add an extra dependency jar (for only one annotation) when using CDI Light in Java SE which seems against our "light" goal

The @Observes evolution evolution would give something like:

public void firstObserver(@Observes(1) Payload pl) {}

public void secondObserver(@Observes(2) Payload pl) {}

Priority value provided in javax.interceptor.Interceptor.Priority would be duplicated in CDI to avoid useless dependency on Interceptor spec while keeping the same approach / values. This ordering could be also used to order step in extensions.

Event Range

The idea behind event range would to provide a "scope" to events (i.e package, war, ear). It would prepare CDI event to become a server wide eventing system. The discussion came to the conclusion that while it’s rather easy to implement, it’s usage could be quite cumbersome. The idea was not discarded but we thought it was a good idea to check with community if the need was real.

Interceptors and Decorators (AOP) enhancement

There were a lot of discussions around enhancing interceptors and decorators. You’ll find the main topics below.

AOP on custom beans and producers

Conclusion was that it is doable but with certain limitations. Among them the fact that an interceptor on producer would be applied on all method of it (no obvious solution to target specifc methods).

We also discussed the syntax for binding interceptor to a produced bean. if you consider this code:



public  Foo produceMap() {

    return new Foo();


@Loggable interceptor binding is bound to the method not the produced bean. We have to find an easy way to bind the interceptor to the produced bean. The only solution we found was to use a Stereotype with the interceptor binding and put it on the producer. Not a direct solution but rather elegant.

AOP on internal call vs self injection pattern

We already discussed about supporting AOP on call make in the same bean (calling intercepted B method from method A with interceptor triggering). After discussion, it seemed very difficult to introduce this new feature and AOP support on produced and custom beans at the same time. So the idea was to ease the use of self injection pattern, providing something like this.

public class MyBean {

  Self<MyBean> mySelf;

  public methodB() {

  public methodA() {

less elegant than having it directly on internal call but still useful.

Other AOP topics

We also discussed about the following topics:

  • relaunching the idea of supporting decorator without interface like it was requested in CDI-403 and before that in CDI-224.

  • standardise the partial bean feature from Deltaspike. For those who don’t know this feature an example can be found here.

Java SE support

We had a long discussion on Java SE support in CDI 2.0. To decide that we should just provide a class like this:

public class ContainerBoot {

     * Simple boot
    static BeanManager initialize() {

     * Boot with parameters
    static BeanManager intialize(Map<?,?>) {
    void shutdown() {}

Discussions are still going on on this topic.

SPI enhancement

Last but not least we also discussed about SPI enhancement. The main topic were:

  • Give the possibility to modify/register beans at runtime. The majority of present people were against this new feature. The ones in favor obtained that the door wouldn’t be closed now and that the community would be consulted to see if this need was "real". So we’ll be back on this feature and if you want to see it, stay tune to give it your support when we’ll ask for it.

  • Add SPI to activate/deactivate contexts. Right now built-in context cannot be activated / deactivated by third parties, forcing them to create their own implementation of such contexts instead of using the one provided by their implementation. This small modification will greatly ease CDI advanced integration in other spec or frameworks.

  • Add helpers to create CDI meta-data. Today it’s not very convenient to create an AnnotatedType or a custom Bean. We decided to explore the introduction of helpers inspired by Deltaspike Builders. They would be provided by lifecycle event


Here are the main topics we discussed during these 2 days. Other small feature will came to JIRA later. At this point there was only orientation and no final decision on any subject. So the door is still open for these as well as new feature. So don’t hesitate to give your advice andv your contribution to our workshop or Jira server.

Working method for CDI 2.0

Posted by Antoine Sabot-Durand on Oct 06, 2014 | Comments

Work on CDI 2.0 started at the beginning of september. As you may guess, specifying and releasing this new major version is a big challenge.

To put all chance on our side we are looking for a strong commitment from the community (as explained in our previous post). That’s why the way we’ll be organised is very important. Thus, when we started thinking about our working method we came up with the following requirements:

  • Keep the big picture of the spec in mind while working on all detail of each new / modified features

  • Have the right balance between "ideal specification" and the "specification only driven by implementation" approaches

  • Be able to welcome new contributors (even casual ones) without loosing them in spec history or advanced technical details at the beginning

  • Give visibility to third party (other JSR or future implementor) of the spec without forcing them to follow our ML, IRC, JIRA

  • Get feedback from the community easily while designing the spec

To satisfy these points we came to the idea of creating different workshop on big CDI topics (existing and new). To begin we identified these workshops:

  • Parts (modularity) : how we can make CDI more modular by extracting sub part in the spec to allow it to grow without becoming bloated

  • Java SE support : how CDI should work in Java SE and what SPI should we add or standardise to ease its integration in home brewed stacks

  • Events enhancement : bringing asynchronicity or ordering to events. Can it be extended to all Java EE

  • Interceptor & Decorator : AOP support on produced or custom bean. Work with interceptor spec to add AOP on inner call

  • SPI enhancement for integration : give access to all metadata produced by the container, give control of CDI from outside code, support Bean addition / modification @ Runtime

  • Contexts enhancement : go beyond the the thread-bound request-response model used by context today to support new application architecture

  • Java 8 enhancement : see how new features in java 8 (type annotation, annotation repetition, lambdas, streams, default methods, type inference…) could enhance CDI in existing and new features.

To ease this big picture approach we also adopted this following step to deal with each workshop:

  1. Blueprint draft : the workgroup lead propose a draft document describing his global idea of how the future should work

  2. Draft discussion The draft is commented, amended, enhanced by the group which can react to the doc by proposing new ideas. and When people feel ready by the EG

  3. Detailled task / requirement: after the discussion, each adopted concept are translated in on or more tickets in our Jira to follow their realisation to start more detailled discussion

  4. Spec and TCK enhancement: each task is translated to the new specification document and translated to the TCK

Of course these steps are more guidelines than a strong workflow, it’s a way to ease contribution not constraint it. It will probably evolve with time.

On our home page you’ll find the list of each workshop and their current status and links (working doc, Jira EPICS, etc…​). Please feel free to check these links and give your feedback and don’t heistate to contribute with your idea on this documents.

Tag Cloud