MicroProfile Tcks

[Emily Jiang]

For MicroProfile tcks, some tests are only going to work in a JavaEE environment. One scenario is that when invoking a method asynchronously, in JavaEE environment, we need to make sure the security context etc is associated with the new thread. John confirmed this is not going to work in Hammock.

I know in JSR TCKs, there are web profile buckets and full profile buckets. Do we need to do some similar thing in MicroProfile? Have a special package for JavaEE specific tcks? Thoughts?

Emily

[John D. Ament]

Hi Emily,

First, big thank you for bringing this back on list!

I want to make sure I'm understanding properly.  When we talk about SecurityContext, are we talking about the EJB one or the JAX-RS one?

If it's the EJB one, then no, I don't believe we should support it since MP doesn't currently require EJB (and personally I would be a huge -1 to it).  If it's the JAX-RS one, my question would be where to propagate it to?

John

[Ken Finnigan]

I haven't had a chance to play with any of the TCKs at present, but it would concern me if they require a Java EE environment to function, as opposed to the pieces of MP that we've defined.

It would seem a bit odd if a TCK requires more than MP to do what it needs.

Ken

--
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+unsubscribe@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/e598c61b-6e33-4852-9172-37e38523ef22%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ondrej Mihályi]

I think that if we need something from JavaEE or specify how MP works together with it, it's a hint we need a new spec.

In this case, with FT and asynch calls, we probably need a spec that defines how new threads are created. Without such a spec, the FT should either remove the asynch feature for the time being or rely on an unspecified behavior, which would be specified later by another spec.

By the way, I'm in favor of a spec that covers threads, although I don’t like JavaEE concurrency utilities much, because they are more like a hack on top of single threaded model and they also don't work well with CDI.

But that's for another thread I guess. My main point os that TCK shouldn't rely on any part of JavaEE besides what's in MP. Any ambiguity of running an MP app in a JavaEE container should be covered by a specific spec.

--Ondro