Reference implementations

[sst...@redhat.com]

At one point I put together a Weld SE based implementation of the MP config 1.0 spec as a base reference implementation. The code is sitting out here:

https://github.com/starksm64/microprofile-config/tree/seimpl

at the time I believed it was complete, but there were some issues trying to run an SE based container with the Arquillian WebArchive based tests in the config TCK that were causing failure due to classes in the WEB-INF/lib path not being added to the container. 

I think in general our specs should have a reference implementation section that points to reference implementations that people can build on and reuse to help simplify getting an implementation

[Mark Little]

We discussed this concept of reference implementations a while back and I think the conclusion was that there wouldn’t be an RI as people view them in Java EE, for instance, but a spec would have to call out implementations that conform to it when published. I’m sure someone can correct me if I’m wrong or point to the thread.

Mark.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/310eb45b-d8a2-4ca1-ab12-d43a13934a1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

---

Mark Little

mli...@redhat.com

JBoss, by Red Hat

Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

[Ondro Mihályi]

You're correct, Mark.

We generally agreed that there will be no RI owned by the MicroProfile project. However, it is encouraged to publish a list of implementations for every feature. An unresolved issue is where to publish the list so tha people can easily find it - see my other post about that.

For config, there is already a kind of reference implementation, which we used as a POC to run the TCK against during the development: https://github.com/struberg/javaConfig

It's just an unofficial toy project, but was adopted by Geronimo where it continues to be maintained as an Apache project.

I think it makes sense for each feature to adopt one or 2 simple implementations as a reference if they are a natural choice for getting started, and complement them with a (growing) list of other implementations. But it's perfectly OK if there is no single implementation chosen as a reference, providing only a list of all implementations (especially if there is no obvious one to choose as a reference).

In my view as a core contributor to the config feature, the only implementation that should be considered as reference is Mark Strubergs or eventually Geronimo's, which is a continuation of it. If some other implementation is used by the team during the development of the future feature versions, I'm happy to promote that one too. Otherwise, it's just yet another implementation and shouldn't be privileged. Just my opinion, others may be of a different opinion :)

--Ondro

[sst...@redhat.com]

The issue was not one of promotion of a particular implementation, rather it is about referencing implementations so that one can understand how the spec/API is supposed to work. It is a large gap between the JWTPrincipal API and making that work in a container for example. Similarly, there is a lot of boiler plate code in a Config API implementation that can be factored out into Java SE/Java EE based dependent base project which can help others with their implementations.

What I'm proposing is that every spec have a reference implementation section that calls out implementations of the specification by container type, including a Java SE/EE only section, so that one can know what a good starting point for them is based on their preferred container.

[John D. Ament]

Hmm nice and simple impl.

You probably ran into the problem I had run into when testing with Geronimo Config on Weld, Weld container wasn't handling resources in JARs when they were in a WAR.  i fixed that in Arquillian here

I'm not a fan of us having RIs.  It leads to a specific implementation becoming dominant.  It also means we need an RI of MicroProfile itself.  Granted, there's no tests yet for MP 1.0/1.1.

John

[Emily Jiang]

I agree with most of you. I don't want to adopt the concept of RI in MicroProfile.io. In WebSphere Liberty, we have an implementation of MicroProfile Config. It is nice to have multiple implementations but there is no RI. All of the implementations are in the same category.

Emily