Re: [DISCUSS] Move microprofile impl to Apache TomEE

[Romain Manni-Bucau]

hi Thomas,

commented inline


Le mar. 14 juin 2022 à 11:45, Thomas Andraschko 
a écrit :

> yep, we probably dont have enough commiters to maintain it
> but instead of freezing, shouldnt we maybe think about how to make it more
> attractive and easier to get more contributors?
> we have sooo many contributors in PrimeFaces as the project structure is
> easier, everything in one repo, and so on
>
> if you check how many repositories we have for MP implementations, API,
> homepage, ...
>

We actually did that > https://geronimo.apache.org/microprofile/


>
> i always wondered about the whole EE projects and locations/structures in
> apache in general
> why is geronimo the place for specs in general?
> i always thought that combining some repos/projects in general would make
> contributions much more welcome and easier
>

it is generally a 50-50, to sumarrize:

pro: single location
con: too much inconsistent things at the same place


>
>
> Wouldnt it be much more self-evident if we would have something like
> https://github.com/apache/ee-specifications?
> Wouldnt it be much more easier and more inviting if we would have all
> microprofile impls in one repo? The time we even safe for all that release
> trains
>

Was an option but people were not that homogeneous originally so dedicated
repos was more consistent with the actual work and avoided the "all in one"
pitfall that each contributor feels rejected due to a lot of work he does
not care about happening.


>
> and this is my perspective as long time committer here @apache - just
> think about how overhelming this is for new possible contributors
>

I think a big issue is that MP is mainly an implementation in its
communication (all vendors joined to have a single impl so there is no real
"spec" as EE was before) and that since they break quite often the *API*
people started to avoid it in apps after some time where it was embraced so
I'm not 100% sure even if I agree with the reasoning from a theory point of
view


>
>
>
>
> Am Di., 14. Juni 2022 um 11:04 Uhr schrieb Richard Zowalla <
> r...@apache.org>:
>
>> Hi,
>>
>> CC'ing dev@tomee here to ensure the discussion is seen.
>>
>> It is true, that TomEE moved to smallrye to update MP to 5.0 (jakarta)
>> due to a lack of contributors / resources to ramp up updated versions
>> in Geronimo.
>>
>> I have no strong opinion about switching the project umbrella as it
>> wouldn't change anything regarding contributions, I guess.
>>
>> Gruß
>> Richard
>>
>>
>> Am Dienstag, dem 14.06.2022 um 08:37 +0200 schrieb Romain Manni-Bucau:
>> > Hi all,
>> >
>> > TomEE people didn't send much feedback and I know they are moving to
>> > smallrye so can be great to know if we must continue this way or just
>> > freeze the projects there?
>> > Anyone able to comment?
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> >
>> >
>> > Le jeu. 9 juin 2022 à 11:32, Jean-Baptiste Onofré  a
>> > écrit :
>> > > OK, it sounds good to me then.
>> > >
>> > > Regards
>> > > JB
>> > >
>> > > On Thu, Jun 9, 2022 at 8:13 AM Romain Manni-Bucau <
>> > > rmannibu...@gmail.com> wrote:
>> > > >
>> > > > Hi
>> > > >
>> > > > Next step is likely to ask tomee since for now we just get the
>> > > consensus geronimo is a bad home for MP.
>> > > >
>> > > > If ok for them, I'd just move the project to tomee since, as
>> > > mentionned, we didnt work much on these projects and tomee was
>> > > driven last activity but guess it can be discussed on tomee thread
>> > > once created.
>> > > >
>> > > > Le jeu. 9 juin 2022 à 07:50, Jean-Baptiste Onofré <
>> > > j...@nanthrax.net> a écrit :
>> > > >>
>> > > >> +1, it makes sense to me.
>> > > >>
>> > > >> I guess we gonna do a vote. The question is about the
>> > > governance/PMC :
>> > > >> I do we plan to move PMC from Geronimo to Tomee or "just" use
>> > > Tomee
>> > > >> PMC ?
>> > > >>
>> > > >> Regards
>> > > >> JB
>> > > >>
>> > > >> On Mon, Jun 6, 2022 at 10:59 AM fpapon 
>> > > wrote:
>> > > >> >
>> > > >> > Hi all,
>> > > >> >
>> > > >> > I would like to start a thread to discuss about the future of
>> > > the Apache
>> > > >> > Geronimo Microprofile implementation:
>> > > >> >
>> > > >> > https://geronimo.apache.org/microprofile/
>> > > >> >
>> > > >> > As we can see, we don't have a lot of traction about the
>> > > maintenance of
>> > > >> > the implementation to be up-to-date with the Microprofile
>> > > specification.
>> > > >> >
>> > > >> > The J2EE Geronimo server is no longer exist and at Apache, the
>> > > active EE
>> > > >> > server seems to be Apache TomEE.
>> > > >> >
>> > > >> > May be it could make more sense to move the Microprofile
>> > > implementation
>> > > >> > to the Apache TomEE umbrella.
>> > > >> >
>> > > >> > WDYT?
>> > > >> >
>> > > >> > regards,
>> > > >> >
>> > > >> > --
>> > > >> > --
>> > > >> > François
>> > > >> >
>>
>>

Re: Jakarta Mail TCK - Additional Thoughts? (was: TomEE 9.x - from javax to jakarta namespace)

[Romain Manni-Bucau]

Hi,

Did you try handling LITERAL+ capability (1)? I don't think we do as of
today.

(1)
https://datatracker.ietf.org/doc/html/rfc7888#:~:text=LITERAL%2B%20allows%20the%20alternate%20form%20of%20literals%20(called%20%22non%2D,are%204096%20bytes%20or%20less
.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 31 mai 2022 à 09:54, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> a écrit :

> Hi,
>
> short update on this:
>
> Collaborated with JL and exchanged some ideas via Slack.
>
> We now tested James + Greenmail as mail servers to rule out any hard-
> coded TCK assumption regarding James. Both fail with the same exception
> / issue on the same TCK mail:
> https://github.com/eclipse-ee4j/mail-tck/blob/2.0.0/tests/mailboxes/test1/9
>
> The difference between the RI and our impl is basically the literal
> header:
>
> a5 APPEND test1 () "8-Dec-1996 15:30:12 +0100" {150432}
> a5 BAD APPEND failed. Illegal arguments.
>
> vs (RI):
>
> A6 APPEND test1 () "08-Dec-1996 15:30:12 +0100" {153113+}
> A6 OK [APPENDUID 466034631 1] APPEND completed.
>   Copied 1 messages
>
> I pushed a configured Jakarta Mail TCK 2.0.1 setup with updated
> instructions into this repository: https://github.com/rzo1/mail-tck
>
> In addition, I am CC'ing the geronimo list, in case some people there
> have additional ideas. Otherwise, we will need to take a dive into the
> imap spec / server-side impl to get any clues :)
>
> Gruß
> Richard
>
>
> Am Dienstag, dem 24.05.2022 um 19:46 + schrieb Zowalla, Richard:
> > Hi,
> >
> > I spend some more time on the mail tck and got some additional
> > insights:
> >
> > There is one specific mail from the TCK mailbox (test1, mail no. 9),
> > which breaks the current Geronimo mail impl. This happens, if you try
> > to bootstrap / setup the test mailbox before running the TCK
> > according
> > ti their documentation. The same procedere just works, if the
> > reference
> > impl is used.
> >
> > The failing tests in the mail tck report similar issues regarding
> > failed IMAP commands. Therefore, I assume, that the underlying issue
> > is
> > similar, i.e. if we solve that, we likely fix some of the TCK tests
> > too.
> >
> > I added some instructions to
> > https://issues.apache.org/jira/browse/GERONIMO-6835 to reproduce the
> > issue without actually running the TCK, so we might have the chance
> > to
> > debug it easily.
> >
> > Basically:
> >
> > - Checkout https://github.com/rzo1/geronimo-javamail/tree/tck-issues
> > - Follow the instructions in tck.adoc to start up a mail server
> > (docker-compose + docker exec)
> > - Run "fpopulate" with arguments "-s test1 -d
> > imap://user01%40james.local:1234@localhost:1143 -D" from within your
> > IDE
> > - Observe the debug output on the console
> >
> >
> > There is a difference between the message length between the RI and
> > the
> > Geronimo impl (as reported by the { } literal). This might be the
> > cause
> > (??), but I have no idea what is going on or why it is happening.
> >
> > Maybe someone has an idea what is going on here? Or has a pointer
> > where
> > to look at? I might be "lost in the tck madness" for today :)
> >
> > Gruß
> > Richard
> >
> >
> >
> > Am Dienstag, dem 24.05.2022 um 17:13 + schrieb Zowalla, Richard:
> > > To give a more detailed view / update from the spec tck party
> > > regarding
> > > activation and mail:
> > >
> > > (A) Geronimo Activation 2.0
> > >
> > > After a first milestone (M1) and some additional fixes after
> > > running
> > > the activation TCK [1] and related signatures tests, we are now
> > > passing
> > > them.
> > >
> > > JL prepared a release artifact (1.0.0), which is currently under
> > > vote.
> > >
> > > During the tck work, we found some inconsistency / unspecified
> > > behaviour of "normalizeMimeTypeParameter" of ActivationDataFlavor.
> > > While this method is tested in the TCK on the basis of the
> > > reference
> > > implementation neither the spec itself nor the javadoc are really
> > > clear
> >

Re: ValidationParser fails to parse Jakarta XML configuration files.

[Romain Manni-Bucau]

If not crazy can be great to avoid to need to rereleasz just for that else
ok for me.

Le mer. 6 avr. 2022 à 21:48, Jean-Louis Monteiro 
a écrit :

> Hi,
>
> while working on the TomEE TCK, I realized BVal was not supporting XML
> configuration because of the way we handle XML Namespaces.
>
> We do have a Filter to override the namespace if it does not match what we
> expect, but there was a bug in the logic, so the namespace was only
> overridden for the root element, but our package-info.java is different
> from jakarta namespace.
>
> Long story short, I created an issue and I'm about to push the fix for it.
> https://issues.apache.org/jira/browse/BVAL-216
>
> I went ahead and slightly updated the TCK module locally to see if we can
> also pass the Jakarta Validation 3.0 TCK.
>
> Aside from 2 failures for the test class
> GenericAndCrossParameterConstraintTest. We do pass them all. It's been
> added in 3.0, so it might be something we haven't implemented yet.
>
> I can address it later or in the next big bang version unless someone can
> have a look.
> Created BVal-217 to track it.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Re: TomEE MicroProfile and Jakarta

[Romain Manni-Bucau]

The risk for TomEE (IMHO indeed) is that, using smallrye, you break the
core value "apache" or at least "owned by apache" and break the other core
value "lightweight" since it comes with a tons of uneeded stuff and
implementation is not even JAXRS friendly (it breaks literally jaxrs and
cdi at multiple levels) so it can mean contributing to smallrye which means
at the end asking mircoprofile to not be a spec but just an implementation
and TomEE to stick to a dedicated MP distro (not in all others) to not kill
itself - not saying it does not makes sense but it is what it means
concretely.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 31 mars 2022 à 21:36, David Blevins  a
écrit :

> It would be great to see us have compliant MicroProfile implementations
> somewhere in Apache; Geronimo, TomEE, CXF.  It's still my personal
> preference --  It makes very little sense to go through the effort to
> create a spec and tck to enable multiple implementations that can
> compete/innovate and then wind up with just one implementation in the
> industry.
>
> That said, from a TomEE perspective we're struggling to keep up with all
> specs, Jakarta EE and MicroProfile.  Part of that is we do try to uniquely
> implement specs, while everyone else just uses the exact same
> implementation.  We're not really playing the same game.  We would need
> more resources than the competition to compete in the way we have been
> attempting.  However, because we're behind, we end up with fewer resources
> and larger gaps between implementations and over time our goals becomes
> harder, not easier.
>
> I wonder if we should switch to the SmallRye implementations where
> needed.  Not because we've given up hope of having Apache implementations,
> but because if we assume our desire to do the implementation work here is a
> constant and we know the time to get there will some number of months and
> that will likely be after complete our Jakarta EE spec work, which is also
> some number of months... we're basically talking sometime 2023.  The
> question then becomes, how do we want to spend our time till then?  Do we
> want to spend it in a compliant state or a non-compliant state?
>
> If we spend the next year and change in a compliant state, using the
> SmallRye impls where needed until we've created compliant Apache versions,
> then we are competitive and will gain resources.  The date on which we
> would have resources to create those Apache implementations would likely be
> sooner.  If we spend the next year and change still not in a compliant
> state (as we've been since 2020), then we'l continue to take a resource hit
> and the date on which we would have resources to create those Apache
> implementations would likely be later.  There are also other risks with
> this approach.
>
> So though it may seem backwards my gut says, unless we get a dramatic
> influx of resources from nowhere, we should use SmallRye where we need
> until we have the time to dedicate to the Apache implementations.
>
>
> -David
>
>
> > On Mar 31, 2022, at 12:44 AM, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> >
> > Hi,
> >
> > Small update regarding jakarta namespace switch and MicroProfile. Adding
> > Geronimo dev@list because we are using most of the Geronimo
> implementations
> >
> > In order to migrate, we have created a shaded version of all MicroProfile
> > APIs to relocate all javax to jakarta. It worked but it's causing some
> > issues with TCK. They are not relocated so of course, all TCK are
> failing.
> >
> > I wanted to see how far we are regarding our implementations, so I went
> > ahead and updated all TCK to the latest version (and compatible with the
> > Jakarta namespace).
> >
> > The other option would be to grab all the TCK and create their equivalent
> > in jakarta namespace using the same approach as for the APIs.
> >
> > What are your thoughts?
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
>
>

Re: TomEE MicroProfile and Jakarta

[Romain Manni-Bucau]

Hi JL,

Think we - as a vendor - shouldn't relocate or create any TCK flavor. AFAIK
Microprofile did migrate their last version to jakarta so they should have
some TCK somewhere - we can use snapshots in a profile for ex.
AFAIK we have some road to upgrade to last versions but it also broke
dramatically backward compatibility for end users - from my user side this
is one of the reason making microprofile > 1.0 (ie pure EE) abandonned - so
not sure how we want to tackle that since breaking for no real new feature
is not great for a community but if we want to maintain some impl we'll
have to go that way at some point anyway, ideas welcomed.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 31 mars 2022 à 09:51, Jean-Louis Monteiro 
a écrit :

> Hi,
>
> Small update regarding jakarta namespace switch and MicroProfile. Adding
> Geronimo dev@list because we are using most of the Geronimo
> implementations
>
> In order to migrate, we have created a shaded version of all MicroProfile
> APIs to relocate all javax to jakarta. It worked but it's causing some
> issues with TCK. They are not relocated so of course, all TCK are failing.
>
> I wanted to see how far we are regarding our implementations, so I went
> ahead and updated all TCK to the latest version (and compatible with the
> Jakarta namespace).
>
> The other option would be to grab all the TCK and create their equivalent
> in jakarta namespace using the same approach as for the APIs.
>
> What are your thoughts?
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Re: JSON Pointer/Patch issue with /-

[Romain Manni-Bucau]

Let say it enables more control whereas this kind of toggle system
properties can be random when apps don't need the same (once again it is
functional and not about perf there).
Feel free to take back my PR, was just sharing the idea with code to try to
fix it together faster.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 2 déc. 2020 à 15:30, Jean-Louis MONTEIRO  a
écrit :

> Hey Romain,
>
> Your email was clear on how to do it. But thanks for creating the PR.
> To be honest, I don't really care if you prefer this way. Essentially,
> instead of adding a property into a file, I'll now add a Maven dependency
> into my pom file.
>
> Does not change much.
> If on the other hand, it makes OSGi deployments easier, I'm fine with it. I
> just need some updates in your PR if I may.
>
> Le mer. 2 déc. 2020 à 13:13, Romain Manni-Bucau  a
> écrit :
>
> > Send a PR with the "SPI" option which enables to have this toggle *at
> will*
> > and drop it when not desired anymore without any config.
> > Hope it illustrates better than words one toggle option which
> > wouldnt depend on the env.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 2 déc. 2020 à 11:49, Jean-Louis MONTEIRO  a
> > écrit :
> >
> > > I understand it's a nice feature and the RFC does not address it.
> > > What I'm not happy with is that adding this feature breaks what's
> > actually
> > > in the spec.
> > >
> > > I would prefer us to implement this feature without breaking standard
> > > features.
> > > I'll push a proposal for now and we can improve.
> > >
> > >
> > >
> > >
> > > Le mar. 1 déc. 2020 à 15:13, Romain Manni-Bucau  >
> > a
> > > écrit :
> > >
> > > > Le mar. 1 déc. 2020 à 14:40, Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> a écrit :
> > > >
> > > > > I'll address a few points inline below, but at a high level, what
> are
> > > we
> > > > > looking to achieve from a spec/tck challenge?
> > > > >
> > > > > I can see a case for some clarification and updates to the Javadoc.
> > > > >
> > > > > The assertions that /- will return an error (as that references an
> > > index
> > > > to
> > > > > append to after the *end* of an array - i.e. array.length) are
> tested
> > > in
> > > > > the TCK, and other implementations must be passing that TCK. It's
> > hard
> > > to
> > > > > see a spec change happening, as there is no spec document beyond
> the
> > > RFCs
> > > > > that I can find. A TCK change that would enable Johnzon to pass,
> and
> > > > > require other currently passing implementations to make a change
> > seems
> > > > > unlikely. Jakarta EE 8's TCK has been around a while and has
> > > > > implementations that pass. The Jakarta EE 9 TCK is basically "done"
> > and
> > > > is
> > > > > essentially the same as EE8, bar the namespace change. I guess
> > adding a
> > > > > test exclude is possible, but serves to make this more vague and
> > vendor
> > > > > dependent (and non-portable) which feels like it defeats the
> purpose
> > -
> > > > > surely having it better defined and tested is the way to go.
> > > > >
> > > >
> > > > Well, here the fact is that it does not impact other vendors since it
> > is
> > > a
> > > > johnzon vendor specific feature we put in a shadow of the
> > (javax/jakarta)
> > > > spec handling in a custom fashion an error case.
> > > > Typically the case where we can exclude the TCK since it is
> irrelevant
> > > for
> > > 

Re: JSON Pointer/Patch issue with /-

[Romain Manni-Bucau]

Send a PR with the "SPI" option which enables to have this toggle *at will*
and drop it when not desired anymore without any config.
Hope it illustrates better than words one toggle option which
wouldnt depend on the env.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 2 déc. 2020 à 11:49, Jean-Louis MONTEIRO  a
écrit :

> I understand it's a nice feature and the RFC does not address it.
> What I'm not happy with is that adding this feature breaks what's actually
> in the spec.
>
> I would prefer us to implement this feature without breaking standard
> features.
> I'll push a proposal for now and we can improve.
>
>
>
>
> Le mar. 1 déc. 2020 à 15:13, Romain Manni-Bucau  a
> écrit :
>
> > Le mar. 1 déc. 2020 à 14:40, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> a écrit :
> >
> > > I'll address a few points inline below, but at a high level, what are
> we
> > > looking to achieve from a spec/tck challenge?
> > >
> > > I can see a case for some clarification and updates to the Javadoc.
> > >
> > > The assertions that /- will return an error (as that references an
> index
> > to
> > > append to after the *end* of an array - i.e. array.length) are tested
> in
> > > the TCK, and other implementations must be passing that TCK. It's hard
> to
> > > see a spec change happening, as there is no spec document beyond the
> RFCs
> > > that I can find. A TCK change that would enable Johnzon to pass, and
> > > require other currently passing implementations to make a change seems
> > > unlikely. Jakarta EE 8's TCK has been around a while and has
> > > implementations that pass. The Jakarta EE 9 TCK is basically "done" and
> > is
> > > essentially the same as EE8, bar the namespace change. I guess adding a
> > > test exclude is possible, but serves to make this more vague and vendor
> > > dependent (and non-portable) which feels like it defeats the purpose -
> > > surely having it better defined and tested is the way to go.
> > >
> >
> > Well, here the fact is that it does not impact other vendors since it is
> a
> > johnzon vendor specific feature we put in a shadow of the (javax/jakarta)
> > spec handling in a custom fashion an error case.
> > Typically the case where we can exclude the TCK since it is irrelevant
> for
> > our impl but I understand also it is not perfect.
> >
> >
> > >
> > > I appreciate that this introduces a backwards incompatible change, and
> > that
> > > there may be other consumers of the library that would have an issue if
> > > this just changed. This seems like a fairly straightforward case that
> > could
> > > be easily and quickly solved with a feature switch, and passing the TCK
> > is
> > > a worthwhile goal, both for Johnzon and TomEE. I suspect the TCK
> > challenge
> > > will take a bit of time, and we'll likely end up back at the feature
> > switch
> > > anyway.
> > >
> >
> > Issue is we dont have a Json.createPointerFactory(mapWithToggle) so it
> is a
> > global flag which means it breaks some deployments anyway - at least at
> > tomee level - when > 1 app is deployed (or >= 1 app + 1 extension).
> >
> >
> > >
> > > On Fri, Nov 27, 2020 at 10:44 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi JL,
> > > >
> > > > As discussed together - but sharing for others - we must take into
> > > account
> > > > some points:
> > > >
> > > > 1. reading both spec, JSON-Patch enables to handle /- as your first
> did
> > > (ie
> > > > consider it is last element). JSON-Patch uses JSON-Pointer but
> nowhere
> > it
> > > > is written it behaves as JSON-Pointer in all cases and it is
> typically
> > > > "integration" definition which can extend an underlying spec
> (otherwise
> > > > most of EE wouldn't be right? ;))
> > > >
> > >
> > > I think the idea is that it references a non-existent element, *after*
> > the
> > > last element in an array. So if you have an array [0, 1, 2,

Re: JSON Pointer/Patch issue with /-

[Romain Manni-Bucau]

Le mar. 1 déc. 2020 à 14:40, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> I'll address a few points inline below, but at a high level, what are we
> looking to achieve from a spec/tck challenge?
>
> I can see a case for some clarification and updates to the Javadoc.
>
> The assertions that /- will return an error (as that references an index to
> append to after the *end* of an array - i.e. array.length) are tested in
> the TCK, and other implementations must be passing that TCK. It's hard to
> see a spec change happening, as there is no spec document beyond the RFCs
> that I can find. A TCK change that would enable Johnzon to pass, and
> require other currently passing implementations to make a change seems
> unlikely. Jakarta EE 8's TCK has been around a while and has
> implementations that pass. The Jakarta EE 9 TCK is basically "done" and is
> essentially the same as EE8, bar the namespace change. I guess adding a
> test exclude is possible, but serves to make this more vague and vendor
> dependent (and non-portable) which feels like it defeats the purpose -
> surely having it better defined and tested is the way to go.
>

Well, here the fact is that it does not impact other vendors since it is a
johnzon vendor specific feature we put in a shadow of the (javax/jakarta)
spec handling in a custom fashion an error case.
Typically the case where we can exclude the TCK since it is irrelevant for
our impl but I understand also it is not perfect.


>
> I appreciate that this introduces a backwards incompatible change, and that
> there may be other consumers of the library that would have an issue if
> this just changed. This seems like a fairly straightforward case that could
> be easily and quickly solved with a feature switch, and passing the TCK is
> a worthwhile goal, both for Johnzon and TomEE. I suspect the TCK challenge
> will take a bit of time, and we'll likely end up back at the feature switch
> anyway.
>

Issue is we dont have a Json.createPointerFactory(mapWithToggle) so it is a
global flag which means it breaks some deployments anyway - at least at
tomee level - when > 1 app is deployed (or >= 1 app + 1 extension).


>
> On Fri, Nov 27, 2020 at 10:44 AM Romain Manni-Bucau  >
> wrote:
>
> > Hi JL,
> >
> > As discussed together - but sharing for others - we must take into
> account
> > some points:
> >
> > 1. reading both spec, JSON-Patch enables to handle /- as your first did
> (ie
> > consider it is last element). JSON-Patch uses JSON-Pointer but nowhere it
> > is written it behaves as JSON-Pointer in all cases and it is typically
> > "integration" definition which can extend an underlying spec (otherwise
> > most of EE wouldn't be right? ;))
> >
>
> I think the idea is that it references a non-existent element, *after* the
> last element in an array. So if you have an array [0, 1, 2, 3, 4], then
> "/-" would reference element _5_ (assuming you start your numbering at 0),
> and not the last element in the array (index 4).
>

This is the jsonpointer spec right,  but JSONPatch never requires to not
handle the case as we do, it is just not written (and why we used it also).
Issue on jsonpointer side being we can't have another character which means
"last element".


>
>
> > 2. On johnzon point of view we can't break this feature which was
> requested
> > by user and transitive users (ie user of products built with johnzon)
> > without at least a clear migration path so if we want to break we should
> do
> > a 1.3 (dont think we need a 1.2 maintenance branch, we can do it lazily),
> > document how to migrate from current behavior to new one (i'll detail it
> > after) and communicate on it on our website properly (index.html ref and
> > dedicated page I guess with the release annoucement). Alternative is to
> > challenge the TCK, it is a failure case so it is typically the kind of
> case
> > we can plug custom/vendor behavior (we do in other parts of the JSON-B
> spec
> > for ex). Overall idea is to not let users on the road because some TCK
> > exist (functional and users over procedural work).
> >
>
> I'd be interested in the history, it helps to be mindful of it when making
> changes.
>

Goal is to be able to work on the last element, there is nothing in specs
about this one but it is very common to need that (see it as "length"
operator).
Indeed we can enrich jsonlogic module to cover that case but most users
just bring jsonp+jsonb and not johnzon-jsonlogic.


>
>
> >
> > On strict TCK side, we can also do a johnzon-tck module where we wrap the
> > provider to handle that case and pass the TCK, this is 

Re: JSON Pointer/Patch issue with /-

[Romain Manni-Bucau]

Hi JL,

As discussed together - but sharing for others - we must take into account
some points:

1. reading both spec, JSON-Patch enables to handle /- as your first did (ie
consider it is last element). JSON-Patch uses JSON-Pointer but nowhere it
is written it behaves as JSON-Pointer in all cases and it is typically
"integration" definition which can extend an underlying spec (otherwise
most of EE wouldn't be right? ;))
2. On johnzon point of view we can't break this feature which was requested
by user and transitive users (ie user of products built with johnzon)
without at least a clear migration path so if we want to break we should do
a 1.3 (dont think we need a 1.2 maintenance branch, we can do it lazily),
document how to migrate from current behavior to new one (i'll detail it
after) and communicate on it on our website properly (index.html ref and
dedicated page I guess with the release annoucement). Alternative is to
challenge the TCK, it is a failure case so it is typically the kind of case
we can plug custom/vendor behavior (we do in other parts of the JSON-B spec
for ex). Overall idea is to not let users on the road because some TCK
exist (functional and users over procedural work).

On strict TCK side, we can also do a johnzon-tck module where we wrap the
provider to handle that case and pass the TCK, this is purely technical to
be compliant but would avoid to break anything.
Now if we really want to be strict in our implementation we must still
enable this last element case. One option not far from what we have is to
use our json-logic module and add some jsonpatch operators. Combining
multiple operators we can manage to fulfill this common patching need - but
we break the overall API + require a new module to be added to apps).

Lastly I would note that JSON Pointer *enables* our impl:

> Note that the use of the "-" character to index an array will always

   result in such an error condition because by definition it refers to
   a nonexistent array element.  Thus, applications of JSON Pointer need
   to specify how that character is to be handled, if it is to be
   useful.


>  For example, some applications might stop pointer processing upon an

   error, while others may attempt to recover from missing values by
   inserting default ones.


Literally means "this is a case we consider as an error but your
application can recover from it" and we do ;).

Since it is an error case I would start by challenging the TCK to make it
vendor dependent and exclude it from the passing list for now.
If really blocking we can go with plan B and try to have a migration path
but it sounds like a lot of effort for everyone for literally 0 gain IMHO.

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 27 nov. 2020 à 10:59, Jean-Louis Monteiro 
a écrit :

> Hi,
>
> I was working to pass the TCK with Johnzon, but I have failures around the
> usage of "/-" in arrays.
>
> From JSON Pointer RCF https://tools.ietf.org/html/rfc6901
>
> > If the currently referenced value is a JSON array, the reference
> >   token MUST contain either:
> >
> >   *  characters comprised of digits (see ABNF below; note that
> >  leading zeros are not allowed) that represent an unsigned
> >  base-10 integer value, making the new referenced value the
> >  array element with the zero-based index identified by the
> >  token, or
> >
> >   *  exactly the single character "-", making the new referenced
> >  value the (nonexistent) member after the last array element.
> >
> >
> And then
>
> > Note that the use of the "-" character to index an array will always
> >result in such an error condition because by definition it refers to
> >a nonexistent array element.  Thus, applications of JSON Pointer need
> >to specify how that character is to be handled, if it is to be
> >useful.
> >
> >
> When I opened https://issues.apache.org/jira/browse/JOHNZON-325
> I first fixed with
>
> https://github.com/apache/johnzon/pull/68/commits/3ef4fb80bdaf6010d4ad66c481675b70bc1e4bca
>
> And we were 100% JSONP compliant but as you can see in the commit, I had
> to @Ignore some junit tests because they did not make sense.
>
> After talking with Romain, he mentioned some improvements to attempt to be
> backward compatible and still support the previous behavior.
> See commit
>
> https://git

Re: WebApplicationExceptionMapper not being called

[Romain Manni-Bucau]

Hi Ivan

You can set it with a cxf interceptor or even jaxrs filter but looks like a
bug, at least the default. Default should be true only if there is no
custom mapper, not if there is any registered mapper matching and this is
known at deploy time. Guess you should open a ticket.

Le mer. 25 déc. 2019 à 15:32, Ivan Junckes Filho  a
écrit :

> It seems the issue is with:
> wae.spec.optimization property, it needs to be false or it
> webapplicationexception  will be skipped.
>
> But I can't find the way to set it to false. Property is part of
> org.apache.cxf.message.Message.
>
> Anyone can help? system.properties didn't work.
>
> On Wed, Dec 25, 2019 at 10:23 AM Ivan Junckes Filho  >
> wrote:
>
> > Hello guys, I am trying to log the exception thrown by
> > WebApplicationExceptionMapper but the exception mapper is never called.
> >
> > Instead of calling it tomee calls ExceptionUtils.convertFaultToResponse.
> > Even writing a new default exception mapper doesn't work. Anyone knows
> how
> > can I print the exception of WebApplicationException? It can be using the
> > mapper or not.
> >
> > public static  Response convertFaultToResponse(T
> ex, Message currentMessage) {
> > if (ex == null || currentMessage == null) {
> > return null;
> > }e
> > Message inMessage = currentMessage.getExchange().getInMessage();
> > Response response = null;
> > if (ex instanceof WebApplicationException) {
> > WebApplicationException webEx = (WebApplicationException)ex;
> > if (webEx.getResponse().hasEntity()
> > && webEx.getCause() == null
> > && MessageUtils.getContextualBoolean(inMessage,
> SUPPORT_WAE_SPEC_OPTIMIZATION, true)) {
> > response = webEx.getResponse();
> > }
> > }
> >
> > if (response == null) {
> > ExceptionMapper  mapper =
> >
>  
> ServerProviderFactory.getInstance(inMessage).createExceptionMapper(ex.getClass(),
> inMessage);
> > if (mapper != null) {
> > try {
> > response = mapper.toResponse(ex);
> > } catch (Throwable mapperEx) {
> >
>  inMessage.getExchange().put(JAXRSUtils.EXCEPTION_FROM_MAPPER, "true");
> > mapperEx.printStackTrace();
> > return Response.serverError().build();
> > }
> > }
> > }
> > if (response == null) {
> > Throwable unwrappedException = ex.getCause();
> > if (unwrappedException instanceof WebApplicationException) {
> > WebApplicationException webEx =
> (WebApplicationException)unwrappedException;
> > response = webEx.getResponse();
> > }
> > }
> > JAXRSUtils.setMessageContentType(currentMessage, response);
> > return response;
> > }
> >
> >
>

Re: Implementing MicroProfile 3.0

[Romain Manni-Bucau]

Awesome JL.

Do you have some details about the breaking changes?


Le mar. 24 sept. 2019 à 03:51, Jean-Louis Monteiro 
a écrit :

> All right, created this one for health
> https://issues.apache.org/jira/browse/GERONIMO-6752
> I have a fix for a bug in the way we handle producer
> https://issues.apache.org/jira/browse/GERONIMO-6753
>
> Since we upgraded to health 2.0 and there are some breaking changes, I
> have bumped up the version to 2.0.0-SNAPSHOT.
>
> I don't have the carma to change JIRA and update the version accordingly
> so I have assigned the issues to version Health_1.0.3
> <https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12346154>
>
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Sun, Sep 22, 2019 at 11:00 PM Romain Manni-Bucau 
> wrote:
>
>> Hi JL
>>
>> AFAIK the missing impl are mainly fault tolerance 2 (which adds
>> completionstage support we already have), opentracing 1.3 (which is sadly
>> just minor fixes compared to others and no opentracing upgrade IIRC), and
>> metrics 2 (which mainly split counters in 2 entities). Other specs are
>> ready I think.
>>
>> Do you have different inputs or challenges?
>>
>> The main challenge we are facing as an implementer is to limit user
>> impacts
>> if possible (we dont want to force users to rewrite their app each year so
>> we mitigate it when not made too hard by microprofile).
>>
>>
>> Le lun. 23 sept. 2019 à 02:00, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> a écrit :
>>
>> > Hi,
>> >
>> > I have created a branch named TOMEE-2689_MicroProfile3.0 where I have
>> > upgraded all API's (and therefor TCK) in order to match MicroProfile
>> 3.0.
>> >
>> > Here is the diff
>> >
>> >
>> https://gitbox.apache.org/repos/asf?p=tomee.git;a=commitdiff;h=83812d23512b2ab269435d21962f14202f281912;hp=66230480e1858fed3174c25fa33de58ee93872fe
>> >
>> > Obviously, the TCKs aren't passing anymore because we would need to
>> > upgrade some of our code.
>> >
>> > There is metrics, opentracing, health, rest-client and openapi to
>> > implement or upgrade.
>> >
>> > I'll be starting but I would take any help.
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>>
>

Re: Implementing MicroProfile 3.0

[Romain Manni-Bucau]

Hi JL

AFAIK the missing impl are mainly fault tolerance 2 (which adds
completionstage support we already have), opentracing 1.3 (which is sadly
just minor fixes compared to others and no opentracing upgrade IIRC), and
metrics 2 (which mainly split counters in 2 entities). Other specs are
ready I think.

Do you have different inputs or challenges?

The main challenge we are facing as an implementer is to limit user impacts
if possible (we dont want to force users to rewrite their app each year so
we mitigate it when not made too hard by microprofile).


Le lun. 23 sept. 2019 à 02:00, Jean-Louis Monteiro 
a écrit :

> Hi,
>
> I have created a branch named TOMEE-2689_MicroProfile3.0 where I have
> upgraded all API's (and therefor TCK) in order to match MicroProfile 3.0.
>
> Here is the diff
>
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=commitdiff;h=83812d23512b2ab269435d21962f14202f281912;hp=66230480e1858fed3174c25fa33de58ee93872fe
>
> Obviously, the TCKs aren't passing anymore because we would need to
> upgrade some of our code.
>
> There is metrics, opentracing, health, rest-client and openapi to
> implement or upgrade.
>
> I'll be starting but I would take any help.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Re: Johnzon release

[Romain Manni-Bucau]

As mentionned on the related thread 1.2.0, master is ready normally

Le mer. 11 sept. 2019 à 18:18, Jean-Louis Monteiro 
a écrit :

> Now that the JSONB spec jar is released, I  pushed the changes to move to
> non snapshot dependencies.
>
> Question guys: are the changes for passing TCK small so we do a 1.1.14 or
> do we consider they are significant enough to produce a 1.2 instead?
>
> thoughts?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Mon, Sep 9, 2019 at 12:05 PM Romain Manni-Bucau 
> wrote:
>
> > As mentionned in the related thread ("JSON-B and JSON-P TCKs") it sounds
> ok
> > for me.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 9 sept. 2019 à 11:57, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com>
> > a écrit :
> >
> > > Hi,
> > >
> > > Romain and Mark have done a great work with the TCK. I'd like to open
> up
> > a
> > > vote to get a release out and fill a certification request like this
> one
> > >
> > > https://github.com/eclipse-ee4j/jsonb-api/issues/175
> > >
> > > Any problem?
> > >
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> >
>

Re: Johnzon release

[Romain Manni-Bucau]

As mentionned in the related thread ("JSON-B and JSON-P TCKs") it sounds ok
for me.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 9 sept. 2019 à 11:57, Jean-Louis Monteiro 
a écrit :

> Hi,
>
> Romain and Mark have done a great work with the TCK. I'd like to open up a
> vote to get a release out and fill a certification request like this one
>
> https://github.com/eclipse-ee4j/jsonb-api/issues/175
>
> Any problem?
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

We cant, only impl+api are certified so no issue ;)

Le mer. 4 sept. 2019 à 17:01, Jean-Louis Monteiro 
a écrit :

> I'd like to certify some of them if possible of course.
>
> Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau 
> a écrit :
>
>> Not sure I'm following Mark, EPL is fine for us (
>> https://www.apache.org/legal/resolved.html) and G spec jars are not
>> officially certified so don't change of license anytime.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mer. 4 sept. 2019 à 15:07, Mark Struberg  a écrit :
>>
>> > No, before that it was CDDL+GPL. It just moved to EPL, which is also
>> CatB
>> >
>> > LieGrue,
>> > strub
>> >
>> > > Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com
>> > >:
>> > >
>> > > @Mark: didn't change with jakarta donation? can you open a ticket on
>> > > jakartee tracker please?
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > > <https://rmannibucau.metawerx.net/> | Old Blog
>> > > <http://rmannibucau.wordpress.com> | Github <
>> > https://github.com/rmannibucau> |
>> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > <
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >
>> > >
>> > >
>> > > Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a
>> écrit
>> > :
>> > >
>> > >> No, this is an intended situation.
>> > >> When one fully passes the TCK then you get the EFSL. This 'removes'
>> the
>> > >> copyleft nature of the EPL.
>> > >> The details are quite nested in the legal papers, but that's it
>> > basically.
>> > >>
>> > >> If we just upgrade our existing API to be binary compat then we have
>> no
>> > IP
>> > >> issues.
>> > >>
>> > >> LieGrue,
>> > >> strub
>> > >>
>> > >>
>> > >>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau <
>> > rmannibu...@gmail.com
>> > >>> :
>> > >>>
>> > >>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the
>> ambiguity
>> > >> for us.
>> > >>> That said it is good to reuse the same GAV for end users so we might
>> > ask
>> > >> jakarta to double license its api jars?
>> > >>>
>> > >>> Romain Manni-Bucau
>> > >>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> > >>>
>> > >>>
>> > >>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
>> > >> jlmonte...@tomitribe.com> a écrit :
>> > >>> Yep that was the point.
>> > >>> So I was asking if we should do the same yes or not.
>> > >>>
>> > >>> That seems to be your opinion Romain.
>> > >>> Mark on the other end is having some doubts about the license.
>> > >>> --
>> > >>> Jean-Louis Monteiro
>> > >>> http://twitter.com/jlouismonteiro
>> > >>> http://www.tomitribe.com
>> > >>>
>> > >>>
>> > >>> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <
>> > rmannibu...@gmail.com>
>> > >> wrote:
>> > >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> > >> jlmonte...@tomitribe.com>
>> > >>> a écrit :
>> > >>>
>> > >>>> Thanks Romain. I'm fine with using Eclipse jars if from a legal
>> point
>> > >> of
>> > >>>> view, it works.
>> > >>>> Otherwise, I'd like to split our spec jars.
>> > >>>>
>> > >>>> What about MicroProfile?
>> > >>>>
>> > >>>
>> > >>> We already agre

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

Not sure I'm following Mark, EPL is fine for us (
https://www.apache.org/legal/resolved.html) and G spec jars are not
officially certified so don't change of license anytime.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 4 sept. 2019 à 15:07, Mark Struberg  a écrit :

> No, before that it was CDDL+GPL. It just moved to EPL, which is also CatB
>
> LieGrue,
> strub
>
> > Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau  >:
> >
> > @Mark: didn't change with jakarta donation? can you open a ticket on
> > jakartee tracker please?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a écrit
> :
> >
> >> No, this is an intended situation.
> >> When one fully passes the TCK then you get the EFSL. This 'removes' the
> >> copyleft nature of the EPL.
> >> The details are quite nested in the legal papers, but that's it
> basically.
> >>
> >> If we just upgrade our existing API to be binary compat then we have no
> IP
> >> issues.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity
> >> for us.
> >>> That said it is good to reuse the same GAV for end users so we might
> ask
> >> jakarta to double license its api jars?
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >>>
> >>>
> >>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com> a écrit :
> >>> Yep that was the point.
> >>> So I was asking if we should do the same yes or not.
> >>>
> >>> That seems to be your opinion Romain.
> >>> Mark on the other end is having some doubts about the license.
> >>> --
> >>> Jean-Louis Monteiro
> >>> http://twitter.com/jlouismonteiro
> >>> http://www.tomitribe.com
> >>>
> >>>
> >>> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com>
> >>> a écrit :
> >>>
> >>>> Thanks Romain. I'm fine with using Eclipse jars if from a legal point
> >> of
> >>>> view, it works.
> >>>> Otherwise, I'd like to split our spec jars.
> >>>>
> >>>> What about MicroProfile?
> >>>>
> >>>
> >>> We already agreed to not redo the API and use microprofile jars.
> >>>
> >>>
> >>>> It's the same license and we are using them in our MicroProfile
> >>>> implementations.
> >>>> --
> >>>> Jean-Louis Monteiro
> >>>> http://twitter.com/jlouismonteiro
> >>>> http://www.tomitribe.com
> >>>>
> >>>>
> >>>> On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg
>  >>>
> >>>> wrote:
> >>>>
> >>>>> depends what their license is. EPL is (weak) copyleft. Thus I would
> >> like
> >>>>> to avoid exposing it downstream as api.
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>>> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> >>>>> rmannibu...@gmail.com>:
> >>>>>>
> >>>>>> If we still can't reuse jakata artifacts (their license is ok and
> >> there
> >>>>> is
> >>>>>> no impl ref

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

@Mark: didn't change with jakarta donation? can you open a ticket on
jakartee tracker please?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a écrit :

> No, this is an intended situation.
> When one fully passes the TCK then you get the EFSL. This 'removes' the
> copyleft nature of the EPL.
> The details are quite nested in the legal papers, but that's it basically.
>
> If we just upgrade our existing API to be binary compat then we have no IP
> issues.
>
> LieGrue,
> strub
>
>
> > Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau  >:
> >
> > MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity
> for us.
> > That said it is good to reuse the same GAV for end users so we might ask
> jakarta to double license its api jars?
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> a écrit :
> > Yep that was the point.
> > So I was asking if we should do the same yes or not.
> >
> > That seems to be your opinion Romain.
> > Mark on the other end is having some doubts about the license.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau 
> wrote:
> > Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> > a écrit :
> >
> > > Thanks Romain. I'm fine with using Eclipse jars if from a legal point
> of
> > > view, it works.
> > > Otherwise, I'd like to split our spec jars.
> > >
> > > What about MicroProfile?
> > >
> >
> > We already agreed to not redo the API and use microprofile jars.
> >
> >
> > > It's the same license and we are using them in our MicroProfile
> > > implementations.
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg  >
> > > wrote:
> > >
> > >> depends what their license is. EPL is (weak) copyleft. Thus I would
> like
> > >> to avoid exposing it downstream as api.
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> > >> rmannibu...@gmail.com>:
> > >> >
> > >> > If we still can't reuse jakata artifacts (their license is ok and
> there
> > >> is
> > >> > no impl reference inside so we should just use them, right?) it
> sounds
> > >> > natural
> > >> >
> > >> > Romain Manni-Bucau
> > >> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >> > <https://rmannibucau.metawerx.net/> | Old Blog
> > >> > <http://rmannibucau.wordpress.com> | Github <
> > >> https://github.com/rmannibucau> |
> > >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >> > <
> > >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >> >
> > >> >
> > >> >
> > >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> > >> jlmonte...@tomitribe.com>
> > >> > a écrit :
> > >> >
> > >> >> Hi all,
> > >> >>
> > >> >> I was digging into some other specifications and see what would
> pass
> > >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
> > >> actually
> > >> >> mixes 2 specifications.
> > >> >>
> > >> >> https://github.com/eclipse-ee4j/security-api
> > >> >>
> > >> >> and
> > >> >>
> > >> >> https://github.com/eclipse-ee4j/jaspic
> > >> >>
> > >> >> I thought the initial intent was to create a specific artifact per
> > >> >> specification.
> > >> >> Mixing them is a bit annoying from a certification perspective.
> > >> >> It's also not clean because in Tomcat for instance, there is
> already
> > >> >> jaspic API so it becomes a duplicate.
> > >> >>
> > >> >> Would it be possible to split them up in 2 artifacts?
> > >> >>
> > >> >> --
> > >> >> Jean-Louis Monteiro
> > >> >> http://twitter.com/jlouismonteiro
> > >> >> http://www.tomitribe.com
> > >> >>
> > >>
> > >>
>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

exactly.
Main ambiguity is for API using a provider as only impl dependency like
jsonp/jsonb (
https://github.com/apache/geronimo-specs/blob/trunk/geronimo-jsonb_1.0_spec/src/main/java/javax/json/bind/spi/JsonbProvider.java#L30
).
Think it makes sense to keep it hosted to change this value even if system
props/SPI enable to switch it since it enables to make fatjars smooths
without configs and to ensure we load the right default but it is really a
single string so can be discussed.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 4 sept. 2019 à 11:16, Jean-Louis Monteiro 
a écrit :

> so for instance activation and javamail would stay in Geronimo Specs and
> let's say @Inject would be Eclipse?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Wed, Sep 4, 2019 at 11:11 AM Romain Manni-Bucau 
> wrote:
>
>> No I guess it was right, "that are" ;) = fork @G only when we need to
>> change some impl/default provider.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> a écrit :
>>
>> > > This is my current thinking as well; maintain apis that are impls, use
>> > the EPL version otherwise.
>> > I believe you meant "that are not impls ..."
>> >
>> > I'll make the changes on the javaee-api jar
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> >
>> > On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
>> > wrote:
>> >
>> >> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> >> wrote:
>> >> >
>> >> > If we still can't reuse jakata artifacts (their license is ok and
>> there
>> >> is no impl reference inside so we should just use them, right?) it
>> sounds
>> >> natural
>> >>
>> >> This is my current thinking as well; maintain apis that are impls, use
>> >> the EPL version otherwise.
>> >>
>> >> We do have a handful of EPL dependencies, such as ECJ which Tomcat
>> itself
>> >> uses.  Also as more projects like CXF switch over using the Jakarta
>> >> versions, our excludes just get harder to manage.
>> >>
>> >>
>> >> -David
>> >>
>> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> jlmonte...@tomitribe.com> a écrit :
>> >> > Hi all,
>> >> >
>> >> > I was digging into some other specifications and see what would pass
>> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
>> actually
>> >> mixes 2 specifications.
>> >> >
>> >> > https://github.com/eclipse-ee4j/security-api
>> >> >
>> >> > and
>> >> >
>> >> > https://github.com/eclipse-ee4j/jaspic
>> >> >
>> >> > I thought the initial intent was to create a specific artifact per
>> >> specification.
>> >> > Mixing them is a bit annoying from a certification perspective.
>> >> > It's also not clean because in Tomcat for instance, there is already
>> >> jaspic API so it becomes a duplicate.
>> >> >
>> >> > Would it be possible to split them up in 2 artifacts?
>> >> >
>> >> > --
>> >> > Jean-Louis Monteiro
>> >> > http://twitter.com/jlouismonteiro
>> >> > http://www.tomitribe.com
>> >>
>> >>
>>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

No I guess it was right, "that are" ;) = fork @G only when we need to
change some impl/default provider.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 4 sept. 2019 à 11:07, Jean-Louis Monteiro 
a écrit :

> > This is my current thinking as well; maintain apis that are impls, use
> the EPL version otherwise.
> I believe you meant "that are not impls ..."
>
> I'll make the changes on the javaee-api jar
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Sep 3, 2019 at 8:07 PM David Blevins 
> wrote:
>
>> > On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau 
>> wrote:
>> >
>> > If we still can't reuse jakata artifacts (their license is ok and there
>> is no impl reference inside so we should just use them, right?) it sounds
>> natural
>>
>> This is my current thinking as well; maintain apis that are impls, use
>> the EPL version otherwise.
>>
>> We do have a handful of EPL dependencies, such as ECJ which Tomcat itself
>> uses.  Also as more projects like CXF switch over using the Jakarta
>> versions, our excludes just get harder to manage.
>>
>>
>> -David
>>
>> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com> a écrit :
>> > Hi all,
>> >
>> > I was digging into some other specifications and see what would pass
>> Jakarta TCK and realized that geronimo-security_1.0_spec content actually
>> mixes 2 specifications.
>> >
>> > https://github.com/eclipse-ee4j/security-api
>> >
>> > and
>> >
>> > https://github.com/eclipse-ee4j/jaspic
>> >
>> > I thought the initial intent was to create a specific artifact per
>> specification.
>> > Mixing them is a bit annoying from a certification perspective.
>> > It's also not clean because in Tomcat for instance, there is already
>> jaspic API so it becomes a duplicate.
>> >
>> > Would it be possible to split them up in 2 artifacts?
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>>
>>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

go ahead

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 3 sept. 2019 à 16:41, Jean-Louis Monteiro 
a écrit :

> We can raise the issue at Jakarta
>
> Meanwhile, can I remove the jaspic api classes because they really don't
> have anything to do in this spec jar
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Sep 3, 2019 at 4:37 PM Romain Manni-Bucau 
> wrote:
>
>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity for
>> us.
>> That said it is good to reuse the same GAV for end users so we might ask
>> jakarta to double license its api jars?
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> a écrit :
>>
>> > Yep that was the point.
>> > So I was asking if we should do the same yes or not.
>> >
>> > That seems to be your opinion Romain.
>> > Mark on the other end is having some doubts about the license.
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> >
>> > On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> >> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> >> jlmonte...@tomitribe.com>
>> >> a écrit :
>> >>
>> >> > Thanks Romain. I'm fine with using Eclipse jars if from a legal
>> point of
>> >> > view, it works.
>> >> > Otherwise, I'd like to split our spec jars.
>> >> >
>> >> > What about MicroProfile?
>> >> >
>> >>
>> >> We already agreed to not redo the API and use microprofile jars.
>> >>
>> >>
>> >> > It's the same license and we are using them in our MicroProfile
>> >> > implementations.
>> >> > --
>> >> > Jean-Louis Monteiro
>> >> > http://twitter.com/jlouismonteiro
>> >> > http://www.tomitribe.com
>> >> >
>> >> >
>> >> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg
>> > >> >
>> >> > wrote:
>> >> >
>> >> >> depends what their license is. EPL is (weak) copyleft. Thus I would
>> >> like
>> >> >> to avoid exposing it downstream as api.
>> >> >>
>> >> >> LieGrue,
>> >> >> strub
>> >> >>
>> >> >>
>> >> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
>> >> >> rmannibu...@gmail.com>:
>> >> >> >
>> >> >> > If we still can't reuse jakata artifacts (their license is ok and
>> >> there
>> >> >> is
>> >> >> > no impl reference inside so we should just use them, right?) it
>> >> sounds
>> >> >> > natural
>> >> >> >
>> >> >> > Romain Manni-Bucau
>> >> >> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >> >> > <https://rmannibucau.metawerx.net/> | Old Blog
>> >> >> > <http://rmannibucau.wordpress.com> | Github <
>> >> >> https://github.com/rmannibucau> |
>> >> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >> >> > <
>> >> >>
>> >>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> >> jlmonte...@tomitribe.com>
>> >> >> > a écrit :
>> >> >> >
>> >> >> >> Hi all,
>> >> >> >>
>> >> >> >> I was digging into some other specifications and see what would
>> pass
>> >> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
>> >> >> actually
>> >> >> >> mixes 2 specifications.
>> >> >> >>
>> >> >> >> https://github.com/eclipse-ee4j/security-api
>> >> >> >>
>> >> >> >> and
>> >> >> >>
>> >> >> >> https://github.com/eclipse-ee4j/jaspic
>> >> >> >>
>> >> >> >> I thought the initial intent was to create a specific artifact
>> per
>> >> >> >> specification.
>> >> >> >> Mixing them is a bit annoying from a certification perspective.
>> >> >> >> It's also not clean because in Tomcat for instance, there is
>> already
>> >> >> >> jaspic API so it becomes a duplicate.
>> >> >> >>
>> >> >> >> Would it be possible to split them up in 2 artifacts?
>> >> >> >>
>> >> >> >> --
>> >> >> >> Jean-Louis Monteiro
>> >> >> >> http://twitter.com/jlouismonteiro
>> >> >> >> http://www.tomitribe.com
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >
>>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity for
us.
That said it is good to reuse the same GAV for end users so we might ask
jakarta to double license its api jars?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro 
a écrit :

> Yep that was the point.
> So I was asking if we should do the same yes or not.
>
> That seems to be your opinion Romain.
> Mark on the other end is having some doubts about the license.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau 
> wrote:
>
>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> a écrit :
>>
>> > Thanks Romain. I'm fine with using Eclipse jars if from a legal point of
>> > view, it works.
>> > Otherwise, I'd like to split our spec jars.
>> >
>> > What about MicroProfile?
>> >
>>
>> We already agreed to not redo the API and use microprofile jars.
>>
>>
>> > It's the same license and we are using them in our MicroProfile
>> > implementations.
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> >
>> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg > >
>> > wrote:
>> >
>> >> depends what their license is. EPL is (weak) copyleft. Thus I would
>> like
>> >> to avoid exposing it downstream as api.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>
>> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
>> >> rmannibu...@gmail.com>:
>> >> >
>> >> > If we still can't reuse jakata artifacts (their license is ok and
>> there
>> >> is
>> >> > no impl reference inside so we should just use them, right?) it
>> sounds
>> >> > natural
>> >> >
>> >> > Romain Manni-Bucau
>> >> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> >> > <https://rmannibucau.metawerx.net/> | Old Blog
>> >> > <http://rmannibucau.wordpress.com> | Github <
>> >> https://github.com/rmannibucau> |
>> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >> > <
>> >>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >> >
>> >> >
>> >> >
>> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> >> jlmonte...@tomitribe.com>
>> >> > a écrit :
>> >> >
>> >> >> Hi all,
>> >> >>
>> >> >> I was digging into some other specifications and see what would pass
>> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
>> >> actually
>> >> >> mixes 2 specifications.
>> >> >>
>> >> >> https://github.com/eclipse-ee4j/security-api
>> >> >>
>> >> >> and
>> >> >>
>> >> >> https://github.com/eclipse-ee4j/jaspic
>> >> >>
>> >> >> I thought the initial intent was to create a specific artifact per
>> >> >> specification.
>> >> >> Mixing them is a bit annoying from a certification perspective.
>> >> >> It's also not clean because in Tomcat for instance, there is already
>> >> >> jaspic API so it becomes a duplicate.
>> >> >>
>> >> >> Would it be possible to split them up in 2 artifacts?
>> >> >>
>> >> >> --
>> >> >> Jean-Louis Monteiro
>> >> >> http://twitter.com/jlouismonteiro
>> >> >> http://www.tomitribe.com
>> >> >>
>> >>
>> >>
>>
>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro 
a écrit :

> Thanks Romain. I'm fine with using Eclipse jars if from a legal point of
> view, it works.
> Otherwise, I'd like to split our spec jars.
>
> What about MicroProfile?
>

We already agreed to not redo the API and use microprofile jars.


> It's the same license and we are using them in our MicroProfile
> implementations.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg 
> wrote:
>
>> depends what their license is. EPL is (weak) copyleft. Thus I would like
>> to avoid exposing it downstream as api.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>> >
>> > If we still can't reuse jakata artifacts (their license is ok and there
>> is
>> > no impl reference inside so we should just use them, right?) it sounds
>> > natural
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > <https://rmannibucau.metawerx.net/> | Old Blog
>> > <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>> >
>> >
>> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> > a écrit :
>> >
>> >> Hi all,
>> >>
>> >> I was digging into some other specifications and see what would pass
>> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
>> actually
>> >> mixes 2 specifications.
>> >>
>> >> https://github.com/eclipse-ee4j/security-api
>> >>
>> >> and
>> >>
>> >> https://github.com/eclipse-ee4j/jaspic
>> >>
>> >> I thought the initial intent was to create a specific artifact per
>> >> specification.
>> >> Mixing them is a bit annoying from a certification perspective.
>> >> It's also not clean because in Tomcat for instance, there is already
>> >> jaspic API so it becomes a duplicate.
>> >>
>> >> Would it be possible to split them up in 2 artifacts?
>> >>
>> >> --
>> >> Jean-Louis Monteiro
>> >> http://twitter.com/jlouismonteiro
>> >> http://www.tomitribe.com
>> >>
>>
>>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Romain Manni-Bucau]

If we still can't reuse jakata artifacts (their license is ok and there is
no impl reference inside so we should just use them, right?) it sounds
natural

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro 
a écrit :

> Hi all,
>
> I was digging into some other specifications and see what would pass
> Jakarta TCK and realized that geronimo-security_1.0_spec content actually
> mixes 2 specifications.
>
> https://github.com/eclipse-ee4j/security-api
>
> and
>
> https://github.com/eclipse-ee4j/jaspic
>
> I thought the initial intent was to create a specific artifact per
> specification.
> Mixing them is a bit annoying from a certification perspective.
> It's also not clean because in Tomcat for instance, there is already
> jaspic API so it becomes a duplicate.
>
> Would it be possible to split them up in 2 artifacts?
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Re: JSON-B and JSON-P TCKs

[Romain Manni-Bucau]

was planned, we were waiting Mark green light IIRC

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 26 août 2019 à 16:26, Jean-Louis Monteiro 
a écrit :

> Can we do a release then?
>
> I'd like to get that into TomEE when possible
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Mon, Aug 26, 2019 at 4:15 PM Romain Manni-Bucau 
> wrote:
>
> > Hi JL,
> >
> > AFAIK we are passing now
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 26 août 2019 à 15:41, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com>
> > a écrit :
> >
> > > Hi all, Mark, Romain,
> > >
> > > I have started to play with some other Jakarta EE TCK and saw you guys
> > > discussing JSON-P and JSON-B TCK.
> > >
> > > Would it be possible to give a status about where you are?
> > >
> > > On my side, I'm currently working on Geronimo Activation api/impl 1.2.
> > > I know, but I had to start somewhere. I figured I would start small so
> I
> > > can clear the setup quickly.
> > >
> > > JLouis
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> >
>

Re: JPA Spec jar missing Activator

[Romain Manni-Bucau]

Hi JL,

Not sure if you need it - which can make us reconsider it - but long story
short it is superseeded by capabilities on modern OSGi containers so all
done in the pom.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 14 août 2019 à 09:46, Jean-Louis MONTEIRO  a
écrit :

> Hello,
>
> Does anyone know why the activator disappeared between 2.1 and 2.2 spec
> jars?
>
> https://github.com/apache/geronimo-specs/tree/trunk/geronimo-jpa_2.1_spec/src/main/java/org/apache/geronimo/specs/jpa
>
> Is it desired?
> I'm happy to open a ticket and fix it
>
> --
> Jean-Louis
>

Wrong m3 bval dep?

[Romain Manni-Bucau]

Hi everybody

Last m3 depends on  a phantom bval release breaking dependency management
it seems.

Was it identified/communicated?

Re: OpenTracing Zipkin

[Romain Manni-Bucau]

Hmm, missed that but did you try using v1 instead of v2 endpoint?

Side note: if it helps you to test move the delay to -1 to not wait the
interval.

Le lun. 15 avr. 2019 à 20:36, Ivan Junckes Filho  a
écrit :

> Romain I was actually using this docker-compose from JL as reference, but
> wasn't able to make it work.
>
> I will have a look at it again this week, if I have improvement I will let
> you know.
>
> If you have any other tips let me know.
>
> Thanks for the reply!
>
> On Fri, Apr 12, 2019 at 6:25 PM Romain Manni-Bucau 
> wrote:
>
>> Hi Ivan
>>
>> Did you debug ZipkinHttp?
>>
>> Depending your server/app config you can need some config like providers
>> etc. This class is a good start to check what is happening.
>>
>> A good config start is
>>
>> https://github.com/jeanouii/microprofile-samples/blob/master/docker-compose.yaml
>> - you can need to inline the yaml depending you docker compose
>> version/setup, multiline is not always well supported.
>>
>>
>>
>> Le ven. 12 avr. 2019 à 22:10, Ivan Junckes Filho 
>> a
>> écrit :
>>
>> > Hey guys I am having a hard time to setup TomEE with OpenTracing 1.0.2 +
>> > Zipkin.
>> >
>> > When I send the payload to the zipkin API
>> > http://localhost:9411/api/v2/spans, I keep getting back:
>> > 400 - "Expected a JSON_V2 encoded list, but received: JSON_V1"
>> >
>> > My payload is:
>> > [
>> >   {
>> > "annotations": [
>> >   {
>> > "timestamp": 1555097175276000,
>> > "value": "sr"
>> >   },
>> >   {
>> > "timestamp": 1555097175402000,
>> > "value": "ss"
>> >   }
>> > ],
>> > "binaryAnnotations": [
>> >   {
>> > "key": "http.status_code",
>> > "type": 3,
>> > "value": 200
>> >   },
>> >   {
>> > "key": "component",
>> > "type": 6,
>> > "value": "jaxrs"
>> >   },
>> >   {
>> > "key": "span.kind",
>> > "type": 6,
>> > "value": "server"
>> >   },
>> >   {
>> > "key": "http.url",
>> > "type": 6,
>> > "value": "http://localhost:8081/number-api/numbers/generate;
>> >   },
>> >   {
>> > "key": "http.method",
>> > "type": 6,
>> > "value": "GET"
>> >   }
>> > ],
>> > "duration": 126000,
>> > "id": 2,
>> > "kind": "SERVER",
>> > "localEndpoint": {
>> >   "ipv4": "127.0.0.1",
>> >   "port": 8081,
>> >   "serviceName": "number-api"
>> > },
>> > "name":
>> >
>> "GET:com.microprofile.samples.services.number.resource.NumberResource.generate",
>> > "parentId": 1,
>> > "tags": {
>> >   "http.status_code": "200",
>> >   "component": "jaxrs",
>> >   "http.url": "http://localhost:8081/number-api/numbers/generate;,
>> >   "http.method": "GET"
>> > },
>> > "timestamp": 1555097175276000,
>> > "traceId": 24
>> >   }
>> > ]
>> >
>> > Any ideas how to fix this?  Anyone was able to configure zipkin as a
>> > collector using TomEE?
>> >
>>
>

Re: OpenTracing Zipkin

[Romain Manni-Bucau]

Hi Ivan

Did you debug ZipkinHttp?

Depending your server/app config you can need some config like providers
etc. This class is a good start to check what is happening.

A good config start is
https://github.com/jeanouii/microprofile-samples/blob/master/docker-compose.yaml
- you can need to inline the yaml depending you docker compose
version/setup, multiline is not always well supported.



Le ven. 12 avr. 2019 à 22:10, Ivan Junckes Filho  a
écrit :

> Hey guys I am having a hard time to setup TomEE with OpenTracing 1.0.2 +
> Zipkin.
>
> When I send the payload to the zipkin API
> http://localhost:9411/api/v2/spans, I keep getting back:
> 400 - "Expected a JSON_V2 encoded list, but received: JSON_V1"
>
> My payload is:
> [
>   {
> "annotations": [
>   {
> "timestamp": 1555097175276000,
> "value": "sr"
>   },
>   {
> "timestamp": 1555097175402000,
> "value": "ss"
>   }
> ],
> "binaryAnnotations": [
>   {
> "key": "http.status_code",
> "type": 3,
> "value": 200
>   },
>   {
> "key": "component",
> "type": 6,
> "value": "jaxrs"
>   },
>   {
> "key": "span.kind",
> "type": 6,
> "value": "server"
>   },
>   {
> "key": "http.url",
> "type": 6,
> "value": "http://localhost:8081/number-api/numbers/generate;
>   },
>   {
> "key": "http.method",
> "type": 6,
> "value": "GET"
>   }
> ],
> "duration": 126000,
> "id": 2,
> "kind": "SERVER",
> "localEndpoint": {
>   "ipv4": "127.0.0.1",
>   "port": 8081,
>   "serviceName": "number-api"
> },
> "name":
> "GET:com.microprofile.samples.services.number.resource.NumberResource.generate",
> "parentId": 1,
> "tags": {
>   "http.status_code": "200",
>   "component": "jaxrs",
>   "http.url": "http://localhost:8081/number-api/numbers/generate;,
>   "http.method": "GET"
> },
> "timestamp": 1555097175276000,
> "traceId": 24
>   }
> ]
>
> Any ideas how to fix this?  Anyone was able to configure zipkin as a
> collector using TomEE?
>

Re: RestClient issue - different apps with same client

[Romain Manni-Bucau]

Cxf rest cdi extension leaks beans, think i opened n issue last week or the
week before about it. Dropping the static from the extension fixes that.

Guess it was done as a workaround for ears but probably better to use
another mecanism like the one of deltaspike or just not do it.

Le mar. 12 mars 2019 à 20:46, Daniel Cunha  a écrit :

> Hi Ivan,
>
> Can you share a sample?
>
> Em ter, 12 de mar de 2019 às 16:34, Ivan Junckes Filho <
> ivanjunc...@gmail.com> escreveu:
>
> > Hey guys, there is a very annoying bug when using rest client from cxf
> > 3.2.7 in TomEE M2. When 2 apps have the same client the server throws the
> > error below and shuts down?
> >
> > Shouldn't we allow different apps in the same server use the same client?
> >
> > *Error*
> > Caused by: org.apache.webbeans.exception.WebBeansException:
> > org.apache.webbeans.exception.DuplicateDefinitionException:
> > PassivationCapable bean id is not unique:
> > br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient
> > bean:SiemClassificacaoServiceClient, WebBeansType:THIRDPARTY,
> >
> >
> Name:br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient,
> > API
> >
> >
> Types:[br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient],
> >
> >
> Qualifiers:[javax.enterprise.inject.Default,org.eclipse.microprofile.rest.client.inject.RestClient,javax.enterprise.inject.Any],
> > existing: SiemClassificacaoServiceClient, WebBeansType:THIRDPARTY,
> >
> >
> Name:br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient,
> > API
> >
> >
> Types:[br.com.gbrsistemas.crvirtual.classificacao.SiemClassificacaoServiceClient],
> >
> >
> Qualifiers:[javax.enterprise.inject.Default,org.eclipse.microprofile.rest.client.inject.RestClient,javax.enterprise.inject.Any]
> > at
> >
> >
> org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:371)
> > at
> >
> >
> org.apache.webbeans.event.NotificationManager.invokeObserverMethod(NotificationManager.java:818)
> > at
> >
> >
> org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:714)
> > ... 42 more
> >
>
>
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
>

Re: "In" parameter not being populated OpenAPI

[Romain Manni-Bucau]

Then just upgrade?
About the "not needed", it depends but not an issue by itself AFAIK.

Le lun. 11 févr. 2019 à 17:37, Ivan Junckes Filho  a
écrit :

> This is how it is showing up in components, schemas. But with a lot of not
> needed properties as  this class has only telefone, mensagem and usuario.
>
>  "br_com_gbrsistemas_crvirtual_sms_Sms": {
> "deprecated": false,
> "exclusiveMaximum": false,
> "exclusiveMinimum": false,
> "maxLength": 2147483647,
> "minLength": 0,
> "nullable": false,
> "properties": {
>   "telefone": {
> "type": "string"
>   },
>   "mensagem": {
> "type": "string"
>   },
>   "usuario": {
> "type": "string"
>   }
> },
> "readOnly": false,
> "type": "object",
> "uniqueItems": false,
> "writeOnly": false
>   },
>
> Also the SNAPSHOT service path references the previous schema also with a
> lot of not needed properties like deprecated, etc.
>
> /sms/enviar": {
>   "post": {
> "deprecated": false,
> "description": "Enviar SMS.",
> "operationId": "enviarSms",
> "parameters": [
>
> ],
> "requestBody": {
>   "content": {
> "*/*": {
>   "schema": {
> "$ref":
> "#/components/schemas/br_com_gbrsistemas_crvirtual_sms_Sms",
> "deprecated": false,
> "exclusiveMaximum": false,
> "exclusiveMinimum": false,
> "maxLength": 2147483647,
> "minLength": 0,
> "nullable": false,
> "readOnly": false,
> "type": "object",
> "uniqueItems": false,
> "writeOnly": false
>   }
> }
>   },
>   "required": false
> },
> "responses": {
>   "200": {
> "content": {
>   "text/plain": {
> "schema": {
>   "deprecated": false,
>   "exclusiveMaximum": false,
>   "exclusiveMinimum": false,
>   "maxLength": 2147483647,
>   "minLength": 0,
>   "nullable": false,
>   "readOnly": false,
>   "type": "string",
>   "uniqueItems": false,
>   "writeOnly": false
> }
>   }
> },
> "description": "Success"
>   },
>   "400": {
> "content": {
>   "200": {
>
>   }
> },
> "description": "Bad Request"
>   }
> },
> "security": [
>   {
> "bearer": [
>
> ]
>   }
> ]
>   }
> },
>
> The current m2 version of TomEE doesn't even show ref or any schema
> classes.
>
> On Mon, Feb 11, 2019 at 12:12 PM Romain Manni-Bucau 
> wrote:
>
>> Hi Ivan, no the mapping can need some polishing to become mainstream
>> (cause it is not openapi role to reimplement all mappers logic) but the
>> annotation mapping is done.
>> This one can depend the companions this annotation has, some will imply
>> it gets ignored but AFAIK TCK test that and we pass them.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le lun. 11 févr. 2019 à 14:56, Ivan Junckes Filho 
>> a écrit :
>>
>>>

Re: "In" parameter not being populated OpenAPI

[Romain Manni-Bucau]

Hi Ivan, no the mapping can need some polishing to become mainstream (cause
it is not openapi role to reimplement all mappers logic) but the annotation
mapping is done.
This one can depend the companions this annotation has, some will imply it
gets ignored but AFAIK TCK test that and we pass them.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 11 févr. 2019 à 14:56, Ivan Junckes Filho  a
écrit :

> One thing I saw happening too, is when I add the annotation below it
> doesn't get added to openapi.
>
> @RequestBody(content = @Content(schema = @Schema(implementation = Sms.class)))
>
>
> Is that because it is under development?
>
>
> On Mon, Feb 11, 2019 at 11:38 AM Romain Manni-Bucau 
> wrote:
>
>> Yes Ivan, array mapping is in progress. In the meantime you can define
>> your schema to ensure you control it and the implicit representation does
>> not depends on the way the impl parses it - which can not match your
>> underlying mapper.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le lun. 11 févr. 2019 à 14:23, Ivan Junckes Filho 
>> a écrit :
>>
>>> Looks like it is fixed in the master, but when I get the lib and add to
>>> tomee it shows some bad behavior with the schemas.
>>>
>>> [image: image.png]
>>>
>>> On Mon, Feb 11, 2019 at 11:09 AM Ivan Junckes Filho <
>>> ivanjunc...@gmail.com> wrote:
>>>
>>>> No I didn't, I will have a look. thanks
>>>>
>>>> On Mon, Feb 11, 2019 at 11:08 AM Romain Manni-Bucau <
>>>> rmannibu...@gmail.com> wrote:
>>>>
>>>>> Hi Ivan,
>>>>>
>>>>> Did you test on the snapshot? we got some enhancements about it.
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>> <http://rmannibucau.wordpress.com> | Github <
>>>>> https://github.com/rmannibucau> |
>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>> <
>>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>> >
>>>>>
>>>>>
>>>>> Le lun. 11 févr. 2019 à 14:03, Ivan Junckes Filho <
>>>>> ivanjunc...@gmail.com> a
>>>>> écrit :
>>>>>
>>>>> > Hey guys, I think there is an issue with parameters as the "in"
>>>>> property
>>>>> > is required by the spec and is not showing up. This affects
>>>>> swagger-ui as
>>>>> > it doesn't replace uf by the actual value. Anyone aware of this
>>>>> issue?
>>>>> >
>>>>> > {
>>>>> >   "openapi": "3.0.1",
>>>>> >   "paths": {
>>>>> > "/test/{uf}": {
>>>>> >   "get": {
>>>>> > "deprecated": false,
>>>>> > "description": "Test by UF.",
>>>>> > "operationId": "test",
>>>>> > "parameters": [
>>>>> >   {
>>>>> > "name": "uf",
>>>>> > "required": true,
>>>>> > "schema": {
>>>>> >   "type": "string"
>>>>> > },
>>>>> > "style": "simple"
>>>>> >   }
>>>>> > ],
>>>>> > "responses": {
>>>>> >   "200": {
>>>>> > "content": {
>>>>> >   "application/json": {
>>>>> > "schema": {
>>>>> >   "deprecated": false,
>>>>> >   "exclusiveMaximum": false,
>>>>> >   "exclusiveMinimum": false,
>>>>> >   "items": {
>>>>> >
>>>>> >   },
>>>>> >   "maxLength": 2147483647,
>>>>> >   "minLength": 0,
>>>>> >   "nullable": false,
>>>>> >   "properties": {
>>>>> >
>>>>> >   },
>>>>> >   "readOnly": false,
>>>>> >   "uniqueItems": false,
>>>>> >   "writeOnly": false
>>>>> > }
>>>>> >   }
>>>>> > },
>>>>> > "description": "Success"
>>>>> >   },
>>>>> >   "400": {
>>>>> > "content": {
>>>>> >   "200": {
>>>>> >
>>>>> >   }
>>>>> > },
>>>>> > "description": "Bad Request"
>>>>> >   }
>>>>> > },
>>>>> >
>>>>> >   }
>>>>> > },
>>>>> >
>>>>> >   }
>>>>> >   ]
>>>>> > }
>>>>> >
>>>>>
>>>>

Re: "In" parameter not being populated OpenAPI

[Romain Manni-Bucau]

Yes Ivan, array mapping is in progress. In the meantime you can define your
schema to ensure you control it and the implicit representation does not
depends on the way the impl parses it - which can not match your underlying
mapper.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 11 févr. 2019 à 14:23, Ivan Junckes Filho  a
écrit :

> Looks like it is fixed in the master, but when I get the lib and add to
> tomee it shows some bad behavior with the schemas.
>
> [image: image.png]
>
> On Mon, Feb 11, 2019 at 11:09 AM Ivan Junckes Filho 
> wrote:
>
>> No I didn't, I will have a look. thanks
>>
>> On Mon, Feb 11, 2019 at 11:08 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>>
>>> Hi Ivan,
>>>
>>> Did you test on the snapshot? we got some enhancements about it.
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>> <
>>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> >
>>>
>>>
>>> Le lun. 11 févr. 2019 à 14:03, Ivan Junckes Filho 
>>> a
>>> écrit :
>>>
>>> > Hey guys, I think there is an issue with parameters as the "in"
>>> property
>>> > is required by the spec and is not showing up. This affects swagger-ui
>>> as
>>> > it doesn't replace uf by the actual value. Anyone aware of this issue?
>>> >
>>> > {
>>> >   "openapi": "3.0.1",
>>> >   "paths": {
>>> > "/test/{uf}": {
>>> >   "get": {
>>> > "deprecated": false,
>>> > "description": "Test by UF.",
>>> > "operationId": "test",
>>> > "parameters": [
>>> >   {
>>> > "name": "uf",
>>> > "required": true,
>>> > "schema": {
>>> >   "type": "string"
>>> > },
>>> > "style": "simple"
>>> >   }
>>> > ],
>>> > "responses": {
>>> >   "200": {
>>> > "content": {
>>> >   "application/json": {
>>> > "schema": {
>>> >   "deprecated": false,
>>> >   "exclusiveMaximum": false,
>>> >   "exclusiveMinimum": false,
>>> >   "items": {
>>> >
>>> >   },
>>> >   "maxLength": 2147483647,
>>> >   "minLength": 0,
>>> >   "nullable": false,
>>> >   "properties": {
>>> >
>>> >   },
>>> >   "readOnly": false,
>>> >   "uniqueItems": false,
>>> >   "writeOnly": false
>>> > }
>>> >   }
>>> > },
>>> > "description": "Success"
>>> >   },
>>> >   "400": {
>>> > "content": {
>>> >   "200": {
>>> >
>>> >   }
>>> > },
>>> > "description": "Bad Request"
>>> >   }
>>> > },
>>> >
>>> >   }
>>> > },
>>> >
>>> >   }
>>> >   ]
>>> > }
>>> >
>>>
>>

Re: "In" parameter not being populated OpenAPI

[Romain Manni-Bucau]

Hi Ivan,

Did you test on the snapshot? we got some enhancements about it.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 11 févr. 2019 à 14:03, Ivan Junckes Filho  a
écrit :

> Hey guys, I think there is an issue with parameters as the "in" property
> is required by the spec and is not showing up. This affects swagger-ui as
> it doesn't replace uf by the actual value. Anyone aware of this issue?
>
> {
>   "openapi": "3.0.1",
>   "paths": {
> "/test/{uf}": {
>   "get": {
> "deprecated": false,
> "description": "Test by UF.",
> "operationId": "test",
> "parameters": [
>   {
> "name": "uf",
> "required": true,
> "schema": {
>   "type": "string"
> },
> "style": "simple"
>   }
> ],
> "responses": {
>   "200": {
> "content": {
>   "application/json": {
> "schema": {
>   "deprecated": false,
>   "exclusiveMaximum": false,
>   "exclusiveMinimum": false,
>   "items": {
>
>   },
>   "maxLength": 2147483647,
>   "minLength": 0,
>   "nullable": false,
>   "properties": {
>
>   },
>   "readOnly": false,
>   "uniqueItems": false,
>   "writeOnly": false
> }
>   }
> },
> "description": "Success"
>   },
>   "400": {
> "content": {
>   "200": {
>
>   }
> },
> "description": "Bad Request"
>   }
> },
>
>   }
> },
>
>   }
>   ]
> }
>

Re: @OpenAPIDefinition not working

[Romain Manni-Bucau]

Hey, just recalled we had a flag about it,

you can skip it setting openejb.cxf-rs.cache-application=false

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 8 févr. 2019 à 19:01, Ivan Junckes Filho  a
écrit :

> Interesting, ok thanks Romain.
>
> On Fri, Feb 8, 2019 at 3:29 PM Romain Manni-Bucau 
> wrote:
>
>> Hi Ivan,
>>
>> In a few cases - don't recall out of my head if it is all - TomEE wraps
>> user application in InternalApplication. IIRC it was for caching reason -
>> TomEE not being super cleanly aligned on CDI + to avoid to get multiple
>> instances between runtime and deployment which can break user code.
>> Enhancing TomEE to no do it anymore or not use a wrapper when not needed
>> can be a first step fixing that.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le ven. 8 févr. 2019 à 18:14, Ivan Junckes Filho 
>> a écrit :
>>
>>> The @OpenAPIDefinition is not being picked up by the CDI extension
>>> because it is only getting InternalApplication instead of picking up my
>>> custom Application config. Any ideas why? OpenAPIDefinition configs are
>>> therefore not showing up in the openapi doc.
>>>
>>>
>>> @OpenAPIDefinition(info =
>>> @Info(
>>> title = "TEST",
>>> version = "2.0",
>>> description = "Pet Store App API",
>>> license = @License(
>>> name = "Apache 2.0",
>>> url = 
>>> "http://www.apache.org/licenses/LICENSE-2.0.html;),
>>> contact = @Contact(
>>> name = "PetStore API Support",
>>> url = 
>>> "https://github.com/eclipse/microprofile-open-api;,
>>> email = "supp...@petstore.com")
>>> ),
>>> security = @SecurityRequirement(name = "oauth2"),
>>> servers = @Server(url = "/test/"))
>>> @ApplicationPath("/api")
>>> @LoginConfig(authMethod = "MP-JWT")
>>> public class ApplicationConfiguration extends Application {
>>>
>>>

Re: @OpenAPIDefinition not working

[Romain Manni-Bucau]

Hi Ivan,

In a few cases - don't recall out of my head if it is all - TomEE wraps
user application in InternalApplication. IIRC it was for caching reason -
TomEE not being super cleanly aligned on CDI + to avoid to get multiple
instances between runtime and deployment which can break user code.
Enhancing TomEE to no do it anymore or not use a wrapper when not needed
can be a first step fixing that.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 8 févr. 2019 à 18:14, Ivan Junckes Filho  a
écrit :

> The @OpenAPIDefinition is not being picked up by the CDI extension because
> it is only getting InternalApplication instead of picking up my custom
> Application config. Any ideas why? OpenAPIDefinition configs are therefore
> not showing up in the openapi doc.
>
>
> @OpenAPIDefinition(info =
> @Info(
> title = "TEST",
> version = "2.0",
> description = "Pet Store App API",
> license = @License(
> name = "Apache 2.0",
> url = 
> "http://www.apache.org/licenses/LICENSE-2.0.html;),
> contact = @Contact(
> name = "PetStore API Support",
> url = 
> "https://github.com/eclipse/microprofile-open-api;,
> email = "supp...@petstore.com")
> ),
> security = @SecurityRequirement(name = "oauth2"),
> servers = @Server(url = "/test/"))
> @ApplicationPath("/api")
> @LoginConfig(authMethod = "MP-JWT")
> public class ApplicationConfiguration extends Application {
>
>

Re: OpenTracing - nullpointer OpenTracingFilter

[Romain Manni-Bucau]

Long story short, the MP impl assume CDI is active, if not then tomee but
disable the MP impl.
For us it means disabling also the servlet container initializers. It can
be done in OpenEJBContextConfig or - likely good - implementing a
contextual ConfigSource (reading AppContext#properties for instance) and
forcing geronimo.opentracing.filter.active to false for the webapp (not
globally). Setting the system property you should get the same behavior but
it will be global so some app will not get tracing.
In other word it is the core work tomee must do: integration :).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 22 janv. 2019 à 17:03, Ivan Junckes Filho  a
écrit :

> When you say it is a bug in CDI support of TomEE, could you please be more
> specific? Of course if you are aware of what it could be·
>
> On Tue, Jan 22, 2019 at 12:50 PM Romain Manni-Bucau 
> wrote:
>
>> Hmm, we can add a check in the filter and fail the deployment but at the
>> end it is a bug in CDI support of TomEE so likely saner to fix it in TomEE,
>> right?
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le mar. 22 janv. 2019 à 15:37, Ivan Junckes Filho 
>> a écrit :
>>
>>> I would say if the extension was not executed for some reason that we
>>> need to know why, we need to make sure the filter doesn't throw that
>>> exception or completely ignore the filter logic right?
>>>
>>> On Tue, Jan 22, 2019 at 12:08 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>>
>>>> Hi Ivan,
>>>>
>>>> This means the opentracing extension was not executed for the app:
>>>> https://github.com/apache/geronimo-opentracing/blob/master/geronimo-opentracing/src/main/java/org/apache/geronimo/microprofile/opentracing/microprofile/cdi/OpenTracingExtension.java#L125
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github
>>>> <https://github.com/rmannibucau> | LinkedIn
>>>> <https://www.linkedin.com/in/rmannibucau> | Book
>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>>>
>>>>
>>>> Le mar. 22 janv. 2019 à 14:39, Ivan Junckes Filho <
>>>> ivanjunc...@gmail.com> a écrit :
>>>>
>>>>> Hey guys, I would like some help with an opentracing issue. I am not
>>>>> sure if it was already fixed or not. It was happening on version 1.0.0,
>>>>> current M1 release of TomEE 8.
>>>>>
>>>>> There is a nullpointer happening in OpenTracingFilter and it seems to
>>>>> be because this injection is null.
>>>>>
>>>>> @Inject
>>>>> private GeronimoOpenTracingConfig config;
>>>>>
>>>>> So this line throws the null pointer:
>>>>>
>>>>> skipDefaultTags = 
>>>>> Boolean.parseBoolean(config.read("filter.forcedTracing.skipDefaultTags", 
>>>>> "false"));
>>>>>
>>>>> Anyone can help with this?
>>>>>
>>>>> Logs are attached.
>>>>>
>>>>>
>>>>>

Re: Adding Java EE Security 1.0 Spec to geronimo-specs

[Romain Manni-Bucau]

If Roberto agrees +1

Le ven. 11 janv. 2019 20:29, Gurkan Erdogdu  a écrit :

> Hi folks
> Regarding TomEE, we need to add Java EE Security, JSR-375 spec to
> geronimo-specs and needs a release. I have committer access to
> geronimo-specs and added to code (implemented by Roberto Cortez in
> tomee-security) into my local. Can I commit to code to the geronimo-specs?
> Any objection?
> Regards.
> Gurkan
>

Re: TOMEE-2289

[Romain Manni-Bucau]

Hi Ivan

For the browser usage /openapi.json or /openapi.yaml will solve it nicely

On master we ensure to respect the request expected type - it is fine to
serialize it as html, this is even a way to implement a UI for it ;) - but
we also ensure there is a writer instead of assuming the user request will
work (new). This has the drawback to be able to send back an invalid
response to the client (and break it) but since the spec doesn't define
what to do in that case (guess it should just do nothing and let JAX-RS
handle it otherwise microprofile wouldn't be JAX-RS based anymore) and
defines that yaml is supposed to be the default then we are in a grey
enough area to make you happy ;). Worse case we would revert it but it is
not a prod usage for sure so no big deal for now.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 4 janv. 2019 à 21:04, Ivan Junckes Filho  a
écrit :

> FYI I opened a PR on geronimo to fix the issue with text/html.
>
> https://github.com/apache/geronimo-openapi/pull/4
>
> Postman was working because it used */* and the implementation was
> properly handling it, but not handling text/html.
>
> On Thu, Jan 3, 2019 at 2:34 PM Ivan Junckes Filho 
> wrote:
>
>> Yes, the default content-type for browsers is text/html. I will submit a
>> pr accepting that.
>>
>> On Thu, Jan 3, 2019 at 2:17 PM César Hernández Mendoza <
>> cesargu...@gmail.com> wrote:
>>
>>> This  "default" behavior is also present in Metrics geronimo
>>> implementation.
>>> The issue is that the spec doesn't explicitly indicate the default
>>> content-type requirement.
>>>
>>> El jue., 3 ene. 2019 a las 9:48, Ivan Junckes Filho (<
>>> ivanjunc...@gmail.com>)
>>> escribió:
>>>
>>> > I will take a look and help troubleshoot this.
>>> >
>>> > On Thu, Jan 3, 2019 at 12:08 PM Puneeth PS 
>>> wrote:
>>> >
>>> > > Hi Ivan,
>>> > >
>>> > > /openapi works in POSTMAN client but not on browser, so might not be
>>> an
>>> > > issue.
>>> > >
>>> > > On Thu, Jan 3, 2019 at 6:38 PM Ivan Junckes Filho <
>>> ivanjunc...@gmail.com
>>> > >
>>> > > wrote:
>>> > >
>>> > > > Hi Puneeth, I added a couple of more comments.
>>> > > >
>>> > > > There seems to have a couple of bugs in the openapi implementation.
>>> > > >
>>> > > > Json serialization bug and also /openapi is not working without the
>>> > > header.
>>> > > > So we may need to open bugs
>>> > > > in https://issues.apache.org/jira/projects/GERONIMO/issues
>>> > > > <https://issues.apache.org/jira/projects/GERONIMO/issues>.
>>> > > >
>>> > > > I will try to help troubleshoot these issues.
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Thu, Jan 3, 2019 at 12:53 AM Puneeth PS 
>>> > wrote:
>>> > > >
>>> > > > > Hi Ivan,
>>> > > > >
>>> > > > > I have made the changes requested and I've some questions
>>> regarding
>>> > the
>>> > > > > spec which I've asked on the github thread, can you please
>>> clarify
>>> > > these?
>>> > > > >
>>> > > > > On Wed 2 Jan, 2019, 6:09 PM Ivan Junckes Filho <
>>> > ivanjunc...@gmail.com
>>> > > > > wrote:
>>> > > > >
>>> > > > > > Puneeth, I did some comments here
>>> > > > > >
>>> > https://github.com/apache/tomee/pull/340#pullrequestreview-188661807
>>> > > ,
>>> > > > > > please take a look.
>>> > > > > >
>>> > > > > > On Wed, Jan 2, 2019 at 9:51 AM Ivan Junckes Filho <
>>> > > > ivanjunc...@gmail.com
>>> > > > > >
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > > > Hi Puneeth, I will review it for you.
>>> > > > > > >
>>> > > > > > > On Wed, Jan 2, 2019 at 8:39 AM Puneeth PS <
>>> puneeth...@gmail.com>
>>> > > > > wrote:
>>> > > > > > >
>>> > > > > > >> Hi,
>>> > > > > > >>
>>> > > > > > >> I have created a PR (
>>> https://github.com/apache/tomee/pull/340
>>> > )
>>> > > > for
>>> > > > > > >> TOMEE-2289. Can someone take a look and help me improve it?
>>> > > > > > >>
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>>
>>> --
>>> Atentamente:
>>> César Hernández Mendoza.
>>>
>>

Re: New Java EE Schemas for Java EE Deployment Descriptors

[Romain Manni-Bucau]

Hello

If it helps there are twi things to consider:

1. When we supported ee7 we made most of these descriptors at lowest cost
which means we mainly let them pass and sometimes ignore some model part
not used at runtime and let the actual runtime lib read it (typically jsf)
2. All the current models must not be modified in terms of API cause they
are not internal since application composer is an user solution since some
years

My 2 cts would be that the only usage was to serialize it in object tree,
now we have json built-in we can surely rationalize it and made it simpler
and maybe limited to the actual usage. Being able to represent the server
model in tomee core and change stuff here to impact the runtime does not
work since ee6 and cdi anyway so no need to try, would be too costly for
startup time or too complex/split to redo what the spec already does well
probably.

Le lun. 3 déc. 2018 02:59, David Jencks  a écrit :

>
> It’s been a very long time since I worked with these, but I do remember
> that switching to the openejb customized classes was a very big
> improvement. I think it’s definitely worth having an object tree
> representing the deployment descriptor where the objects make sense.
> David Jencks
> Sent from my iPhone
>
> On Dec 2, 2018, at 3:33 PM, David Blevins  wrote:
>
> >> On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu  wrote:
> >>
> >> Hi folks,
> >> I am working on the Java EE schema update to support Java EE 7 and Java
> EE8
> >> schemas which are specified in
> >>
> https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html
> >>
> >> Seems that two modules openejb-jee and openejb-jee-accessor modules are
> >> mostly updated by manually after generated by xjc compiler. Moreover, I
> did
> >> not able to find the any XJB binding file.
> >>
> >> In pom.xml, there is a plugin (jaxb2-maven-plugin) but seems that it is
> not
> >> working correctly.
> >> Do you have any comment on these modules? We need to generate codes
> >> automatically without updating any manual intervention.
> >>
> >> Currently we only support Java EE 6 schemas and using the trick
> (updating
> >> newer namespaces to Java EE 6 old namespace) and do not support Java EE7
> >> and 8 deployment descriptors.
> >>
> >> Here is the JIRA Issue:
> >> https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2306
> >
> > Hi Gurkan,
> >
> > I've added David Jencks to the thread in case he's around and wants to
> give some of his historical perspective.  He is retired and enjoying life,
> so I suspect he won't, but it never hurts.
> >
> > There's long pro-customization and anti-customization history on this
> topic between OpenEJB/Geronimo.  We've done it both ways in both projects,
> this is a rough timeline -- years are approximate:
> >
> > - OpenEJB & Geronimo anti-customization: 2003 - 2006
> > - OpenEJB pro-customization, Geronimo anti-customization 2006-2009
> > - OpenEJB & Geronimo pro-customization: 2009 onward
> >
> > There really is no easy answers without pain points.  Both project
> started as you say, generating automatically without any customizations,
> and committers on both projects eventually shifted away from it.  There's a
> trade-off and it comes down to where you want the benefits and where you're
> willing to live with the cost.  This is a high-level perspective of what we
> all noticed.
> >
> > - Read-only generated tree:
> >- pro: easy when schemas change once every 2-3 years
> >- con: inability to customize pushes complexity into consuming code
> year-round
> >
> > - Generated then customized tree:
> >- pro: increasingly easier to to consume year-round
> >- con: hard when schemas change once every 2-3 years
> >
> > The con of "Generated then customized tree" really only applies to
> existing schemas that change.  New schemas introduced can easily be
> generated.
> >
> > The story arch of this goes basically both OpenEJB and Geronimo used
> generated trees that were not checked into the source.  The pain points
> associated with that resulted in OpenEJB trying it differently when OpenEJB
> 3 was launched in 2006.  Geronimo kept with generated trees believing
> manually changing them was a mistake. After a few years on both projects
> and everyone having the experience with both approaches, Geronimo
> eventually removed it's generated tree and switched the whole server over
> to using the optimized OpenEJB JAXB tree.
> >
> > This topic comes up every few years when it is time to update the
> descriptors, which is completely natural.
> >
> > The topic of customized or not is particularly challenging when you
> don't control the schema.  There are a few terrible aspects of the Java EE
> schemas that make it really hard to work with "pure."
> >
> > - Created it's own String type
> > - No polymorphism/reuse for types like SessionBean, EntityBean,
> MessageDrivenBean
> > - Doesn't use enums many places where it should
> >
> > These are only a few highlights.  Some of the 

Re: Merging Old and New Websites

[Romain Manni-Bucau]

If it helps I have an antora setup ([1]) to generate another doc site with
most of these features - think only the day/night thing is missing, it uses
tags to manage versions - overridable by branches.

Side note: when we did the new site we decided to not merge with the old
one cause too much stuff was outdated and was causing issues, did you plan
to clean it now it has been merged?

[1] https://github.com/Talend/component-runtime/tree/master/documentation

Le dim. 2 déc. 2018 08:56, Alex The Rocker  a écrit :

> Hello David,
>
> Thanks for trying to make TomEE site more readable and accessible!
>
> I would like to suggest a few more enhancements to make this site as
> useful and easy to use as it deserves:
>
> 1.  This site must have navigation links, or better : breadcrumbs
> link, in all its pages.
>  Let me take an example: when I click on the link you gave as an
> example:
> http://tomee.apache.org/tomee-7.1/examples/application-composer.html,
> I arrive on a page which is missing the "context" : I should see that
> I am in a documentation page for TomEE version 7.1, subsection
> Examples, and I should be allowed to navigate from this page to "The
> root of all TomEE docs / The root of all TomEE 71 docs / The root of
> all Examples of TomEE 7.1 docs".
>  Alternative would be to show a TOC (Table Of Contents) next to
> all pages, but I personally find TOCs takes to much reading space,
> whereas breadcrumbs, if well designed (don't use too long identified
> for each "nesting") only take a short space, usual at the top of the
> displayed page (but under other navigation elements, like the Search
> bar, see #3 below).
>
> 2. It would be nice to have (not mandatory) a way to switch from
> version 7.1 of this page to 7.0 and 8.0.
>
> 3. A missing feature is a Search bar  in the top of all pages,
> allowing to search documentation / examples on TomEE site.
>
> 4. Would it be possible to add a "day / night switch button" ? (see
> the Sun/Moon icon at the top right hand side of this site:
> https://docs.influxdata.com/telegraf/v1.9/data_formats/template-patterns/
> ),
> I love this one, but it's a  matter of taste here :)
>
> 5. (hard) Access to the site from mobiles sucks, requires zooming.
> Ideally the styles should implement responsive web design to nicely
> fit pages in small displays.
>
> Disclaimer: I am not a web designer, but I've been participating to
> couple of design reviews...
>
> Kind regards,
> Alexandre
>
>
> Le dim. 2 déc. 2018 à 02:41, David Blevins  a
> écrit :
> >
> > Alright folks!
> >
> > Updated site published and with a refreshed CSS that is more readable.
> >
> >  - http://tomee.apache.org/tomee-7.1/examples/application-composer.html
> >  - http://tomee.apache.org/tomee-8.0/docs/configuring-javamail.html
> >
> > I'm attempting to get this to a point where we can crowd source some
> non-automatable tasks.  What I'm imaging we can all do in a divide and
> conquer fashion:
> >
> >  - Categorize each document for an intelligent looking index
> >  - Review each document for formatting issues
> >  - Convert markdown documents to asciidoc
> >  - Fix inconsistent h1, h2, h3 etc usage
> >  - Update branding to "TomEE" from "OpenEJB"
> >  - Ensure each has a title
> >  - Check links
> >
> > To get there I just need to 1) minimally improve the index pages to have
> groups and 2) add the jbake headers to all the files
> >
> > After that everyone can start hacking on docs too.  Then I'll move on to
> seeing if we can get javadoc generated and published as part of all this.
> Then we'll be able to reference them in our docs, which will be very handy
> and also provide some motivation to actually write javadoc in the first
> place :)
> >
> >
> > -David
> >
>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Le ven. 30 nov. 2018 à 18:23, César Hernández Mendoza 
a écrit :

> Hi all,
>
> Trying to keep the focus of this thread base on the "tangible" artifacts
> (Spec, TCK, etc).
>
> Correct me if I'm wrong but if currently the spec state YAML but the TCK is
> missing the test to enforce this.
> Then, in this case, I think we should fix first the TCK to comply with the
> spec as it's right now.
>

This is not the case but an utility in the TCK allows to bypass it but they
explicitly test yaml and json more or less everywhere.

The "yaml is the default" is explained by the tck, there are comments
explaining there is not standard mime type for yaml...so it must be the
default (I don't think it is the opposite way, it would have been
standardized the spec would have stated it 1-1 I assume)


>
> I see there are a couple of MP issues still open about this issue that can
> update or not later the fix in the TCK.
>
>
>
> [1] https://github.com/eclipse/microprofile-open-api/issues/228
> [2] https://github.com/eclipse/microprofile-open-api/issues/302
>
>
> El vie., 30 nov. 2018 a las 10:49, Romain Manni-Bucau (<
> rmannibu...@gmail.com>) escribió:
>
> > Le ven. 30 nov. 2018 à 17:45, Ivan Junckes Filho 
> a
> > écrit :
> >
> > > Just to be clear, this is not about a vendor opinion, it is my opinion
> > and
> > > the spec says that clearly so it is about a community opinion.
> > >
> > > Also see comments from other people from IBM and RedHat that
> participate
> > > actively in  the spec.
> > >
> > >
> >
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431889411
> > >
> > >
> >
> https://github.com/eclipse/microprofile-open-api/issues/302#issuecomment-443034856
> > >
> > >
> >
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431895833
> > >
> > >
> >
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-432038154
> > >
> > > When you say it is a 1 voice opinion that is not fair.
> > >
> >
> > Well it is all about vendors, was my point. Got very bad feedbacks cause
> > the platform is becoming inconsistent and broken cause each spec is done
> > independently of others and I share that very strongly
> > so I ensured all impl @geronimo don't impose it at users. Having used it
> > recently in softwares requiring some industrialization (I'm strongly
> > thinking to security scans here) I really appreciated to be able to drop
> > not used parts.
> >
> >
> > >
> > > This comment "I know the spec picked yaml for "other$" reasons." is
> also
> > > very offensive and may be wrong. I have been participating on those
> calls
> > > and anyone really is able to participate and help decide things in the
> > > spec.
> > >
> > > >> why is current impl not compliant?
> > >
> > > Like I said yaml is not default and that diverges from the spec. Adding
> > > yaml as default if we add jackson yaml won't make it default as well,
> it
> > > will be still an alternative.
> > >
> >
> > Ok, then this is this assumption which is wrong and where this thread
> > became split.
> >
> >
> > >
> > >
> > >
> > > On Fri, Nov 30, 2018 at 2:40 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Ok, will repeat a third time hoping it is a mail crossing issue: why
> is
> > > > current impl not compliant?
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le ven. 30 nov. 2018 à 17:34, Richard Monson-Haefel <
> > > > monsonhae...@gmail.com>
> > > > a écrit :
> > > >
> > > > > When you are setting up a MP Rest Client, there are certain
> > annotations
> > > > > that are required, right?  Is it possible to have the TomEE code
> > detect
> > > > 

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Le ven. 30 nov. 2018 à 17:45, Ivan Junckes Filho  a
écrit :

> Just to be clear, this is not about a vendor opinion, it is my opinion and
> the spec says that clearly so it is about a community opinion.
>
> Also see comments from other people from IBM and RedHat that participate
> actively in  the spec.
>
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431889411
>
> https://github.com/eclipse/microprofile-open-api/issues/302#issuecomment-443034856
>
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-431895833
>
> https://github.com/eclipse/microprofile-open-api/issues/228#issuecomment-432038154
>
> When you say it is a 1 voice opinion that is not fair.
>

Well it is all about vendors, was my point. Got very bad feedbacks cause
the platform is becoming inconsistent and broken cause each spec is done
independently of others and I share that very strongly
so I ensured all impl @geronimo don't impose it at users. Having used it
recently in softwares requiring some industrialization (I'm strongly
thinking to security scans here) I really appreciated to be able to drop
not used parts.


>
> This comment "I know the spec picked yaml for "other$" reasons." is also
> very offensive and may be wrong. I have been participating on those calls
> and anyone really is able to participate and help decide things in the
> spec.
>
> >> why is current impl not compliant?
>
> Like I said yaml is not default and that diverges from the spec. Adding
> yaml as default if we add jackson yaml won't make it default as well, it
> will be still an alternative.
>

Ok, then this is this assumption which is wrong and where this thread
became split.


>
>
>
> On Fri, Nov 30, 2018 at 2:40 PM Romain Manni-Bucau 
> wrote:
>
> > Ok, will repeat a third time hoping it is a mail crossing issue: why is
> > current impl not compliant?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 30 nov. 2018 à 17:34, Richard Monson-Haefel <
> > monsonhae...@gmail.com>
> > a écrit :
> >
> > > When you are setting up a MP Rest Client, there are certain annotations
> > > that are required, right?  Is it possible to have the TomEE code detect
> > > these MP annotations and change the default to yaml automatically?
> That
> > > way, yaml is only the default if you are communicating with
> MP-conformant
> > > systems.  Just looking for a compromise here.
> > >
> > > On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho <
> > ivanjunc...@gmail.com
> > > >
> > > wrote:
> > >
> > > > The goal for this is to implement Microprofile Specifications. So
> what
> > > the
> > > > Microprofile community decides is important and needs to be followed.
> > Of
> > > > course everyone has a voice there and you clearly spoke up there
> which
> > is
> > > > great. You think it is not the best approach, but people there until
> > now
> > > > think it is. So why not respect what they decide?
> > > >
> > > > It would be compatible if you put yaml by default and choose to make
> > json
> > > > default with a property. But making json default and adding extra
> > configs
> > > > to make yaml default is not what the spec defines.
> > > >
> > > > This is the standard:
> > > > "The default format of the /openapi endpoint is YAML.
> > > >
> > > > Anything different than this is what you think is the best and not a
> > > > consensus in the MicroProfile community. "Stupid" is a very personal
> > > > opinion and doesn't reflect what people think about it there, neither
> > my
> > > > opinion.
> > > >
> > > > I again, think we should follow what the standard is and change later
> > if
> > > > the community decides so.
> > > >
> > > > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > I don't understand why you say so Ivan, it is perfectly compatible.
> > > > >

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Ok, will repeat a third time hoping it is a mail crossing issue: why is
current impl not compliant?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 30 nov. 2018 à 17:34, Richard Monson-Haefel 
a écrit :

> When you are setting up a MP Rest Client, there are certain annotations
> that are required, right?  Is it possible to have the TomEE code detect
> these MP annotations and change the default to yaml automatically?  That
> way, yaml is only the default if you are communicating with MP-conformant
> systems.  Just looking for a compromise here.
>
> On Fri, Nov 30, 2018 at 10:25 AM Ivan Junckes Filho  >
> wrote:
>
> > The goal for this is to implement Microprofile Specifications. So what
> the
> > Microprofile community decides is important and needs to be followed. Of
> > course everyone has a voice there and you clearly spoke up there which is
> > great. You think it is not the best approach, but people there until now
> > think it is. So why not respect what they decide?
> >
> > It would be compatible if you put yaml by default and choose to make json
> > default with a property. But making json default and adding extra configs
> > to make yaml default is not what the spec defines.
> >
> > This is the standard:
> > "The default format of the /openapi endpoint is YAML.
> >
> > Anything different than this is what you think is the best and not a
> > consensus in the MicroProfile community. "Stupid" is a very personal
> > opinion and doesn't reflect what people think about it there, neither my
> > opinion.
> >
> > I again, think we should follow what the standard is and change later if
> > the community decides so.
> >
> > On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > I don't understand why you say so Ivan, it is perfectly compatible.
> > >
> > > Also to answer clearly to your question: I prefer to have an impl not
> > > compatible with the spec when the spec says something stupid, most of
> the
> > > time we put toggle to be able to be compatible but sometimes there is
> not
> > > even a way to be compatible, this is what has been done in TomEE since
> > > years and it works well making users happy rather than spec leads.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github
> > > <https://github.com/rmannibucau> | LinkedIn
> > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le ven. 30 nov. 2018 à 17:11, Ivan Junckes Filho <
> ivanjunc...@gmail.com>
> > > a écrit :
> > >
> > >> This is against the spec as well, yaml is required and must always be
> > >> default. Do we really want to let our implementation not compatible
> with
> > >> that?
> > >>
> > >> On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > >> wrote:
> > >>
> > >>> If jackson yaml is present it will add a (jackson) writer for yaml,
> if
> > >>> not it stays on json.
> > >>>
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >>> <https://rmannibucau.metawerx.net/> | Old Blog
> > >>> <http://rmannibucau.wordpress.com> | Github
> > >>> <https://github.com/rmannibucau> | LinkedIn
> > >>> <https://www.linkedin.com/in/rmannibucau> | Book
> > >>> <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >>>
> > >>>
> > >>> Le ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho <
> > ivanjunc...@gmail.com>
> > >>> a écrit :
> > >>>
> > >>>> @Romain Manni-Bucau  not sure I understood
> > you.
> > >>>> Are you saying you will work to make it compa

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Well, I don't aim to have an argument here but please also consider that I
can ask as well why you (not sure who is "people" cause I see mainly 1
voice here which vendor voice) woudln't respect user feedback which is
regularly pro json in several companies - I know the spec picked yaml for
"other$" reasons.

Also note that, as I mentionned, the implementation is now compliant to the
spec, so not really sure the follow up to give to that topic.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 30 nov. 2018 à 17:25, Ivan Junckes Filho  a
écrit :

> The goal for this is to implement Microprofile Specifications. So what the
> Microprofile community decides is important and needs to be followed. Of
> course everyone has a voice there and you clearly spoke up there which is
> great. You think it is not the best approach, but people there until now
> think it is. So why not respect what they decide?
>
> It would be compatible if you put yaml by default and choose to make json
> default with a property. But making json default and adding extra configs
> to make yaml default is not what the spec defines.
>
> This is the standard:
> "The default format of the /openapi endpoint is YAML.
>
> Anything different than this is what you think is the best and not a
> consensus in the MicroProfile community. "Stupid" is a very personal
> opinion and doesn't reflect what people think about it there, neither my
> opinion.
>
> I again, think we should follow what the standard is and change later if
> the community decides so.
>
> On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau 
> wrote:
>
>> I don't understand why you say so Ivan, it is perfectly compatible.
>>
>> Also to answer clearly to your question: I prefer to have an impl not
>> compatible with the spec when the spec says something stupid, most of the
>> time we put toggle to be able to be compatible but sometimes there is not
>> even a way to be compatible, this is what has been done in TomEE since
>> years and it works well making users happy rather than spec leads.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le ven. 30 nov. 2018 à 17:11, Ivan Junckes Filho 
>> a écrit :
>>
>>> This is against the spec as well, yaml is required and must always be
>>> default. Do we really want to let our implementation not compatible with
>>> that?
>>>
>>> On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>>
>>>> If jackson yaml is present it will add a (jackson) writer for yaml, if
>>>> not it stays on json.
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github
>>>> <https://github.com/rmannibucau> | LinkedIn
>>>> <https://www.linkedin.com/in/rmannibucau> | Book
>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>>>
>>>>
>>>> Le ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho 
>>>> a écrit :
>>>>
>>>>> @Romain Manni-Bucau  not sure I understood
>>>>> you. Are you saying you will work to make it compatible with the spec? 
>>>>> Have
>>>>> yaml as default?
>>>>>
>>>>> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
>>>>> cesargu...@gmail.com> wrote:
>>>>>
>>>>>> >
>>>>>> > I think regardless of what the MicroProfile team decides, we need
>>>>>> to make
>>>>>> > it work as the specification says. Then iterate from there.
>>>>>> > In my opinion this is a big problem that makes us strongly
>>>>>> incompatible
>>>>>>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

I don't understand why you say so Ivan, it is perfectly compatible.

Also to answer clearly to your question: I prefer to have an impl not
compatible with the spec when the spec says something stupid, most of the
time we put toggle to be able to be compatible but sometimes there is not
even a way to be compatible, this is what has been done in TomEE since
years and it works well making users happy rather than spec leads.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 30 nov. 2018 à 17:11, Ivan Junckes Filho  a
écrit :

> This is against the spec as well, yaml is required and must always be
> default. Do we really want to let our implementation not compatible with
> that?
>
> On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau 
> wrote:
>
>> If jackson yaml is present it will add a (jackson) writer for yaml, if
>> not it stays on json.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho 
>> a écrit :
>>
>>> @Romain Manni-Bucau  not sure I understood you.
>>> Are you saying you will work to make it compatible with the spec? Have yaml
>>> as default?
>>>
>>> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
>>> cesargu...@gmail.com> wrote:
>>>
>>>> >
>>>> > I think regardless of what the MicroProfile team decides, we need to
>>>> make
>>>> > it work as the specification says. Then iterate from there.
>>>> > In my opinion this is a big problem that makes us strongly
>>>> incompatible
>>>> > with the standard.
>>>>
>>>>
>>>> +1
>>>>
>>>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
>>>> ivanjunc...@gmail.com>)
>>>> escribió:
>>>>
>>>> > I think regardless of what the MicroProfile team decides, we need to
>>>> make
>>>> > it work as the specification says. Then iterate from there.
>>>> >
>>>> > In my opinion this is a big problem that makes us strongly
>>>> incompatible
>>>> > with the standard.
>>>> >
>>>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
>>>> rmannibu...@gmail.com>
>>>> > wrote:
>>>> >
>>>> > > Browser and all clients default to */* or octect/stream so the else
>>>> is
>>>> > > never used normally and was here just to put a mimetype from an
>>>> optional.
>>>> > >
>>>> > > Browsers even send a kind of "all you can" value (*/*, html, xml at
>>>> > least).
>>>> > >
>>>> > > So yes we can make this value confifurable but this never happens.
>>>> Ivan's
>>>> > > case was even with cxf client which sets a value normally by
>>>> default so
>>>> > it
>>>> > > wouldnt help I think.
>>>> > >
>>>> > > Le ven. 30 nov. 2018 06:21, John D. Ament  a
>>>> > écrit
>>>> > > :
>>>> > >
>>>> > > > The question posed to the MP team does not really match the
>>>> question
>>>> > > > posted here, and seems to be a tangental ask.
>>>> > > >
>>>> > > > The problem is this line of code [1], and nothing to do with
>>>> TomEE's
>>>> > > > behavior; it defaults to JSON even though the spec states it
>>>> should be
>>>> > > > YAML.  Perhaps a clean solution would be to make this a config
>>>> setting?
>>>> > > > But seems like there's a missing TCK test as well.  I'd also
>>>> question
>>>> > > when
>>>> > > > a browser goes here, what does it send in the Accepts hea

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

If jackson yaml is present it will add a (jackson) writer for yaml, if not
it stays on json.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho  a
écrit :

> @Romain Manni-Bucau  not sure I understood you.
> Are you saying you will work to make it compatible with the spec? Have yaml
> as default?
>
> On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <
> cesargu...@gmail.com> wrote:
>
>> >
>> > I think regardless of what the MicroProfile team decides, we need to
>> make
>> > it work as the specification says. Then iterate from there.
>> > In my opinion this is a big problem that makes us strongly incompatible
>> > with the standard.
>>
>>
>> +1
>>
>> El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<
>> ivanjunc...@gmail.com>)
>> escribió:
>>
>> > I think regardless of what the MicroProfile team decides, we need to
>> make
>> > it work as the specification says. Then iterate from there.
>> >
>> > In my opinion this is a big problem that makes us strongly incompatible
>> > with the standard.
>> >
>> > On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > Browser and all clients default to */* or octect/stream so the else is
>> > > never used normally and was here just to put a mimetype from an
>> optional.
>> > >
>> > > Browsers even send a kind of "all you can" value (*/*, html, xml at
>> > least).
>> > >
>> > > So yes we can make this value confifurable but this never happens.
>> Ivan's
>> > > case was even with cxf client which sets a value normally by default
>> so
>> > it
>> > > wouldnt help I think.
>> > >
>> > > Le ven. 30 nov. 2018 06:21, John D. Ament  a
>> > écrit
>> > > :
>> > >
>> > > > The question posed to the MP team does not really match the question
>> > > > posted here, and seems to be a tangental ask.
>> > > >
>> > > > The problem is this line of code [1], and nothing to do with TomEE's
>> > > > behavior; it defaults to JSON even though the spec states it should
>> be
>> > > > YAML.  Perhaps a clean solution would be to make this a config
>> setting?
>> > > > But seems like there's a missing TCK test as well.  I'd also
>> question
>> > > when
>> > > > a browser goes here, what does it send in the Accepts header.  My
>> guess
>> > > is
>> > > > most modern browsers send text/html which also wouldn't line up.
>> > > >
>> > > > John
>> > > >
>> > > > [1]:
>> > > >
>> > >
>> >
>> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>> > > >
>> > > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
>> > > rmannibu...@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
>> > > >> depends where you deploy it (i dont think implementing a custom
>> writer
>> > > for
>> > > >> that is right for users, it has too much pitfalls once integrated
>> to
>> > > >> anything else than this very specific spec).
>> > > >>
>> > > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>> > > >> jonathan.gallim...@gmail.com> a écrit :
>> > > >>
>> > > >>> If the spec requires that, then I'd expect to get a YAML response
>> if
>> > > >>> making a request without an `Accept` header on the request.
>> > > >>>
>> > > >>> I haven't looked through the microprofile-openapi TCK, but I'd
>> expect
>> > > >>> that to be tested, and I'd suggest contributing a test there if
>> there
>> > > isn't
>> > > >>> one.
>> > > >>>
>> > > >>> If you wanted to explicitly request a YAML response, I'd expect
>> one
>> > of
>> > > >>> these to work:
>> > > >>>
>> > > >>> Accept: application/x-yaml
>> > > >>> Accept: text/yaml
>> > > >>>
>> > > >>> I'd expect a Content-Type header on the response to identify the
>> mime
>> > > >>> type of the response, whatever is being returned.
>> > > >>>
>> > > >>> Jon
>> > > >>>
>> > > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>> > > >>> ivanjunc...@gmail.com> wrote:
>> > > >>>
>> > > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
>> > > >>>>
>> > > >>>> The spec says:
>> > > >>>> "The default format of the /openapi endpoint is YAML."
>> > > >>>>
>> > > >>>> But when I try to access /openapi it returns JSON by default.
>> > > >>>>
>> > > >>>> This is not correct.
>> > > >>>>
>> > > >>>> Also how can I access yaml if it is not default?
>> > > >>>>
>> > > >>>
>> > >
>> >
>>
>>
>> --
>> Atentamente:
>> César Hernández Mendoza.
>>
>

Re: Forking for new PRs

[Romain Manni-Bucau]

Hi Richard,

if you have 3 commit in your PR you create a single one "squashing" them 3
(or you can select just 2 if you want)

Some people are fan of it, some people hate it cause it break the history
and the "thinking" of the devs so you loose precious information (yes i'm
in this last partbeing said at the end you can't rely on the history
whatever effort you put in the writing of it). I have a colleague who is
quite interesting on that, he says "I squash 'fix typo' commits only".

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 30 nov. 2018 à 15:50, Richard Monson-Haefel 
a écrit :

> Hi,
>
> What does "Squashing your PR" mean?
>
> Thank you!
>
> Richard
>
> On Thu, Nov 29, 2018 at 5:00 PM exabrial12  wrote:
>
> > Also, if you don't mind Squashing your PR before submitting the request,
> > that
> > will help port anything to other branches!
> >
> >
> >
> > --
> > Sent from:
> > http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> >
>
>
> --
> Richard Monson-Haefel
> https://twitter.com/rmonson
> https://www.linkedin.com/in/monsonhaefel/
>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

I'll add */* for yaml endpoint to complement text/plain, this will solve
the ambiguity

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 30 nov. 2018 à 12:44, Ivan Junckes Filho  a
écrit :

> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
>
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.
>
> On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau 
> wrote:
>
>> Browser and all clients default to */* or octect/stream so the else is
>> never used normally and was here just to put a mimetype from an optional.
>>
>> Browsers even send a kind of "all you can" value (*/*, html, xml at
>> least).
>>
>> So yes we can make this value confifurable but this never happens. Ivan's
>> case was even with cxf client which sets a value normally by default so it
>> wouldnt help I think.
>>
>> Le ven. 30 nov. 2018 06:21, John D. Ament  a
>> écrit :
>>
>> > The question posed to the MP team does not really match the question
>> > posted here, and seems to be a tangental ask.
>> >
>> > The problem is this line of code [1], and nothing to do with TomEE's
>> > behavior; it defaults to JSON even though the spec states it should be
>> > YAML.  Perhaps a clean solution would be to make this a config setting?
>> > But seems like there's a missing TCK test as well.  I'd also question
>> when
>> > a browser goes here, what does it send in the Accepts header.  My guess
>> is
>> > most modern browsers send text/html which also wouldn't line up.
>> >
>> > John
>> >
>> > [1]:
>> >
>> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>> >
>> > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
>> >> depends where you deploy it (i dont think implementing a custom writer
>> for
>> >> that is right for users, it has too much pitfalls once integrated to
>> >> anything else than this very specific spec).
>> >>
>> >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>> >> jonathan.gallim...@gmail.com> a écrit :
>> >>
>> >>> If the spec requires that, then I'd expect to get a YAML response if
>> >>> making a request without an `Accept` header on the request.
>> >>>
>> >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
>> >>> that to be tested, and I'd suggest contributing a test there if there
>> isn't
>> >>> one.
>> >>>
>> >>> If you wanted to explicitly request a YAML response, I'd expect one of
>> >>> these to work:
>> >>>
>> >>> Accept: application/x-yaml
>> >>> Accept: text/yaml
>> >>>
>> >>> I'd expect a Content-Type header on the response to identify the mime
>> >>> type of the response, whatever is being returned.
>> >>>
>> >>> Jon
>> >>>
>> >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>> >>> ivanjunc...@gmail.com> wrote:
>> >>>
>> >>>> Hey guys, I think I found a bug in OpenAPI implementation.
>> >>>>
>> >>>> The spec says:
>> >>>> "The default format of the /openapi endpoint is YAML."
>> >>>>
>> >>>> But when I try to access /openapi it returns JSON by default.
>> >>>>
>> >>>> This is not correct.
>> >>>>
>> >>>> Also how can I access yaml if it is not default?
>> >>>>
>> >>>
>>
>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Browser and all clients default to */* or octect/stream so the else is
never used normally and was here just to put a mimetype from an optional.

Browsers even send a kind of "all you can" value (*/*, html, xml at least).

So yes we can make this value confifurable but this never happens. Ivan's
case was even with cxf client which sets a value normally by default so it
wouldnt help I think.

Le ven. 30 nov. 2018 06:21, John D. Ament  a écrit :

> The question posed to the MP team does not really match the question
> posted here, and seems to be a tangental ask.
>
> The problem is this line of code [1], and nothing to do with TomEE's
> behavior; it defaults to JSON even though the spec states it should be
> YAML.  Perhaps a clean solution would be to make this a config setting?
> But seems like there's a missing TCK test as well.  I'd also question when
> a browser goes here, what does it send in the Accepts header.  My guess is
> most modern browsers send text/html which also wouldn't line up.
>
> John
>
> [1]:
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>
> On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau 
> wrote:
>
>> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
>> depends where you deploy it (i dont think implementing a custom writer for
>> that is right for users, it has too much pitfalls once integrated to
>> anything else than this very specific spec).
>>
>> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> a écrit :
>>
>>> If the spec requires that, then I'd expect to get a YAML response if
>>> making a request without an `Accept` header on the request.
>>>
>>> I haven't looked through the microprofile-openapi TCK, but I'd expect
>>> that to be tested, and I'd suggest contributing a test there if there isn't
>>> one.
>>>
>>> If you wanted to explicitly request a YAML response, I'd expect one of
>>> these to work:
>>>
>>> Accept: application/x-yaml
>>> Accept: text/yaml
>>>
>>> I'd expect a Content-Type header on the response to identify the mime
>>> type of the response, whatever is being returned.
>>>
>>> Jon
>>>
>>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>>> ivanjunc...@gmail.com> wrote:
>>>
>>>> Hey guys, I think I found a bug in OpenAPI implementation.
>>>>
>>>> The spec says:
>>>> "The default format of the /openapi endpoint is YAML."
>>>>
>>>> But when I try to access /openapi it returns JSON by default.
>>>>
>>>> This is not correct.
>>>>
>>>> Also how can I access yaml if it is not default?
>>>>
>>>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Response is fine (thanks jaxrs), request is up to jaxrs runtime so depends
where you deploy it (i dont think implementing a custom writer for that is
right for users, it has too much pitfalls once integrated to anything else
than this very specific spec).

Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore 
a écrit :

> If the spec requires that, then I'd expect to get a YAML response if
> making a request without an `Accept` header on the request.
>
> I haven't looked through the microprofile-openapi TCK, but I'd expect that
> to be tested, and I'd suggest contributing a test there if there isn't one.
>
> If you wanted to explicitly request a YAML response, I'd expect one of
> these to work:
>
> Accept: application/x-yaml
> Accept: text/yaml
>
> I'd expect a Content-Type header on the response to identify the mime type
> of the response, whatever is being returned.
>
> Jon
>
> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho 
> wrote:
>
>> Hey guys, I think I found a bug in OpenAPI implementation.
>>
>> The spec says:
>> "The default format of the /openapi endpoint is YAML."
>>
>> But when I try to access /openapi it returns JSON by default.
>>
>> This is not correct.
>>
>> Also how can I access yaml if it is not default?
>>
>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Does not mean im not right ;)

Le jeu. 29 nov. 2018 20:33, Richard Monson-Haefel 
a écrit :

> Ivan is right. The default for MicroProfile is yaml. It would only be
> json if the accept heard specifies json.  Here is the exact wording from
> section 5.2
>
> "The default format of the /openapi endpoint is YAML.
>
> Vendors must also support the JSON format if the request contains an Accept
> header with a value of application/json, in which case the response must
> contain a Content-Type header with a value of application/json."
>
> On Thu, Nov 29, 2018 at 11:03 AM Ivan Junckes Filho  >
> wrote:
>
> > Hey Romain, take a look on:
> >
> >
> >
> https://download.eclipse.org/microprofile/microprofile-open-api-1.0/microprofile-openapi-spec.html#_content_format
> >
> > It is clear for me there, that the default should be yaml.
> >
> > On Thu, Nov 29, 2018 at 2:58 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hello Ivan,
> > >
> > > this is actually not exactly the case, the impl is writer agnostic and
> > > fully relies on JAXRS for that so if you have a body writer which
> matches
> > > OpenAPI and returns yaml by default or
> > > which prefer yaml over json then you will have the behavior you
> describe.
> > >
> > > To get yaml you can send the Accept header valued with yaml media type
> > > like "text/yaml" for some implementations.
> > >
> > > Side note: the impl does not impose any body writer to be integrable in
> > > any environment and does not enforce yaml as well cause it is not part
> of
> > > the core of microprofile (and hopefully will never be) so no reason to
> > > import a lib (which can be heavy and potentially with vulnerabilities +
> > > work for the users to maintain it) for that.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github
> > > <https://github.com/rmannibucau> | LinkedIn
> > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho <
> ivanjunc...@gmail.com>
> > > a écrit :
> > >
> > >> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>
> > >> The spec says:
> > >> "The default format of the /openapi endpoint is YAML."
> > >>
> > >> But when I try to access /openapi it returns JSON by default.
> > >>
> > >> This is not correct.
> > >>
> > >> Also how can I access yaml if it is not default?
> > >>
> > >
> >
>
>
> --
> Richard Monson-Haefel
> https://twitter.com/rmonson
> https://www.linkedin.com/in/monsonhaefel/
>

Re: Microprofile OpenAPI

[Romain Manni-Bucau]

Hello Ivan,

this is actually not exactly the case, the impl is writer agnostic and
fully relies on JAXRS for that so if you have a body writer which matches
OpenAPI and returns yaml by default or
which prefer yaml over json then you will have the behavior you describe.

To get yaml you can send the Accept header valued with yaml media type like
"text/yaml" for some implementations.

Side note: the impl does not impose any body writer to be integrable in any
environment and does not enforce yaml as well cause it is not part of the
core of microprofile (and hopefully will never be) so no reason to import a
lib (which can be heavy and potentially with vulnerabilities + work for the
users to maintain it) for that.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho  a
écrit :

> Hey guys, I think I found a bug in OpenAPI implementation.
>
> The spec says:
> "The default format of the /openapi endpoint is YAML."
>
> But when I try to access /openapi it returns JSON by default.
>
> This is not correct.
>
> Also how can I access yaml if it is not default?
>

Re: [TOMEE-2287] Histogram Prometheus Output

[Romain Manni-Bucau]

Hello Michael,

in prometheus, histograms are not represented directly like their class and
the prometheus representation is done through an endpoint and not a body
writer as per microprofile spec - can likely be enhanced but it is not
needed today since you rarely want a single metrics in the output (see
https://github.com/apache/geronimo-metrics/blob/master/geronimo-metrics-common/src/main/java/org/apache/geronimo/microprofile/metrics/common/prometheus/PrometheusFormatter.java#L140
for an impl)

Now, geronimo-metrics provides for you the prometheus endpoints so you
don't need to implement it on your side, did you set the system
property geronimo.metrics.jaxrs.activated=true
?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 28 nov. 2018 à 16:43, Ivan Junckes Filho  a
écrit :

> Hi Michael, could you please push it to a remote branch so I can take a
> look?
>
> On Wed, Nov 28, 2018 at 1:26 PM Michael Redlich  wrote:
>
> > Hello everyone:
> >
> > I am making progress implementing a Metrics Histogram example.  Please
> see
> > the following code:
> >
> > @Path("/histogram")
> > @GET
> > @Produces(MediaType.TEXT_PLAIN)
> > // @Produces(MediaType.APPLICATION_JSON)
> > public Histogram histogramStatus() {
> > Metadata metadata = new Metadata("items", MetricType.HISTOGRAM,
> > "degrees F");
> > metadata.setDescription("A histogram of recent temperatures.");
> > Histogram temps = metrics.histogram(metadata);
> > for(int temp = 80; temp < 100; ++temp) {
> > temps.update(temp);
> > }
> > return temps;
> > }
> >
> >
> > In APPLICATION_JSON mode (commented), the output is as expected. However,
> > in TEXT_MODE, I get the following message:
> >
> > No message body writer has been found for class
> > org.apache.geronimo.microprofile.metrics.impl.HistogramImpl,
> > ContentType: text/plain
> >
> > I haven't been able to find a way to correct this, especially since the
> > Counter Metric didn't require a body writer.
> >
> > I would appreciate any help.  Thanks!
> >
> > Mike.
> >
> > --
> > *Code*, *Write*, *Cycle*, *Run*, *Drink*,
> > *Sleep ... Repeat*
> >
> > *InfoQ <https://www.infoq.com/> Java Queue Editor*
> > https://about.me/mpredli <http://about.me/mpredli/>
> > https://twitter.com/mpredli
> > https://redlich.net/
> > https://javasig.org/
> > *Laissez Les Bon Temps Rouler*
> >
>

Re: Please review PR #214

[Romain Manni-Bucau]

Hello Bruno,

I put some suggestions on the PR, hope it helps.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 26 nov. 2018 à 18:02, Bruno Baptista  a écrit :

> Hi,
>
> I think the code for this example: TOMEE-2283 New Example: Websocket
> with TLS and Basic Auth <https://issues.apache.org/jira/browse/TOMEE-2283>
>
> Is ready for review here: https://github.com/apache/tomee/pull/214
>
> Can one of you please take a look?
>
> Cheers
>
> --
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
>

Re: Please review PR #201

[Romain Manni-Bucau]

@Bruno: note that this is not what we are doing, I'm just mentionning that
TomEE does not need that and that there is no need to put any pressure
either on TomEE or Geronimo in such situation since everything is good on
both side in current state.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 26 nov. 2018 à 17:05, Bruno Baptista  a écrit :

> It's just that I would expect to release 1.0.1 for a mater of principle.
>
> I think we shouldn't throw away an already approved valid contribution.
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 26/11/18 13:53, Romain Manni-Bucau wrote:
> > Le lun. 26 nov. 2018 à 14:48, Bruno Baptista  a
> écrit :
> >
> >> Hi Romain,
> >>
> >> We are holding other work with this discussion.
> >>
> >> Can we agree that this is good enough for a 1st version and move on with
> >> a follow up PR?... It's not going to be worse than starting SE tasks
> >> inside the container, like we have now.
> >>
> > As I said, while it is not released without being harnessed I'm happy
> > without any way working for you.
> >
> >
> >> Also, releasing Safegard 1.0.1 would be nice. There is unreleased code
> >> in there that this work needs. We can live with the SNAPSHOT in the
> >> meantime because there is no prediction of work for that SNAPSHOT.
> >>
> > I don't think there is anything needed, you can replace all that by a
> > standard cdi extension if the snapshot is bothering you can use the last
> > release.
> > Just veto the default and override the impl, no?
> >
> >
> >> Cheers.
> >>
> >> Bruno Baptista
> >> https://twitter.com/brunobat_
> >>
> >>
> >> On 23/11/18 15:41, Romain Manni-Bucau wrote:
> >>> Le ven. 23 nov. 2018 à 16:34, Bruno Baptista  a
> >> écrit :
> >>>> Hi Romain,
> >>>>
> >>>> About "The point is not the cdi bean but the executor. So high level
> you
> >>>> deploy an
> >>>> app not using safeguard but it being present and you ensure the
> >> container
> >>>> has no executor resource instantiated (you will get one (the
> facade))."
> >>>>
> >>>> Sorry Romain, I still don't understand how the code in the PR can
> >>>> possible affect something not using the FT API or Safeguard in
> >> particular.
> >>> I think the code is ok but it uses assumptions which are likely not
> >> obvious
> >>> and it is not tested so next commit will break it - since this code
> must
> >> be
> >>> reworked anyway - and you will not see it.
> >>> So better to ensure the build guarantee all the outcome we want for end
> >>> users.
> >>>
> >>>
> >>>> In relation to the Managed executor... What you say makes sense but I
> >>>> wonder how likely it is to happen and if it's enough to hold the PR.
> Do
> >>>> you have a custom executor example somewhere?
> >>>>
> >>> We have some in the core tests you can reuse. But long story short you
> >> run
> >>> your test, don't use safeguard and guarantee in @Test by looking up the
> >>> resource directly using internals (SystemInstance > ContainerSystem and
> >> so
> >>> on) that the instance is not yet instantiated. See for a test doing
> >> exactly
> >>> that:
> >>>
> >>
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/assembler/classic/LazyResourceTest.java#L41
> >>> To summarize:
> >>>
> >>> 1. CDI is lazy
> >>> 2. we define the default executor as being lazy
> >>> 3. we assume safeguard will not impact an app not using it
> >>>
> >>> ==> you must ensure that 3 didnt trigger an executor creation, it is
> fine
> >>> to rely on 1+2 (which means so "main" code)
> >>>
> >>>
> >>>> Cheers
> >>>>
> >>>> Bruno Baptista
> >>>> https://twitter.com/brunobat_
> >>>>
> >>>>
> >>>> On 23/11/18 15:14, Romain Manni-Bu

Re: Avoid String in a loop

[Romain Manni-Bucau]

+0 (this is only for error cases as far as i saw and a few concatenations
so you don't see the diff in practise + the compiler is able to optimize it
and even replace string builder when relevant these days)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 26 nov. 2018 à 15:38, Daniel Cunha  a écrit :

> Wowww!
>
> Nice catch Otávio!
> That is really a good improvement!
>
> Em seg, 26 de nov de 2018 às 10:47, Otávio Gonçalves de Santana <
> osant...@tomitribe.com> escreveu:
>
> > The reason to prefer StringBuilder is that both + and concat create a new
> > object every time you call them (provided the right-hand side argument is
> > not empty). This can quickly add up to a lot of objects, almost all of
> > which are completely unnecessary.
> >
> > public class Main{
> > public static void main(String[] args)
> > {
> > long now = System.currentTimeMillis();
> > slow();
> > System.out.println("slow elapsed " +
> > (System.currentTimeMillis() - now) + " ms");
> >
> > now = System.currentTimeMillis();
> > fast();
> > System.out.println("fast elapsed " +
> > (System.currentTimeMillis() - now) + " ms");
> > }
> >
> > private static void fast()
> > {
> > StringBuilder s = new StringBuilder();
> > for(int i=0;i<10;i++)
> > s.append("*");
> > }
> >
> > private static void slow()
> > {
> > String s = "";
> > for(int i=0;i<10;i++)
> > s+="*";
> > }
> > }
> >
> >
> >- slow elapsed 11741 ms
> >- fast elapsed 7 ms
> >
> > Also, this PR avoids unnecessary call in StringBuilder
> > Ref: https://github.com/apache/tomee/pull/219
> >
>
>
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
>

Re: Please review PR #201

[Romain Manni-Bucau]

Le lun. 26 nov. 2018 à 14:48, Bruno Baptista  a écrit :

> Hi Romain,
>
> We are holding other work with this discussion.
>
> Can we agree that this is good enough for a 1st version and move on with
> a follow up PR?... It's not going to be worse than starting SE tasks
> inside the container, like we have now.
>

As I said, while it is not released without being harnessed I'm happy
without any way working for you.


>
> Also, releasing Safegard 1.0.1 would be nice. There is unreleased code
> in there that this work needs. We can live with the SNAPSHOT in the
> meantime because there is no prediction of work for that SNAPSHOT.
>

I don't think there is anything needed, you can replace all that by a
standard cdi extension if the snapshot is bothering you can use the last
release.
Just veto the default and override the impl, no?


>
> Cheers.
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 23/11/18 15:41, Romain Manni-Bucau wrote:
> > Le ven. 23 nov. 2018 à 16:34, Bruno Baptista  a
> écrit :
> >
> >> Hi Romain,
> >>
> >> About "The point is not the cdi bean but the executor. So high level you
> >> deploy an
> >> app not using safeguard but it being present and you ensure the
> container
> >> has no executor resource instantiated (you will get one (the facade))."
> >>
> >> Sorry Romain, I still don't understand how the code in the PR can
> >> possible affect something not using the FT API or Safeguard in
> particular.
> >>
> > I think the code is ok but it uses assumptions which are likely not
> obvious
> > and it is not tested so next commit will break it - since this code must
> be
> > reworked anyway - and you will not see it.
> > So better to ensure the build guarantee all the outcome we want for end
> > users.
> >
> >
> >> In relation to the Managed executor... What you say makes sense but I
> >> wonder how likely it is to happen and if it's enough to hold the PR. Do
> >> you have a custom executor example somewhere?
> >>
> > We have some in the core tests you can reuse. But long story short you
> run
> > your test, don't use safeguard and guarantee in @Test by looking up the
> > resource directly using internals (SystemInstance > ContainerSystem and
> so
> > on) that the instance is not yet instantiated. See for a test doing
> exactly
> > that:
> >
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/assembler/classic/LazyResourceTest.java#L41
> >
> > To summarize:
> >
> > 1. CDI is lazy
> > 2. we define the default executor as being lazy
> > 3. we assume safeguard will not impact an app not using it
> >
> > ==> you must ensure that 3 didnt trigger an executor creation, it is fine
> > to rely on 1+2 (which means so "main" code)
> >
> >
> >> Cheers
> >>
> >> Bruno Baptista
> >> https://twitter.com/brunobat_
> >>
> >>
> >> On 23/11/18 15:14, Romain Manni-Bucau wrote:
> >>> Le ven. 23 nov. 2018 à 15:49, Bruno Baptista  a
> >> écrit :
> >>>> Hi Romain,
> >>>>
> >>>> Thanks for your comment.
> >>>>
> >>>> The class doing the resource injection is lazy loaded, specifically
> >>>> /FailsafeContainerExecutionManagerProvider/. I did verify it in
> >>>> development but no test was produced... And to say the truth I
> wouldn't
> >>>> know how to validate if a bean has already been loaded or not. Can you
> >>>> please provide a test example?
> >>>>
> >>> The point is not the cdi bean but the executor. So high level you
> deploy
> >> an
> >>> app not using safeguard but it being present and you ensure the
> container
> >>> has no executor resource instantiated (you will get one (the facade)).
> >>>
> >>>
> >>>> Please explain what do you mean by "MP-fault-tolerance executor for
> that
> >>>> case if noone exists". It will exist, that's the whole purpose of this
> >>>> PR. Can you please provide an example where a
> >>>> /ManagedScheduledExecutorService/ will not be present?
> >>>>
> >>> You can see it as "don't let it default to a random executor". This is
> >> the
> >>> current behavior. So here is what can happen:
> >>>
> >>> 1. The user doesnt use any executor -> it defaults -> it is ok

Re: Building TomEE, openejb-core, crashed test: org.apache.openejb.assembler.DeployerEjbTest

[Romain Manni-Bucau]

Hi Ferdi,

surefire got some "hiccup" in last versions, maybe try 3.0.0-M1 or or
2.22.1 which should work, if not the output dump can help sometimes to
identify if it is a memory issue or (more likely) another one.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 26 nov. 2018 à 08:25, Ferdi  a écrit :

> Hi,
>
> I've got the latest master from github and was trying to run `mvn clean
> install`, but I've got this error:
>
> [ERROR] Crashed tests:
> [ERROR] org.apache.openejb.assembler.DeployerEjbTest
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
> ExecutionException The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C ""C:\Program
> Files\Java\jdk1.8.0_161\jre\bin\java"
> -javaagent:C:\Users\Ferdi_S672\Documents\Personal\Projects\tomee\container\openejb-core/target/openejb-javaagent-8.0.0-SNAPSHOT.jar
>
> -Dopenejb.classloader.forced-skip=org.apache.openejb.jee.,org.apache.openejb.api.
>
> -Dopenejb.classloader.forced-load=org.apache.openejb -enableassertions
> -Dopenejb.descriptors.output.folder=./dump/
> -Dorg.apache.activemq.SERIALIZABLE_PACKAGES=org,java -jar
> C:\Users\FERDI_~1\AppData\Local\Temp\surefire925326680556375235\surefirebooter1103379934330427088.jar
>
> C:\Users\Ferdi_S672\AppData\Local\Temp\surefire925326680556375235
> 2018-11-26T14-39-15_252-jvmRun1 surefire1842635169862471047tmp
> surefire_521382701203330047466tmp"
> [ERROR] Process Exit Code: 0
> [ERROR] Crashed tests:
> [ERROR] org.apache.openejb.assembler.DeployerEjbTest
>
> The rest is in this gist:
> <https://gist.github.com/ferdisn/19d4d8d697d12f3c1bcc2787483b3b67>
>
> Has anyone found / seen this before? I've tried:
>
> 1. -Xmx1024m -XX:MaxPermSize=256m
> 2. -Xmx2048m -XX:MaxPermSize=512m
> 3. Change Surefire to 2.22
>
> My computer has 16 GB RAM, and plenty of space available during the run.
>

Re: Feedback as newbie

[Romain Manni-Bucau]

if you clone the repo i mentionned you can generate it locally and run it
over a http server for dev purposes locally (and guess what, it is a tomee
;)). You can then check it is the first one the valid one (
https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/community/index.adoc).
And yes we never used develop branch, only master.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le sam. 24 nov. 2018 à 17:17, César Hernández Mendoza 
a écrit :

> Hi Frankie,
>
> ... current docu pages
> > How can I tell which docu page is current, e.g. from:
> > *  http://tomee.apache.org/community/sources.html
> > <http://tomee.apache.org/community/sources.html>
> > *  http://tomee.apache.org/dev/source-code.html
> > <http://tomee.apache.org/dev/source-code.html>
>
>
>
> For me [1] is the valid one. [2] has already a message about "We have moved
> to GIT" but I agree with you that an improved message like "This page is no
> longer valid" and a link to the new Valid URL should be provided.
> I'm not aware of what the roadmap is for both websites we currently have,
> but having two sites is misleading. I think another Epic could be the
> migration of all the pages from the old website to the new website, but
> again, I don't have the context. I can take a look on Monday if nobody
> replies about the background.
>
>
> [1] http://tomee.apache.org/community/sources.html
> [2] http://tomee.apache.org/dev/source-code.html
>
>
> El sáb., 24 nov. 2018 a las 9:39, Frankie ()
> escribió:
>
> > I will be happy to generate a PR for the site if somebody could provide
> > information to answer the questions in my post ... ;-)Again the
> > questions:[1] Which one of the two
> > (http://tomee.apache.org/community/sources.html or Which one of the
> > following) is the right place? And what should happen with the other one?
> > At
> > least a hint should be added that its outdated and a link to the new
> > place?[2] Can somebody confirm, that the development for 8.0.0 is done in
> > the master branch? And explain what the branch "tomee-8.0.0-ML1-rel" is
> > for?
> >
> >
> >
> > --
> > Sent from:
> > http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>
>
>
> --
> Atentamente:
> César Hernández Mendoza.
>

Re: Feedback as newbie

[Romain Manni-Bucau]

Hello

Quick recommandation for such a very valuable feedback is to make it a
contribution doing a PR on http://github.com/apache/tomee-site-generator
and let tomee community promote it live asap. Also it encourages it to be
part of the community work quickly and avoid it to be lost.

This way you will also help next people who will register on the list later
;).

Website is what you look when you are lost, mails are there to share
ideas/work and get feedbacks. This is what can help to pick the right media
;).

Le sam. 24 nov. 2018 13:36, Richard Monson-Haefel 
a écrit :

> Hi Frankie,
>
> This information is gold!  I'm working on a document that will help people
> new to open source and the way that TomEE does open source. Right now its
> just talking about "what is enterprise computing" and how TomEE and open
> source in general play into that, but I plan to get into the nitty-gritty
> eventually.
>
> It would be great if you could continue to track the issues you encounter
> and the solutions.  Then, perhaps, you can help with the document I'm
> working on - not only in the narrative but also in a Troubleshooting
> section.  This effort is going to take longer than I thought but is
> important as you have probably already guessed.
>
> Richard
>
> On Sat, Nov 24, 2018 at 3:59 AM Frankie  wrote:
>
> > Did my first tiny contrubution yesterday and would like to share how it
> > felt
> > for me.
> >
> > First of all I have to say thanks for the great support and the fast
> reply
> > to posts on the TomEE Dev mailing list. I feel very comfortable and
> > welcomed
> > with that.
> >
> > There were some little points of struggle that caused unsureness. I would
> > like to take this as a chance to help to get the docu updated/improved so
> > that other newcomers can benefit - or to get hints where I should have
> > looked ... ;-)
> >
> > [1] current docu pages
> > How can I tell which docu page is current, e.g. from:
> > *  http://tomee.apache.org/community/sources.html
> > 
> > *  http://tomee.apache.org/dev/source-code.html
> > 
> >
> > [2] git workflow: howto find the correct branch
> > http://tomee.apache.org/dev/git.html <
> http://tomee.apache.org/dev/git.html>
> >
> > says:
> > * The 'develop' repository is the equivalent of the SVN trunk directory
> >=> branch "develop"? In github it is not active and the last commit on
> > this is dated march 2015 ... ?
> > * The 'master' repository is the equivalent of the SVN tags directory.
> >=> branch "master" seems to be the used for the actual developing on
> > Version 8.0.0?
> >=> Branches "tomee-7.1.x", "tomee-7.0.x" and "tomee-1.7.x" obvoiusly
> > used
> > for the matching versions
> >=> branch "tomee-8.0.0-ML1-rel"?
> > I read through some PRs to figure out that I had to use the master for
> > 8.0.0
> > ...
> >
> >
> >
> >
> > --
> > Sent from:
> > http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> >
>

Re: Write tests geronimo

[Romain Manni-Bucau]

Hi Ivan

TCK are in geronimo and they use arquillian, tomee just reapplies them to
check the packaging does not break anything and its classloading is fine as
well so you can write tests the same.




Le ven. 23 nov. 2018 19:51, Ivan Junckes Filho  a
écrit :

> Hello guys, I did a change on Geronimo Metrics.
> https://github.com/apache/geronimo-metrics/pull/2
>
> geronimo-metrics, as you are aware, is a library used in TomEE.
>
> I am wondering how can I write a test for my change. Writing a test in
> TomEE for this is very simple, but writing a test in geronimo I don't know
> how to do it.
>
> Basically what I need it to have an app, deploy it with a resource, call
> an endpoint annotated with @Gauge and check if the gauge metric works.
>
> https://github.com/apache/tomee/pull/213 (This does it in the TomEE side)
>
> I see some references to Meecrowave in the project as well, not sure how
> some tests use Meecrowave and if that is a pattern we should use there.
>
> The TCK for MicroProfile Metrics is on TomEE, so the other question is if
> we should just rely on the TCK or if we should not.
>
> Thanks.
>

Re: Metrics Gauge Example and Bug

[Romain Manni-Bucau]

https://github.com/apache/tomee/blob/4c7fd4af95983a92bef89dc598873310dd13dd2e/server/openejb-cxf-rs/src/test/java/org/apache/openejb/server/cxf/rs/johnzon/JsonbJaxrsProviderTest.java
was supposed to cover that

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 23 nov. 2018 à 16:58, Bruno Baptista  a écrit :

> We should probably add a test for that regression.
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 23/11/18 15:50, Ivan Junckes Filho wrote:
> > It worked, thanks man!
> >
> > On Fri, Nov 23, 2018 at 12:40 PM Roberto Cortez 
> wrote:
> >
> >> Yes, that was the issue. This should fix it:
> >>
> >>
> https://github.com/apache/tomee/commit/1bfb65a1837235f4e9ad4458f67aabcab5eff829
> >>
> >> Try to pull the code and test it again.
> >>
> >> Cheers,
> >> Roberto
> >>
> >> On 23 Nov 2018, at 14:14, Roberto Cortez  wrote:
> >>
> >> No point. I’ve found the issue:
> >>
> >> It’s here:
> >>
> >>
> https://github.com/tomitribe/tomee/commit/7f18f4bcfe64119b9001d5ac6bffeb7324987a37
> >>
> >> This commit reverted back the new JsonbProvider to the old
> JohnzonProvider.
> >>
> >> The fix should be just to replace one with another. Let me try it and
> test.
> >>
> >> Cheers,
> >> Roberto
> >>
> >> On 23 Nov 2018, at 12:06, Ivan Junckes Filho 
> >> wrote:
> >>
> >> I was using the current master.
> >>
> >> 1.1.9
> >>
> >> I will try to use the version Romain proposed and see how it works.
> >>
> >>
> >> On Thu, Nov 22, 2018 at 7:36 PM Roberto Cortez <
> >> radcor...@yahoo.com.invalid> wrote:
> >>
> >>> Hey,
> >>>
> >>> I think metrics doesn’t even run properly on TomEE 7.x because of CDI
> 2.0.
> >>>
> >>> Regarding the fail, I’m not sure what is wrong. I remember seeing that
> >>> before and I think it got fixed when we added the JsonB JAX-RS
> Provider.
> >>> Maybe there is a regression in some place.
> >>>
> >>> Cheers,
> >>> Roberto
> >>>
> >>>> On 22 Nov 2018, at 21:08, Romain Manni-Bucau 
> >>> wrote:
> >>>> Hi Ivan
> >>>>
> >>>> Do you use tomee 8 with johnzon 1.1.10? Works well on this one
> normally
> >>> if johnzon defaults are not broken. On tomee 7 you need to add jsonb ;)
> >>>> Le jeu. 22 nov. 2018 21:51, Ivan Junckes Filho  >>> <mailto:ivanjunc...@gmail.com>> a écrit :
> >>>> Also there are a lot of properties being returned on that payload that
> >>> are not needed like rate1, rate5... etc.
> >>>>
> >>>>
> >>>> On Thu, Nov 22, 2018 at 6:26 PM Ivan Junckes Filho <
> >>> ivanjunc...@gmail.com <mailto:ivanjunc...@gmail.com>> wrote:
> >>>> The issue with the TCK is because meter in the spec expects
> >>> fifteenMinRate instead of fifteenMinuteRate.
> >>>> Same apply for the other properties like fiveMin..oneMin..
> >>>>
> >>>> @JsonbProperty("fifteenMinRate") is probably being ignored.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Nov 22, 2018 at 5:46 PM Ivan Junckes Filho <
> >>> ivanjunc...@gmail.com <mailto:ivanjunc...@gmail.com>> wrote:
> >>>> Hey Romain, it is actually a mapping issue. I created the PR but the
> >>> microprofile metrics TCK seems to be broken on TomEE, so I am not sure
> if
> >>> the PR is reliable.
> >>>> https://github.com/apache/geronimo-metrics/pull/2 <
> >>> https://github.com/apache/geronimo-metrics/pull/2>
> >>>> I will try to check what is going on with the TCK on TomEE, if you
> have
> >>> any tips let me know.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Nov 21, 2018 at 7:59 PM Romain Manni-Bucau <
> >>> rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>> wrote:
> >>>> Hi Ivan
> >>>

Re: Please review PR #201

[Romain Manni-Bucau]

Le ven. 23 nov. 2018 à 16:34, Bruno Baptista  a écrit :

> Hi Romain,
>
> About "The point is not the cdi bean but the executor. So high level you
> deploy an
> app not using safeguard but it being present and you ensure the container
> has no executor resource instantiated (you will get one (the facade))."
>
> Sorry Romain, I still don't understand how the code in the PR can
> possible affect something not using the FT API or Safeguard in particular.
>

I think the code is ok but it uses assumptions which are likely not obvious
and it is not tested so next commit will break it - since this code must be
reworked anyway - and you will not see it.
So better to ensure the build guarantee all the outcome we want for end
users.


>
> In relation to the Managed executor... What you say makes sense but I
> wonder how likely it is to happen and if it's enough to hold the PR. Do
> you have a custom executor example somewhere?
>

We have some in the core tests you can reuse. But long story short you run
your test, don't use safeguard and guarantee in @Test by looking up the
resource directly using internals (SystemInstance > ContainerSystem and so
on) that the instance is not yet instantiated. See for a test doing exactly
that:
https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/assembler/classic/LazyResourceTest.java#L41

To summarize:

1. CDI is lazy
2. we define the default executor as being lazy
3. we assume safeguard will not impact an app not using it

==> you must ensure that 3 didnt trigger an executor creation, it is fine
to rely on 1+2 (which means so "main" code)


>
> Cheers
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 23/11/18 15:14, Romain Manni-Bucau wrote:
> > Le ven. 23 nov. 2018 à 15:49, Bruno Baptista  a
> écrit :
> >
> >> Hi Romain,
> >>
> >> Thanks for your comment.
> >>
> >> The class doing the resource injection is lazy loaded, specifically
> >> /FailsafeContainerExecutionManagerProvider/. I did verify it in
> >> development but no test was produced... And to say the truth I wouldn't
> >> know how to validate if a bean has already been loaded or not. Can you
> >> please provide a test example?
> >>
> > The point is not the cdi bean but the executor. So high level you deploy
> an
> > app not using safeguard but it being present and you ensure the container
> > has no executor resource instantiated (you will get one (the facade)).
> >
> >
> >> Please explain what do you mean by "MP-fault-tolerance executor for that
> >> case if noone exists". It will exist, that's the whole purpose of this
> >> PR. Can you please provide an example where a
> >> /ManagedScheduledExecutorService/ will not be present?
> >>
> > You can see it as "don't let it default to a random executor". This is
> the
> > current behavior. So here is what can happen:
> >
> > 1. The user doesnt use any executor -> it defaults -> it is ok
> > 2. The user uses one or more executors for his app -> it defaults to it
> ->
> > it messes up the app and does not have the expected setting
> >
> > Case 2 is important cause it can really make it not functional and even
> > lead to locks in some cases so better to not let it happen and just
> create
> > a safeguard executor if
> > the user didnt specify he wants safeguard to use the executor
> > "'mysafeguardexecutor".
> >
> > This is why the config is important and I mentionned it early even if it
> is
> > not the most sexy part to do, I agree.
> >
> >
> >> Cheers
> >>
> >> Bruno Baptista
> >> https://twitter.com/brunobat_
> >>
> >>
> >> On 23/11/18 14:39, Romain Manni-Bucau wrote:
> >>>> It's lazily loaded, so no worries on that regard.
> >>> What is "it" here? :)
> >>>
> >>> Conretely the bean instantiation yes cause it is normal scoped and the
> >>> resource too cause it is by default lazy in tomee (service-jar.xml) but
> >> it
> >>> is worth a test that prevent regression on that behavior IMHO, I didn't
> >>> catch on in the PR.
> >>>
> >>> Concretely in terms of container we can want to create a dedicated
> >>> MP-fault-tolerance executor for that case if noone exists and the user
> >>> didn't specify one cause this default behavior (cumulated with tomee
> >>> defaulting on @Resouce) will make this not reliable which is quite
> >>> ridiculous when you think abo

Re: Please review PR #201

[Romain Manni-Bucau]

Le ven. 23 nov. 2018 à 15:49, Bruno Baptista  a écrit :

> Hi Romain,
>
> Thanks for your comment.
>
> The class doing the resource injection is lazy loaded, specifically
> /FailsafeContainerExecutionManagerProvider/. I did verify it in
> development but no test was produced... And to say the truth I wouldn't
> know how to validate if a bean has already been loaded or not. Can you
> please provide a test example?
>

The point is not the cdi bean but the executor. So high level you deploy an
app not using safeguard but it being present and you ensure the container
has no executor resource instantiated (you will get one (the facade)).


>
> Please explain what do you mean by "MP-fault-tolerance executor for that
> case if noone exists". It will exist, that's the whole purpose of this
> PR. Can you please provide an example where a
> /ManagedScheduledExecutorService/ will not be present?
>

You can see it as "don't let it default to a random executor". This is the
current behavior. So here is what can happen:

1. The user doesnt use any executor -> it defaults -> it is ok
2. The user uses one or more executors for his app -> it defaults to it ->
it messes up the app and does not have the expected setting

Case 2 is important cause it can really make it not functional and even
lead to locks in some cases so better to not let it happen and just create
a safeguard executor if
the user didnt specify he wants safeguard to use the executor
"'mysafeguardexecutor".

This is why the config is important and I mentionned it early even if it is
not the most sexy part to do, I agree.


>
> Cheers
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 23/11/18 14:39, Romain Manni-Bucau wrote:
> >> It's lazily loaded, so no worries on that regard.
> > What is "it" here? :)
> >
> > Conretely the bean instantiation yes cause it is normal scoped and the
> > resource too cause it is by default lazy in tomee (service-jar.xml) but
> it
> > is worth a test that prevent regression on that behavior IMHO, I didn't
> > catch on in the PR.
> >
> > Concretely in terms of container we can want to create a dedicated
> > MP-fault-tolerance executor for that case if noone exists and the user
> > didn't specify one cause this default behavior (cumulated with tomee
> > defaulting on @Resouce) will make this not reliable which is quite
> > ridiculous when you think about it for something about failt tolerance.
> > This is why it should be in before next release. Now if you do the PR
> next
> > week it is fine, was not to do it today but to ensure it is not merged
> and
> > the enthusiasm makes it forgotten.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le ven. 23 nov. 2018 à 15:18, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> a écrit :
> >
> >> Maybe add those config options in a second PR? What do you think?
> >>
> >> Jon
> >>
> >> On Fri, Nov 23, 2018 at 2:01 PM Bruno Baptista 
> wrote:
> >>
> >>> Hi Romain,
> >>>
> >>> In the end I decided to simply use the server default, for now.
> >>>
> >>> It will only be used if annotations are called in the code. It's lazily
> >>> loaded, so no worries on that regard.
> >>>
> >>> Cheers.
> >>>
> >>> Bruno Baptista
> >>> https://twitter.com/brunobat_
> >>>
> >>>
> >>> On 23/11/18 12:31, Romain Manni-Bucau wrote:
> >>>> Didnt you want to make the pool configurable and not instantiated if
> >> not
> >>>> used?
> >>>>
> >>>> Le ven. 23 nov. 2018 13:20, Daniel Cunha  a
> >>> écrit :
> >>>>> Hey Bruno,
> >>>>>
> >>>>> awesome! It really sounds good! I just push my +1 :)
> >>>>>
> >>>>> Em sex, 23 de nov de 2018 às 06:44, Bruno Baptista <
> >> bruno...@gmail.com>
> >>>>> escreveu:
> >>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> Additionally, I've requested a Safeguard 1.0.1 release. we shouldn't
> >> be

Re: Please review PR #201

[Romain Manni-Bucau]

> It's lazily loaded, so no worries on that regard.

What is "it" here? :)

Conretely the bean instantiation yes cause it is normal scoped and the
resource too cause it is by default lazy in tomee (service-jar.xml) but it
is worth a test that prevent regression on that behavior IMHO, I didn't
catch on in the PR.

Concretely in terms of container we can want to create a dedicated
MP-fault-tolerance executor for that case if noone exists and the user
didn't specify one cause this default behavior (cumulated with tomee
defaulting on @Resouce) will make this not reliable which is quite
ridiculous when you think about it for something about failt tolerance.
This is why it should be in before next release. Now if you do the PR next
week it is fine, was not to do it today but to ensure it is not merged and
the enthusiasm makes it forgotten.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 23 nov. 2018 à 15:18, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> Maybe add those config options in a second PR? What do you think?
>
> Jon
>
> On Fri, Nov 23, 2018 at 2:01 PM Bruno Baptista  wrote:
>
> > Hi Romain,
> >
> > In the end I decided to simply use the server default, for now.
> >
> > It will only be used if annotations are called in the code. It's lazily
> > loaded, so no worries on that regard.
> >
> > Cheers.
> >
> > Bruno Baptista
> > https://twitter.com/brunobat_
> >
> >
> > On 23/11/18 12:31, Romain Manni-Bucau wrote:
> > > Didnt you want to make the pool configurable and not instantiated if
> not
> > > used?
> > >
> > > Le ven. 23 nov. 2018 13:20, Daniel Cunha  a
> > écrit :
> > >
> > >> Hey Bruno,
> > >>
> > >> awesome! It really sounds good! I just push my +1 :)
> > >>
> > >> Em sex, 23 de nov de 2018 às 06:44, Bruno Baptista <
> bruno...@gmail.com>
> > >> escreveu:
> > >>
> > >>> Thanks!
> > >>>
> > >>> Additionally, I've requested a Safeguard 1.0.1 release. we shouldn't
> be
> > >>> using snapshots.
> > >>>
> > >>> Cheers
> > >>>
> > >>> Bruno Baptista
> > >>> https://twitter.com/brunobat_
> > >>>
> > >>>
> > >>> On 22/11/18 19:30, Roberto Cortez wrote:
> > >>>> Cool! Thank you.
> > >>>>
> > >>>> I’ll have a look.
> > >>>>
> > >>>>> On 22 Nov 2018, at 19:08, Bruno Baptista 
> wrote:
> > >>>>>
> > >>>>> Hi!
> > >>>>>
> > >>>>> I think the code is ready. Can some of you please review this pull
> > >>> request:
> > >>>>> https://github.com/apache/tomee/pull/201
> > >>>>>
> > >>>>> Related to:TOMEE-2278 <
> > >> https://issues.apache.org/jira/browse/TOMEE-2278>-
> > >>> Use Managed Executor with Safeguard Fault Tolerance lib
> > >>>>> Cheers.
> > >>>>>
> > >>>>> --
> > >>>>> Bruno Baptista
> > >>>>> https://twitter.com/brunobat_
> > >>>>>
> > >>>>>
> > >>
> > >> --
> > >> Daniel "soro" Cunha
> > >> https://twitter.com/dvlc_
> > >>
> >
>

Re: MicroProfile rest client example

[Romain Manni-Bucau]

Hi César

Not sure the snapshot was deployed, maybe build it locally
JL's fix does not change that error which is an outdated api in the server.

Le ven. 23 nov. 2018 03:58, César Hernández Mendoza 
a écrit :

> Hi,
> I updated my PR [1], the previous exception is no longer appearing since
> I'm not showing a Programmatic Standalone MicroProfile RestClient.
>
> I'm still using Tomee remote and Deployment(testable=true) [2]
>
> I feel I'm close to having a concrete example but now I'm facing a new
> issue which I need help and/or advice:
>
> * The tests run fine from the IDE (IntelliJ)
>
> * But after doing on a terminal: mvn clean test I got  this error (Complete
> stack trace [4]): java.lang.NoSuchMethodError:
>
> org.eclipse.microprofile.rest.client.RestClientBuilder.baseUri(Ljava/net/URI;)Lorg/eclipse/microprofile/rest/client/RestClientBuilder;
>
> * After investing some time trying to see where the issue was, I found that
> if I change in my pom.xml the version of arquillian-tomee-remote   from
> 8.0.0-SNAPSHOT   to   8.0.0-M1 , the issue disappears and both IDE and
> maven clean test runs without any issue.
>
> * @Jean-Louis, I see we had a recent commit on master for
> arquillian-tomee-remote
> [3], tomorrow I´m planning to revert the Commit and check if that fixes the
> current issue, but if the issue I´m having is an expected behavior, can you
> please take a quick look and let me know if I´m missing something.
>
>
> [1]
>
> https://github.com/cesarhernandezgt/tomee/commit/6179cdc8f654e9bfaec29e276ed999d9bfca3388#diff-cf40b757e6a74b3ffcfa2462457e3201R44
> [2]
>
> https://github.com/cesarhernandezgt/tomee/blob/mp-rest-client-example/examples/mp-rest-client/src/test/java/org/superbiz/rest/BookResourceTest.java#L19
> [3]
>
> https://github.com/apache/tomee/commit/7e33681b48562138efe41219b7c8f6e499bf8506#diff-a66043deab99db291cb46640c07dd3a5
> [4] java.lang.NoSuchMethodError:
>
> org.eclipse.microprofile.rest.client.RestClientBuilder.baseUri(Ljava/net/URI;)Lorg/eclipse/microprofile/rest/client/RestClientBuilder;
>
> at
> org.apache.cxf.microprofile.client.cdi.RestClientBean.create(RestClientBean.java:95)
> at
> org.apache.webbeans.component.third.ThirdpartyBeanImpl.create(ThirdpartyBeanImpl.java:97)
> at
> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:68)
> at
> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:125)
> at
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:813)
> at
> org.apache.webbeans.container.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:673)
> at
> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:100)
> at
> org.apache.webbeans.inject.InjectableField.doInjection(InjectableField.java:65)
> at
> org.apache.webbeans.portable.InjectionTargetImpl.injectFields(InjectionTargetImpl.java:227)
> at
> org.apache.webbeans.portable.InjectionTargetImpl.inject(InjectionTargetImpl.java:213)
> at
> org.apache.webbeans.portable.InjectionTargetImpl.inject(InjectionTargetImpl.java:203)
> at org.apache.webbeans.inject.OWBInjector.inject(OWBInjector.java:56)
> at
> org.apache.openejb.arquillian.common.enrichment.OpenEJBEnricher.doInject(OpenEJBEnricher.java:131)
> at
> org.apache.openejb.arquillian.common.enrichment.OpenEJBEnricher.enrich(OpenEJBEnricher.java:100)
> at
> org.apache.openejb.arquillian.common.TomEEInjectionEnricher.enrich(TomEEInjectionEnricher.java:52)
> at
> org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at
> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at
> org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at
> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at
> org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> 

Re: Metrics Gauge Example and Bug

[Romain Manni-Bucau]

Hi Ivan

Do you use tomee 8 with johnzon 1.1.10? Works well on this one normally if
johnzon defaults are not broken. On tomee 7 you need to add jsonb ;)

Le jeu. 22 nov. 2018 21:51, Ivan Junckes Filho  a
écrit :

> Also there are a lot of properties being returned on that payload that are
> not needed like rate1, rate5... etc.
>
>
>
> On Thu, Nov 22, 2018 at 6:26 PM Ivan Junckes Filho 
> wrote:
>
>> The issue with the TCK is because meter in the spec
>> expects fifteenMinRate instead of fifteenMinuteRate.
>>
>> Same apply for the other properties like fiveMin..oneMin..
>>
>> @JsonbProperty("fifteenMinRate") is probably being ignored.
>>
>>
>>
>>
>> On Thu, Nov 22, 2018 at 5:46 PM Ivan Junckes Filho 
>> wrote:
>>
>>> Hey Romain, it is actually a mapping issue. I created the PR but the
>>> microprofile metrics TCK seems to be broken on TomEE, so I am not sure if
>>> the PR is reliable.
>>> https://github.com/apache/geronimo-metrics/pull/2
>>>
>>> I will try to check what is going on with the TCK on TomEE, if you have
>>> any tips let me know.
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Nov 21, 2018 at 7:59 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>>
>>>> Hi Ivan
>>>>
>>>> It is a bug in tomee scanning I think
>>>>
>>>>
>>>> Le mer. 21 nov. 2018 21:35, Ivan Junckes Filho 
>>>> a
>>>> écrit :
>>>>
>>>> > Hey guys, I was writing an example of metrics gauge (WIP).
>>>> >
>>>> > https://github.com/apache/tomee/pull/213
>>>> >
>>>> > And I found a bug when trying access a gauge with "Accept:
>>>> > application/json".
>>>> >
>>>> > Just to let you know that I will work on a fix for this:
>>>> >
>>>> > 21-Nov-2018 17:24:08.811 WARNING [http-nio-8080-exec-4]
>>>> > org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare
>>>> Both
>>>> >
>>>> org.apache.geronimo.microprofile.metrics.common.jaxrs.MetricsEndpoints#getJson
>>>> > and
>>>> >
>>>> org.apache.geronimo.microprofile.metrics.jaxrs.CdiMetricsEndpoints#getJson
>>>> > are equal candidates for handling the current request which can lead
>>>> to
>>>> > unpredictable results
>>>> > 21-Nov-2018 17:26:52.183 SEVERE [http-nio-8080-exec-4]
>>>> > org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem
>>>> Problem with
>>>> > writing the data, class java.util.Collections$SingletonMap,
>>>> ContentType:
>>>> > application/json
>>>> > 21-Nov-2018 17:26:52.184 WARNING [http-nio-8080-exec-4]
>>>> > org.apache.cxf.phase.PhaseInterceptorChain.doDefaultLogging
>>>> Interceptor for
>>>> > {
>>>> >
>>>> http://jaxrs.common.metrics.microprofile.geronimo.apache.org/}MetricsEndpoints
>>>> > has thrown exception, unwinding now
>>>> >  org.apache.cxf.interceptor.Fault
>>>> > at
>>>> >
>>>> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleWriteException(JAXRSOutInterceptor.java:396)
>>>> > at
>>>> >
>>>> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(JAXRSOutInterceptor.java:272)
>>>> > at
>>>> >
>>>> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:122)
>>>> > at
>>>> >
>>>> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRSOutInterceptor.java:84)
>>>> > at
>>>> >
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>>>> > at
>>>> >
>>>> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:90)
>>>> > at
>>>> >
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
>>>> > at
>>>> >
>>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
>>>> > at
>>>> >
>>>> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
>>>> &

Re: TOMEE-2253 - tomee.sh -version not working properly with Java 11

[Romain Manni-Bucau]

Hi Daniel,

Cause there are some commands using a webapp like classloader and it would
fail in this mode in general - we have the same hack for tomee embedded i
think, just not triggered the same way.
Feel free to revisit it and unify it with what you are doing. Likely what
was planned:
https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/SystemClassPath.java#L33
and
https://github.com/apache/tomee/blob/master/container/openejb-loader/src/main/java/org/apache/openejb/loader/SystemClassPath.java#L66.
This is why i mentionned you shouldnt modify the classloader by default at
the beginning of the review and just reuse the system classpath. The
intention was to make this custom loader behave the same as the child first
one but guess it was never aligned.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 22 nov. 2018 à 14:24, Daniel Cunha  a écrit :

> Hi Romain,
>
> I get your point now...
> Question: Why do we need to do it[1]?
>
> if (loader != null) {
> Thread.currentThread().setContextClassLoader(loader);
> if (loader != ClassLoader.getSystemClassLoader()) {
>
> System.setProperty("openejb.classloader.first.disallow-system-loading",
> "true");
> }
> }
>
>
> Do we really need to change it? Why?
> I believe which the CLI has you owner classpath and we don't need to change
> the default on to execute our commands. Just try understand why we are
> doing it.
>
> [1]
>
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/cli/Bootstrap.java#L151-L156
>
> Em ter, 20 de nov de 2018 às 17:32, Daniel Cunha 
> escreveu:
>
> > Hi Romain,
> >
> > Ok, I'll create a scenario for it.
> >
> > Thank you.
> >
> > Em ter, 20 de nov de 2018 às 17:29, Romain Manni-Bucau <
> > rmannibu...@gmail.com> escreveu:
> >
> >> Hi Daniel
> >>
> >> Do you think you can assert the classloader in the execution thread
> didnt
> >> change after the call? Was one concern and i didnt find the matching
> >> assert
> >>
> >> Le mar. 20 nov. 2018 20:00, Daniel Cunha  a
> écrit
> >> :
> >>
> >> > Hi folks,
> >> >
> >> > I've added a new test with JAXRS, calling a command in my endpoint
> from
> >> > Bootstrap CLI.
> >> > Please review the changes on my PR[1] and let me know what do you
> think
> >> > about it.
> >> >
> >> > Thank you. :)
> >> >
> >> > [1] https://github.com/apache/tomee/pull/176
> >> >
> >> > Em seg, 19 de nov de 2018 às 13:57, Daniel Cunha <
> daniels...@gmail.com>
> >> > escreveu:
> >> >
> >> > > Hi Jon,
> >> > >
> >> > > ok. I got it! :)
> >> > >
> >> > > Em seg, 19 de nov de 2018 às 13:49, Jonathan Gallimore <
> >> > > jonathan.gallim...@gmail.com> escreveu:
> >> > >
> >> > >> On Mon, Nov 19, 2018 at 4:30 PM Daniel Cunha  >
> >> > >> wrote:
> >> > >>
> >> > >> > Hi guys,
> >> > >> >
> >> > >> > I updated the PR with some chages:
> >> > >> > 1 - Move BasicURLClassPath.CustomizableURLClassLoader to be
> public.
> >> > >> > 2 - I'm using BasicURLClassPath.CustomizableURLClassLoader
> instead
> >> of
> >> > >> > DynamicClassLoader (class that I created)
> >> > >> > 3- DynamicClassLoader is not needed anymore. Was removed from the
> >> PR.
> >> > >> > 3 - Added more tests:
> >> > >> > - Standalone client that has its own main and delegates to
> the
> >> CLI
> >> > >> main
> >> > >> > - As above, but perhaps with the standalone client creating a
> >> > >> > classloader
> >> > >> > with the CLI jars and then launching it
> >> > >> >
> >> > >> > Question:
> >> > >> >
> >> > >> > @Jon,
> >> > >> > what do you want me mean with: A webapp calling commands in the
> >> CLI?
> >

Re: Metrics Gauge Example and Bug

[Romain Manni-Bucau]

Hi Ivan

It is a bug in tomee scanning I think


Le mer. 21 nov. 2018 21:35, Ivan Junckes Filho  a
écrit :

> Hey guys, I was writing an example of metrics gauge (WIP).
>
> https://github.com/apache/tomee/pull/213
>
> And I found a bug when trying access a gauge with "Accept:
> application/json".
>
> Just to let you know that I will work on a fix for this:
>
> 21-Nov-2018 17:24:08.811 WARNING [http-nio-8080-exec-4]
> org.apache.cxf.jaxrs.model.OperationResourceInfoComparator.compare Both
> org.apache.geronimo.microprofile.metrics.common.jaxrs.MetricsEndpoints#getJson
> and
> org.apache.geronimo.microprofile.metrics.jaxrs.CdiMetricsEndpoints#getJson
> are equal candidates for handling the current request which can lead to
> unpredictable results
> 21-Nov-2018 17:26:52.183 SEVERE [http-nio-8080-exec-4]
> org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem Problem with
> writing the data, class java.util.Collections$SingletonMap, ContentType:
> application/json
> 21-Nov-2018 17:26:52.184 WARNING [http-nio-8080-exec-4]
> org.apache.cxf.phase.PhaseInterceptorChain.doDefaultLogging Interceptor for
> {
> http://jaxrs.common.metrics.microprofile.geronimo.apache.org/}MetricsEndpoints
> has thrown exception, unwinding now
>  org.apache.cxf.interceptor.Fault
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleWriteException(JAXRSOutInterceptor.java:396)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(JAXRSOutInterceptor.java:272)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:122)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRSOutInterceptor.java:84)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:90)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at
> org.apache.openejb.server.cxf.rs.CxfRsHttpListener.doInvoke(CxfRsHttpListener.java:253)
> at
> org.apache.tomee.webservices.CXFJAXRSFilter.doFilter(CXFJAXRSFilter.java:94)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.apache.openejb.server.httpd.EEFilter.doFilter(EEFilter.java:65)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.tomee.microprofile.jwt.MPJWTFilter.doFilter(MPJWTFilter.java:64)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.geronimo.microprofile.opentracing.microprofile.server.OpenTracingFilter.doFilter(OpenTracingFilter.java:126)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:44)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
> at
> org.apache.tomee.catalina.OpenEJBSecurityListener$RequestCapturer.invoke(OpenEJBSecurityListener.java:97)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:668)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770)
> at
> 

Re: Is there someone looking for Microprofile Reactive at TomEE?

[Romain Manni-Bucau]

Hi Jon,

basically just implement a "pipeline" (like java stream with backpressure)
enabling to "fill" the spec todos. It would have like 4-5 primitives
allowing to impl all the spec. Then it is just "Impl" classes to fill.

FYI i pushed on my github earlier this morning a PoC using java streams and
showing it does not work that well:
https://github.com/rmannibucau/geronimo-reactive-streams

Main goals would be to not require scala (hope this is a joke ;)), make it
work in EE land (rxjava does not with its schedulers tools) and keep it
very light and dependency free since the spec does nothing much compared to
the jvm itself.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 21 nov. 2018 à 11:22, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> I'm new to this, and reading through the documentation, so apologies if
> this is a silly question. What would you be specifically looking for in
> terms of a "light implementation" - would that be an alternative to Akka
> Streams, RxJava and Reactor? Are there particular principles, goals or
> designs you had in mind?
>
> Cheers
>
> Jon
>
> On Wed, Nov 21, 2018 at 6:49 AM Romain Manni-Bucau 
> wrote:
>
> > Ok so MP decided to be bloated as the old ee so we will get a light impl
> > @geronimo - likely next year. Anyone wants to lead it since you asked?
> >
> > Le mar. 20 nov. 2018 13:44, Romain Manni-Bucau  a
> > écrit :
> >
> > > Hi Otavio,
> > >
> > > none yet and the existing ones are either bloated or don't integrate
> well
> > > in any existing stack :(
> > >
> > > FYI the reason it is not @geronimo:
> > > https://github.com/eclipse/microprofile/issues/57
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github
> > > <https://github.com/rmannibucau> | LinkedIn
> > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le mar. 20 nov. 2018 à 13:14, Bruno Baptista  a
> > > écrit :
> > >
> > >> Hi Otávio!
> > >>
> > >> Not on TomEE, have you looked in the Geronimo Side?
> > >>
> > >> +1 to work on reactive streams. If you want help, I can join.
> > >>
> > >> Cheers
> > >>
> > >> Bruno Baptista
> > >> http://twitter.com/brunobat_
> > >>
> > >>
> > >> On 20/11/18 12:07, Otávio Gonçalves de Santana wrote:
> > >> > Hello everyone, at the Eclipse Microprofile world there are a lot of
> > >> > implementations that TomEE covers, but, I did not find the
> > >> implementation
> > >> > to microprofile-reactive-streams
> > >> > <https://github.com/eclipse/microprofile-reactive-streams>.
> > >> >
> > >> > Does someone know if this Job has started at the TomEE side?
> > >> > If not, what is the best way to start this initiative?
> > >> >
> > >>
> > >
> >
>

Re: Is there someone looking for Microprofile Reactive at TomEE?

[Romain Manni-Bucau]

Ok so MP decided to be bloated as the old ee so we will get a light impl
@geronimo - likely next year. Anyone wants to lead it since you asked?

Le mar. 20 nov. 2018 13:44, Romain Manni-Bucau  a
écrit :

> Hi Otavio,
>
> none yet and the existing ones are either bloated or don't integrate well
> in any existing stack :(
>
> FYI the reason it is not @geronimo:
> https://github.com/eclipse/microprofile/issues/57
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mar. 20 nov. 2018 à 13:14, Bruno Baptista  a
> écrit :
>
>> Hi Otávio!
>>
>> Not on TomEE, have you looked in the Geronimo Side?
>>
>> +1 to work on reactive streams. If you want help, I can join.
>>
>> Cheers
>>
>> Bruno Baptista
>> http://twitter.com/brunobat_
>>
>>
>> On 20/11/18 12:07, Otávio Gonçalves de Santana wrote:
>> > Hello everyone, at the Eclipse Microprofile world there are a lot of
>> > implementations that TomEE covers, but, I did not find the
>> implementation
>> > to microprofile-reactive-streams
>> > <https://github.com/eclipse/microprofile-reactive-streams>.
>> >
>> > Does someone know if this Job has started at the TomEE side?
>> > If not, what is the best way to start this initiative?
>> >
>>
>

Re: Microprofile Metrics Example

[Romain Manni-Bucau]

Well it was not a big issue bit something to take care. The pr - not yet
merged - is way more impacting users and kind of justifies to not use MP
today :(.

Le mar. 20 nov. 2018 22:39, César Hernández Mendoza 
a écrit :

> Hi Romain,
>
> Did you test passing accept header or just in the browser which sends json
> > and text as acceptable value so resolution can be not that deterministic
> > using it - but this is the request so all fine ;).
>
>
> Yes, yesterday my test was performed using safari and that was causing the
> behaviour I describe in my previous email.
> Today I build tested again and did some test using curl and the Accept
> header and I didn't find any issue. Thanks for the help.
>
> The last side note is prometheus does not support monotonic=false (small
> > glitch in the spec).
>
> Interesting, It seems this is been fixed for microprofile metrics 2.x
> release [1] [2] as we are speaking.
>
> [1] https://github.com/eclipse/microprofile-metrics/pull/309
> [2] https://github.com/eclipse/microprofile-metrics/issues/290
>
>
> El lun., 19 nov. 2018 a las 23:52, Romain Manni-Bucau (<
> rmannibu...@gmail.com>) escribió:
>
> > Hi César,
> >
> > Did you test passing accept header or just in the browser which sends
> json
> > and text as acceptable value so resolution can be not that deterministic
> > using it - but this is the request so all fine ;).
> >
> > The last side note is prometheus does not support monotonic=false (small
> > glitch in the spec).
> >
> > Le mar. 20 nov. 2018 03:12, César Hernández Mendoza <
> cesargu...@gmail.com>
> > a écrit :
> >
> > > Hi Ivan, nice job with this example.
> > >
> > > I found another potential issue with the metrics in TomEE, If you
> remove
> > > the `monotonic = true` from the @Counted annotation, then the format of
> > the
> > > endpoint: http://localhost:8080/rest-mp-metrics/metrics is no longer
> > > Prometheus but JSON instead.
> > >
> > >
> > > Without `monotonic = true`
> > >
> > >
> > >
> >
> {"application":{"message_counter":0},"vendor":{"startTime":1542679115312},"base":{"classloader.totalLoadedClass.count":8971,"thread.count":39,"classloader.currentLoadedClass.count":8971,"jvm.uptime":103050,"gc.PS
> > >
> > >
> >
> MarkSweep.count":2,"thread.max.count":39,"memory.committedHeap":369098752,"gc.PS
> > >
> > >
> >
> Scavenge.count":7,"cpu.availableProcessors":4,"thread.daemon.count":38,"classloader.totalUnloadedClass.count":8971,"memory.maxHeap":3817865216,"memory.usedHeap":69535960,"gc.PS
> > > MarkSweep.time":141,"gc.PS Scavenge.time":103}}
> > >
> > >
> > >
> > > With `monotonic = true`
> > >
> > > # TYPE application:message_counter counter
> > > application:message_counter 0.0
> > > # TYPE base:classloader_total_loaded_class_count counter
> > > base:classloader_total_loaded_class_count 8839.0
> > > # TYPE base:thread_count counter
> > > base:thread_count 39.0
> > > # TYPE base:classloader_current_loaded_class_count counter
> > > base:classloader_current_loaded_class_count 8847.0
> > > # TYPE base:jvm_uptime_seconds gauge
> > > base:jvm_uptime_seconds 0.006427
> > > # TYPE base:gc_ps_mark_sweep_count counter
> > > base:gc_ps_mark_sweep_count 2.0
> > > # TYPE base:gc_ps_scavenge_count counter
> > > base:gc_ps_scavenge_count 7.0
> > > # TYPE base:memory_committed_heap_bytes gauge
> > > base:memory_committed_heap_bytes 3.70147328E8
> > > # TYPE base:thread_max_count counter
> > > base:thread_max_count 39.0
> > > # TYPE base:cpu_available_processors gauge
> > > base:cpu_available_processors 4.0
> > > # TYPE base:thread_daemon_count counter
> > > base:thread_daemon_count 38.0
> > > # TYPE base:classloader_total_unloaded_class_count counter
> > > base:classloader_total_unloaded_class_count 8847.0
> > > # TYPE base:memory_max_heap_bytes gauge
> > > base:memory_max_heap_bytes 3.817865216E9
> > > # TYPE base:gc_ps_mark_sweep_time_seconds gauge
> > > base:gc_ps_mark_sweep_time_seconds 1.19E-4
> > > # TYPE base:memory_used_heap_bytes gauge
> > > base:memory_used_heap_bytes 6.7481504E7
> > > # TYPE base:gc_ps_scavenge_time_seconds gauge
> > > base:gc_ps_scavenge_time_seconds 1.09E-4
> > > # TYPE vendor:start_time counter
> > > vendor:start_time 1.542679428814E12
> > >
> > >
> > > This is not stated on the MP metrics spec. So I wonder if TomEE should
> > > provide a set of properties to avoid these random behaviors.
> > >
> > >
> > > El lun., 19 nov. 2018 a las 13:51, Ivan Junckes Filho (<
> > > ivanjunc...@gmail.com>) escribió:
> > >
> > > > Hey guys, just to let you know that I created a Microprofile Metrics
> > > > Example under Tomee.
> > > >
> > > > I am still working on that and I will provide more test scenarios.
> > > >
> > > > Here is the PR if you want to review the work so far:
> > > > https://github.com/apache/tomee/pull/203
> > > >
> > > > Feel free to merge if you think this can be done incrementally.
> > > >
> > >
> > >
> > > --
> > > Atentamente:
> > > César Hernández Mendoza.
> > >
> >
>
>
> --
> Atentamente:
> César Hernández Mendoza.
>

Re: TOMEE-2253 - tomee.sh -version not working properly with Java 11

[Romain Manni-Bucau]

Hi Daniel

Do you think you can assert the classloader in the execution thread didnt
change after the call? Was one concern and i didnt find the matching assert

Le mar. 20 nov. 2018 20:00, Daniel Cunha  a écrit :

> Hi folks,
>
> I've added a new test with JAXRS, calling a command in my endpoint from
> Bootstrap CLI.
> Please review the changes on my PR[1] and let me know what do you think
> about it.
>
> Thank you. :)
>
> [1] https://github.com/apache/tomee/pull/176
>
> Em seg, 19 de nov de 2018 às 13:57, Daniel Cunha 
> escreveu:
>
> > Hi Jon,
> >
> > ok. I got it! :)
> >
> > Em seg, 19 de nov de 2018 às 13:49, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> escreveu:
> >
> >> On Mon, Nov 19, 2018 at 4:30 PM Daniel Cunha 
> >> wrote:
> >>
> >> > Hi guys,
> >> >
> >> > I updated the PR with some chages:
> >> > 1 - Move BasicURLClassPath.CustomizableURLClassLoader to be public.
> >> > 2 - I'm using BasicURLClassPath.CustomizableURLClassLoader instead of
> >> > DynamicClassLoader (class that I created)
> >> > 3- DynamicClassLoader is not needed anymore. Was removed from the PR.
> >> > 3 - Added more tests:
> >> > - Standalone client that has its own main and delegates to the CLI
> >> main
> >> > - As above, but perhaps with the standalone client creating a
> >> > classloader
> >> > with the CLI jars and then launching it
> >> >
> >> > Question:
> >> >
> >> > @Jon,
> >> > what do you want me mean with: A webapp calling commands in the CLI?
> >> >
> >>
> >> Hopefully I can answer that one in a straightforward way :). Try
> creating
> >> a
> >> servlet that loads the Bootstrap CLI class, and invokes some methods.
> >> Effectively you'd be calling the TomEE command line commands from a
> >> servlet. That use case hadn't occurred to me, but it sounds like one
> worth
> >> trying.
> >>
> >> That would probably need to sit
> >> under
> arquillian/arquillian-tomee-tests/arquillian-tomee-webprofile-tests.
> >>
> >> Jon
> >>
> >>
> >> >
> >> > Command is a class with main method, if I've it deployed in my library
> >> > folder, it should works fine, I just need to create a instance and
> call
> >> the
> >> > main.
> >> > Same will be if I try execute it with Process (that is exactly what we
> >> are
> >> > testing).
> >> >
> >> > Em sex, 2 de nov de 2018 às 07:53, Jonathan Gallimore <
> >> > jonathan.gallim...@gmail.com> escreveu:
> >> >
> >> > > I'm following this thread with some interest. What would be some
> good
> >> > tests
> >> > > to make sure these cases are covered off? Some suggestions in
> >> addition to
> >> > > the existing test:
> >> > >
> >> > > * Standalone client that has its own main and delegates to the CLI
> >> main
> >> > > * As above, but perhaps with the standalone client creating a
> >> classloader
> >> > > with the CLI jars and then launching it
> >> > > * A webapp calling commands in the CLI
> >> > >
> >> > > Any others? These are interesting use cases that I hadn't
> considered -
> >> > this
> >> > > is interesting.
> >> > >
> >> > > Jon
> >> > >
> >> > >
> >> > >
> >> > > On Wed, Oct 31, 2018 at 2:30 PM Romain Manni-Bucau <
> >> > rmannibu...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Le mer. 31 oct. 2018 à 14:52, Daniel Cunha 
> a
> >> > > écrit
> >> > > > :
> >> > > >
> >> > > > > Em seg, 29 de out de 2018 às 14:01, Jonathan Gallimore <
> >> > > > > jonathan.gallim...@gmail.com> escreveu:
> >> > > > >
> >> > > > > > We should write a test case for both of these, and agree on
> >> them.
> >> > I'd
> >> > > > > like
> >> > > > > > to be able to merge this in with confidence, and without the
> >> tests
> >> > I
> >> > > > > don't
> >> > > > > > see how we can do that.
> >> > > > > >
> &

Re: About TomEE Twitter account

[Romain Manni-Bucau]

What about a bot polling tweets in a github repo - with a scheduled date
for instance? Then PR would be welcomed ;). Just needs a server (or even a
free heroku pby or openshift).

Le mar. 20 nov. 2018 18:57, David Blevins  a
écrit :

> I would trust Mark Struberg with access to the twitter account to use
> impartially.  Anyone with access to that account would need to intimately
> understand Apache's marketing and trademark policies.  Otherwise it's kids
> playing with matches.
>
> A little more access could be good to help breath some life into it.  I'd
> be hesitant to throw the floodgates open and risk seeing it used in
> appropriately.
>
>
> -David
>
> > On Nov 20, 2018, at 7:30 AM, César Hernández Mendoza <
> cesargu...@gmail.com> wrote:
> >
> > Hi,
> >
> > The last post from TomEE Twitter account [1] was on July 13th 2017, in
> 2016
> > there were no posts at all.
> >
> > Is there a process to generate content on this twitter account?
> >
> > I think at least we could be posting when:
> >
> >   -  A new release is available
> >   - New content is generated by the community like tutorials, articles,
> >   etc.
> >   - General announcement from the project
> >
> >
> > [1] https://twitter.com/ApacheTomEE
> >
> > --
> > Atentamente:
> > César Hernández Mendoza.
>
>

Re: Is there someone looking for Microprofile Reactive at TomEE?

[Romain Manni-Bucau]

Hi Otavio,

none yet and the existing ones are either bloated or don't integrate well
in any existing stack :(

FYI the reason it is not @geronimo:
https://github.com/eclipse/microprofile/issues/57

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 20 nov. 2018 à 13:14, Bruno Baptista  a écrit :

> Hi Otávio!
>
> Not on TomEE, have you looked in the Geronimo Side?
>
> +1 to work on reactive streams. If you want help, I can join.
>
> Cheers
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 20/11/18 12:07, Otávio Gonçalves de Santana wrote:
> > Hello everyone, at the Eclipse Microprofile world there are a lot of
> > implementations that TomEE covers, but, I did not find the implementation
> > to microprofile-reactive-streams
> > <https://github.com/eclipse/microprofile-reactive-streams>.
> >
> > Does someone know if this Job has started at the TomEE side?
> > If not, what is the best way to start this initiative?
> >
>

Re: TomEE 8 - Next steps

[Romain Manni-Bucau]

Probably worth a read:


http://tomee-openejb.979440.n4.nabble.com/VOTE-next-tomee-version-targetting-EE-7-td4674650.html
http://tomee-openejb.979440.n4.nabble.com/Java-EE-version-Alignment-Troubles-td4674796.html

And related if you still feel motivated by reading after these pages ;)

Le mar. 20 nov. 2018 00:16, Roberto Cortez  a
écrit :

> Nevermind, that was just a discussion because I had the idea that the
> Jakarta EE version was going to reset. This is not the case, so doesn’t
> make sense anymore.
>
> > On 19 Nov 2018, at 23:08, exabrial12  wrote:
> >
> > Roberto, I'd advise to stick to https://semver.org semantics:
> >
> > It's worth a read at the link, but:
> >
> > major.minor.patch
> >
> > * major is API breaking changes, so removing an API or class
> > * minor is adding a new API or feature, or marking a public API as
> > deprecated, in a non-breaking manner
> > * patch is bug fixing, non-breaking unless functionality was incorrect
> >
> >
> >
> >
> > --
> > Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>
>

Re: Microprofile Metrics Example

[Romain Manni-Bucau]

Hi César,

Did you test passing accept header or just in the browser which sends json
and text as acceptable value so resolution can be not that deterministic
using it - but this is the request so all fine ;).

The last side note is prometheus does not support monotonic=false (small
glitch in the spec).

Le mar. 20 nov. 2018 03:12, César Hernández Mendoza 
a écrit :

> Hi Ivan, nice job with this example.
>
> I found another potential issue with the metrics in TomEE, If you remove
> the `monotonic = true` from the @Counted annotation, then the format of the
> endpoint: http://localhost:8080/rest-mp-metrics/metrics is no longer
> Prometheus but JSON instead.
>
>
> Without `monotonic = true`
>
>
> {"application":{"message_counter":0},"vendor":{"startTime":1542679115312},"base":{"classloader.totalLoadedClass.count":8971,"thread.count":39,"classloader.currentLoadedClass.count":8971,"jvm.uptime":103050,"gc.PS
>
> MarkSweep.count":2,"thread.max.count":39,"memory.committedHeap":369098752,"gc.PS
>
> Scavenge.count":7,"cpu.availableProcessors":4,"thread.daemon.count":38,"classloader.totalUnloadedClass.count":8971,"memory.maxHeap":3817865216,"memory.usedHeap":69535960,"gc.PS
> MarkSweep.time":141,"gc.PS Scavenge.time":103}}
>
>
>
> With `monotonic = true`
>
> # TYPE application:message_counter counter
> application:message_counter 0.0
> # TYPE base:classloader_total_loaded_class_count counter
> base:classloader_total_loaded_class_count 8839.0
> # TYPE base:thread_count counter
> base:thread_count 39.0
> # TYPE base:classloader_current_loaded_class_count counter
> base:classloader_current_loaded_class_count 8847.0
> # TYPE base:jvm_uptime_seconds gauge
> base:jvm_uptime_seconds 0.006427
> # TYPE base:gc_ps_mark_sweep_count counter
> base:gc_ps_mark_sweep_count 2.0
> # TYPE base:gc_ps_scavenge_count counter
> base:gc_ps_scavenge_count 7.0
> # TYPE base:memory_committed_heap_bytes gauge
> base:memory_committed_heap_bytes 3.70147328E8
> # TYPE base:thread_max_count counter
> base:thread_max_count 39.0
> # TYPE base:cpu_available_processors gauge
> base:cpu_available_processors 4.0
> # TYPE base:thread_daemon_count counter
> base:thread_daemon_count 38.0
> # TYPE base:classloader_total_unloaded_class_count counter
> base:classloader_total_unloaded_class_count 8847.0
> # TYPE base:memory_max_heap_bytes gauge
> base:memory_max_heap_bytes 3.817865216E9
> # TYPE base:gc_ps_mark_sweep_time_seconds gauge
> base:gc_ps_mark_sweep_time_seconds 1.19E-4
> # TYPE base:memory_used_heap_bytes gauge
> base:memory_used_heap_bytes 6.7481504E7
> # TYPE base:gc_ps_scavenge_time_seconds gauge
> base:gc_ps_scavenge_time_seconds 1.09E-4
> # TYPE vendor:start_time counter
> vendor:start_time 1.542679428814E12
>
>
> This is not stated on the MP metrics spec. So I wonder if TomEE should
> provide a set of properties to avoid these random behaviors.
>
>
> El lun., 19 nov. 2018 a las 13:51, Ivan Junckes Filho (<
> ivanjunc...@gmail.com>) escribió:
>
> > Hey guys, just to let you know that I created a Microprofile Metrics
> > Example under Tomee.
> >
> > I am still working on that and I will provide more test scenarios.
> >
> > Here is the PR if you want to review the work so far:
> > https://github.com/apache/tomee/pull/203
> >
> > Feel free to merge if you think this can be done incrementally.
> >
>
>
> --
> Atentamente:
> César Hernández Mendoza.
>

Re: Override bean from library on TomEE

[Romain Manni-Bucau]

Le lun. 19 nov. 2018 17:58, Bruno Baptista  a écrit :

> Thanks Romain,
>
> It's good to know. Where is that configuration?
>

https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/resources/default.exclusions
and
https://github.com/apache/tomee/commit/23f44b17e6ab504561f32aa4ae92f2521e07261e


> However, the problem is before that... The test with the interceptor,
> somehow fails to load the alternative, which has me very puzzled.
>
> Cheers.
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 19/11/18 16:45, Romain Manni-Bucau wrote:
> > Le lun. 19 nov. 2018 à 16:59, Roberto Cortez  >
> > a écrit :
> >
> >> Hi,
> >>
> >> We had that project before, and we ended up dropping with the
> >> justification that the libs should handle all of that.
> >>
> >> Not saying not to do it and I just don’t want to see code being blocked
> >> again for the same reason :)
> >>
> >> Cheers,
> >> Roberto
> >>
> >>> On 19 Nov 2018, at 15:31, Bruno Baptista  wrote:
> >>>
> >>> Hi Romain,
> >>>
> >>> In relation to the name of the lib to be /geronimo-safeguard-tomee/
> >> instead of /tomee-microprofile-common/ I would advise against it
> because we
> >> can put other overrides and utility classes on it instead of creating a
> >> single lib for every particular spec/need.
> >>
> > Point was more that geronimo-* are scanned and not tomee-*, so was more
> > technical than semantic ;) - i'm almost happy if you call it
> > "makeitwork.jar" :D.
> >
> >
> >>> Feedback is appreciated on the intended scope and name of that library.
> >> Let's see what's the opinion of the community over it.
> >>> In relation to the /DefaultManagedScheduledExecutorService/
> >> configuration, you are right. Will add it as soon as the injection
> mystery
> >> is solved. Any feedback on the injection of the alternative bean will be
> >> appreciated because I'm kind of stuck now.
> >>> Cheers
> >>>
> >>> Bruno Baptista
> >>> http://twitter.com/brunobat_
> >>>
> >>>
> >>> On 19/11/18 15:13, Romain Manni-Bucau wrote:
> >>>> rename the lib geronimo-safeguard-tomee or include the common MP jar
> in
> >> the
> >>>> scanned modules?
> >>>>
> >>>> side note: i mentionned it @geronimo: you likely don't want to
> hardcode
> >> a
> >>>> default name which will either be replaced by another one, not be the
> >>>> default one or not be controllable by the user (
> >>>> DefaultManagedScheduledExecutorService) so probably use tomee to
> inject
> >> a
> >>>> configuration (@Resource MicroprofileConfiguration config; in your
> >> common
> >>>> module) and then lookup the instance using tomee internal
> >> (containersystem
> >>>> -> jndicontext? for instance). Not a big thing but if not done users
> >> will
> >>>> have to code this bean themselves to control it I think.
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>>
> >>>> Le lun. 19 nov. 2018 à 15:24, Bruno Baptista  a
> >> écrit :
> >>>>> Hi All,
> >>>>>
> >>>>> I created a PR to make the discussion easier. It's here:
> >>>>> https://github.com/apache/tomee/pull/201
> >>>>>
> >>>>> There's another problem with the alternative bean implementation.
> After
> >>>>> including the SafeguardInterceptor in the test, the bean,
> >>>>> FailsafeContainerExecutionManagerProvider, is never picked up.
> >>>>>
> >>>>> I've played a bit with the priorities of both the interceptor and the
> >>>>> alternative without success.
> >>>>>
> >>>>> We still need to figure out a CDI extension to activate the code on
> >>>>> TomEE, but first, the 

Re: Override bean from library on TomEE

[Romain Manni-Bucau]

Le lun. 19 nov. 2018 à 16:59, Roberto Cortez 
a écrit :

> Hi,
>
> We had that project before, and we ended up dropping with the
> justification that the libs should handle all of that.
>
> Not saying not to do it and I just don’t want to see code being blocked
> again for the same reason :)
>
> Cheers,
> Roberto
>
> > On 19 Nov 2018, at 15:31, Bruno Baptista  wrote:
> >
> > Hi Romain,
> >
> > In relation to the name of the lib to be /geronimo-safeguard-tomee/
> instead of /tomee-microprofile-common/ I would advise against it because we
> can put other overrides and utility classes on it instead of creating a
> single lib for every particular spec/need.
>

Point was more that geronimo-* are scanned and not tomee-*, so was more
technical than semantic ;) - i'm almost happy if you call it
"makeitwork.jar" :D.


> >
> > Feedback is appreciated on the intended scope and name of that library.
> Let's see what's the opinion of the community over it.
> >
> > In relation to the /DefaultManagedScheduledExecutorService/
> configuration, you are right. Will add it as soon as the injection mystery
> is solved. Any feedback on the injection of the alternative bean will be
> appreciated because I'm kind of stuck now.
> >
> > Cheers
> >
> > Bruno Baptista
> > http://twitter.com/brunobat_
> >
> >
> > On 19/11/18 15:13, Romain Manni-Bucau wrote:
> >> rename the lib geronimo-safeguard-tomee or include the common MP jar in
> the
> >> scanned modules?
> >>
> >> side note: i mentionned it @geronimo: you likely don't want to hardcode
> a
> >> default name which will either be replaced by another one, not be the
> >> default one or not be controllable by the user (
> >> DefaultManagedScheduledExecutorService) so probably use tomee to inject
> a
> >> configuration (@Resource MicroprofileConfiguration config; in your
> common
> >> module) and then lookup the instance using tomee internal
> (containersystem
> >> -> jndicontext? for instance). Not a big thing but if not done users
> will
> >> have to code this bean themselves to control it I think.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >>
> >>
> >> Le lun. 19 nov. 2018 à 15:24, Bruno Baptista  a
> écrit :
> >>
> >>> Hi All,
> >>>
> >>> I created a PR to make the discussion easier. It's here:
> >>> https://github.com/apache/tomee/pull/201
> >>>
> >>> There's another problem with the alternative bean implementation. After
> >>> including the SafeguardInterceptor in the test, the bean,
> >>> FailsafeContainerExecutionManagerProvider, is never picked up.
> >>>
> >>> I've played a bit with the priorities of both the interceptor and the
> >>> alternative without success.
> >>>
> >>> We still need to figure out a CDI extension to activate the code on
> >>> TomEE, but first, the existing test has to work on it's own.
> >>>
> >>> Cheers.
> >>>
> >>> Bruno Baptista
> >>> http://twitter.com/brunobat_
> >>>
> >>>
> >>> On 19/11/18 10:56, Bruno Baptista wrote:
> >>>> Hi Jon,
> >>>>
> >>>> I'm not sure what would be the right way to load that code.
> >>>>
> >>>> But now that you mention it, a CDI extension sounds the proper way to
> >>>> do it. The code now loads properly. Thanks!
> >>>>
> >>>> Will create a PR soon.
> >>>>
> >>>> Bruno Baptista
> >>>> http://twitter.com/brunobat_
> >>>>
> >>>>
> >>>> On 19/11/18 10:41, Jonathan Gallimore wrote:
> >>>>> I haven't seen the code, so its difficult to suggest anything - where
> >>>>> would you expect it to be loaded - in a CDI extension?
> >>>>>
> >>>>> On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista  >>>>> <mailto:bruno...@gmail.com>> wrote:
> >>>>>
> >>>>> Hi all,
> >>&

Re: Override bean from library on TomEE

[Romain Manni-Bucau]

rename the lib geronimo-safeguard-tomee or include the common MP jar in the
scanned modules?

side note: i mentionned it @geronimo: you likely don't want to hardcode a
default name which will either be replaced by another one, not be the
default one or not be controllable by the user (
DefaultManagedScheduledExecutorService) so probably use tomee to inject a
configuration (@Resource MicroprofileConfiguration config; in your common
module) and then lookup the instance using tomee internal (containersystem
-> jndicontext? for instance). Not a big thing but if not done users will
have to code this bean themselves to control it I think.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 19 nov. 2018 à 15:24, Bruno Baptista  a écrit :

> Hi All,
>
> I created a PR to make the discussion easier. It's here:
> https://github.com/apache/tomee/pull/201
>
> There's another problem with the alternative bean implementation. After
> including the SafeguardInterceptor in the test, the bean,
> FailsafeContainerExecutionManagerProvider, is never picked up.
>
> I've played a bit with the priorities of both the interceptor and the
> alternative without success.
>
> We still need to figure out a CDI extension to activate the code on
> TomEE, but first, the existing test has to work on it's own.
>
> Cheers.
>
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 19/11/18 10:56, Bruno Baptista wrote:
> >
> > Hi Jon,
> >
> > I'm not sure what would be the right way to load that code.
> >
> > But now that you mention it, a CDI extension sounds the proper way to
> > do it. The code now loads properly. Thanks!
> >
> > Will create a PR soon.
> >
> > Bruno Baptista
> > http://twitter.com/brunobat_
> >
> >
> > On 19/11/18 10:41, Jonathan Gallimore wrote:
> >> I haven't seen the code, so its difficult to suggest anything - where
> >> would you expect it to be loaded - in a CDI extension?
> >>
> >> On Mon, Nov 19, 2018 at 10:31 AM Bruno Baptista  >> <mailto:bruno...@gmail.com>> wrote:
> >>
> >> Hi all,
> >>
> >> I've created a jira for this task to properly track the commits:
> >> https://issues.apache.org/jira/browse/TOMEE-2278
> >>
> >> Right now I have a problem activating the code... The code is in
> >> the lib folder but it's not being loaded into the classpath.
> >>
> >> Do I need to create some kind of a service like this?
> >>
> >> Or am I missing to declare it in some xml file?
> >>
> >> Cheers
> >>
> >> Bruno Baptista
> >> http://twitter.com/brunobat_
> >>
> >>
> >> On 18/11/18 12:55, Bruno Baptista wrote:
> >>>
> >>> Hi All,
> >>>
> >>> I came up with a test that successfully overrides the original
> >>> /FailsafeExecutionManagerProvider/ Safeguard class.
> >>>
> >>> It was a bit of a surprise but, in this case, beans.xml is
> >>> useless because "The alternatives that you specify in the
> >>> |beans.xml| file apply only to classes in the same archive."
> >>> see: https://docs.oracle.com/javaee/7/tutorial/cdi-adv002.htm
> >>>
> >>> Because the beans are in different jar files, priority has to be
> >>> used instead:
> >>>
> >>> @Priority(Interceptor.Priority.APPLICATION+10)
> >>>
> >>> The precise priority might need to be fine tuned because of the
> >>> fault tolerance interceptor... Will have to test the final
> >>> behavior.
> >>>
> >>> Also, we probably need to reorganize the
> >>> tomee-microprofile-webapp project...
> >>> This is needed because the code overriding the bean needs to be
> >>> in a library and this project only creates a war file, which is
> >>> in fact a container for the bundled libraries. The classes we
> >>> place in there will not be in the final server.
> >>>
> >>> I'm thinking on something like:
> >>>
> >>> tomee
> >>> |
> >>> --- tomee-microprofile
&g

Re: Override bean from library on TomEE

[Romain Manni-Bucau]

FYI this works:


@ApplicationScoped
public class CustomProvider extends FailsafeExecutionManagerProvider {
@Override
@Produces
@Specializes
@ApplicationScoped
public ExecutionManager createExecutionManager() {
return new FailsafeExecutionManager() {
@Override // hardcoded impl for testing purposes
public Object execute(final InvocationContext invocationContext) {
return "replaced";
}
};
}
}


Side note: did you want to use @Resource for the executor injection?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 16 nov. 2018 à 14:54, Romain Manni-Bucau  a
écrit :

> Hi Bruno,
>
> I assume the alternative is activated in the beans.xml? (if not try adding
> a @Priority maybe or just drop the annotation which should be useless)
>
> If it is i'd start by writing a small test (with application composer) to
> check if it is a bug in tomee cause this is how it must work
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  a
> écrit :
>
>> Hi Roman,
>>
>> This is what I did and it doesn't work. The original bean is always
>> picked up:
>>
>> @Specializes@Alternative@ApplicationScopedpublic class 
>> FailsafeContainerExecutionManagerProvider extends 
>> FailsafeExecutionManagerProvider {
>>
>> @Injectprivate ManagedScheduledExecutorService executor;
>>
>> @Produces@ApplicationScoped@Overridepublic ExecutionManager 
>> createExecutionManager() throws Exception {
>>
>>
>> final MicroprofileAnnotationMapper mapper = 
>> MicroprofileAnnotationMapper.getInstance();
>> final DefaultExecutorServiceProvider executorServiceProvider = new 
>> DefaultExecutorServiceProvider(executor);
>> final BulkheadManagerImpl bulkheadManager = new 
>> BulkheadManagerImpl();
>> final FailsafeCircuitBreakerManager circuitBreakerManager = new 
>> FailsafeCircuitBreakerManager();
>> final FailsafeRetryManager retryManager = new FailsafeRetryManager();
>>
>> return new FailsafeExecutionManager(
>> mapper,
>> bulkheadManager,
>> circuitBreakerManager,
>> retryManager,
>> new ExecutionPlanFactory(circuitBreakerManager, 
>> retryManager, bulkheadManager, mapper,
>> executorServiceProvider),
>> executorServiceProvider);
>> }
>> }
>>
>>
>> I feel that this needs to be done in a different way... Would you be able
>> to point me to a similar override currently being done?
>>
>> Cheers
>> Bruno Baptista
>> https://twitter.com/brunobat_
>> http://tomitribe.com
>> https://tribestream.io
>> Bruno Baptista
>> http://twitter.com/brunobat_
>>
>>
>> On 16/11/18 10:28, Romain Manni-Bucau wrote:
>>
>> Hi Bruno,
>>
>> it is a palin bean so @Specializes works, did you put it on the method?
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> 
>> <https://twitter.com/rmannibucau> |  Blog<https://rmannibucau.metawerx.net/> 
>> <https://rmannibucau.metawerx.net/> | Old 
>> Blog<http://rmannibucau.wordpress.com> <http://rmannibucau.wordpress.com> | 
>> Github <https://github.com/rmannibucau> <https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> 
>> <https://www.linkedin.com/in/rmannibucau> | 
>> Book<https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>  
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le ven. 16 nov. 2018 à 11:00, Bruno Baptista  
>>  a écrit :
>>
>>
>> Hi all,
>>
>> We have a problem with the integration of the Safeguard Fault Tolerance
>> libra

Re: Override bean from library on TomEE

[Romain Manni-Bucau]

Hi Bruno,

I assume the alternative is activated in the beans.xml? (if not try adding
a @Priority maybe or just drop the annotation which should be useless)

If it is i'd start by writing a small test (with application composer) to
check if it is a bug in tomee cause this is how it must work

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 16 nov. 2018 à 12:44, Bruno Baptista  a écrit :

> Hi Roman,
>
> This is what I did and it doesn't work. The original bean is always picked
> up:
>
> @Specializes@Alternative@ApplicationScopedpublic class 
> FailsafeContainerExecutionManagerProvider extends 
> FailsafeExecutionManagerProvider {
>
> @Injectprivate ManagedScheduledExecutorService executor;
>
> @Produces@ApplicationScoped@Overridepublic ExecutionManager 
> createExecutionManager() throws Exception {
>
>
> final MicroprofileAnnotationMapper mapper = 
> MicroprofileAnnotationMapper.getInstance();
> final DefaultExecutorServiceProvider executorServiceProvider = new 
> DefaultExecutorServiceProvider(executor);
> final BulkheadManagerImpl bulkheadManager = new BulkheadManagerImpl();
> final FailsafeCircuitBreakerManager circuitBreakerManager = new 
> FailsafeCircuitBreakerManager();
> final FailsafeRetryManager retryManager = new FailsafeRetryManager();
>
> return new FailsafeExecutionManager(
> mapper,
> bulkheadManager,
> circuitBreakerManager,
> retryManager,
> new ExecutionPlanFactory(circuitBreakerManager, retryManager, 
> bulkheadManager, mapper,
> executorServiceProvider),
> executorServiceProvider);
> }
> }
>
>
> I feel that this needs to be done in a different way... Would you be able
> to point me to a similar override currently being done?
>
> Cheers
> Bruno Baptista
> https://twitter.com/brunobat_
> http://tomitribe.com
> https://tribestream.io
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
> On 16/11/18 10:28, Romain Manni-Bucau wrote:
>
> Hi Bruno,
>
> it is a palin bean so @Specializes works, did you put it on the method?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> 
> <https://twitter.com/rmannibucau> |  Blog<https://rmannibucau.metawerx.net/> 
> <https://rmannibucau.metawerx.net/> | Old 
> Blog<http://rmannibucau.wordpress.com> <http://rmannibucau.wordpress.com> | 
> Github <https://github.com/rmannibucau> <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> 
> <https://www.linkedin.com/in/rmannibucau> | 
> Book<https://www.packtpub.com/application-development/java-ee-8-high-performance>
>  <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le ven. 16 nov. 2018 à 11:00, Bruno Baptista  
>  a écrit :
>
>
> Hi all,
>
> We have a problem with the integration of the Safeguard Fault Tolerance
> library on TomEE 8 and I need help to solve it. This is a follow up to
> the original email thread, from Oct 3, in the Geronimo mailing list,
> where we decided to do perform the override in the container side.
>
> I need to override the starting point for the library, originally here:
>
> https://github.com/apache/geronimo-safeguard/blob/master/safeguard-impl/src/main/java/org/apache/safeguard/impl/cdi/FailsafeExecutionManagerProvider.java
>
> Because it's not using a managed executor service from TomEE... Like
> this one: "java:comp/DefaultManagedScheduledExecutorService"
>
> I Expect to do the wiring in here
> .../apache-tomee/tomee/tomee-microprofile-webapp/src
>
> Like using a @Specializes bean or something, but I think we cannot do
> that there. Could someone help me wire up this new bean?
>
> I had a PR to fix this the lib itself but it was decided not to move
> with it. For the curious, it's 
> here:https://github.com/apache/geronimo-safeguard/pull/2
>
> Cheers
> --
> Bruno Baptistahttp://twitter.com/brunobat_
>
>
>

Re: Override bean from library on TomEE

[Romain Manni-Bucau]

Hi Bruno,

it is a palin bean so @Specializes works, did you put it on the method?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 16 nov. 2018 à 11:00, Bruno Baptista  a écrit :

> Hi all,
>
> We have a problem with the integration of the Safeguard Fault Tolerance
> library on TomEE 8 and I need help to solve it. This is a follow up to
> the original email thread, from Oct 3, in the Geronimo mailing list,
> where we decided to do perform the override in the container side.
>
> I need to override the starting point for the library, originally here:
>
>
> https://github.com/apache/geronimo-safeguard/blob/master/safeguard-impl/src/main/java/org/apache/safeguard/impl/cdi/FailsafeExecutionManagerProvider.java
>
> Because it's not using a managed executor service from TomEE... Like
> this one: "java:comp/DefaultManagedScheduledExecutorService"
>
> I Expect to do the wiring in here
> .../apache-tomee/tomee/tomee-microprofile-webapp/src
>
> Like using a @Specializes bean or something, but I think we cannot do
> that there. Could someone help me wire up this new bean?
>
> I had a PR to fix this the lib itself but it was decided not to move
> with it. For the curious, it's here:
> https://github.com/apache/geronimo-safeguard/pull/2
>
> Cheers
> --
> Bruno Baptista
> http://twitter.com/brunobat_
>
>
>

Re: tomee git commit: TOMEE-2277 Java 11 - define modules for TomEE At the moment, they are tight to maven artifact but we can improve later.

[Romain Manni-Bucau]

The full tomee build does not rely on modules even ran with java11 so it
does not surprises me much.

Try to create a new project and require openejb-core module for instance.
Will be enough to check

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 15 nov. 2018 à 12:09, Jean-Louis Monteiro 
a écrit :

> I built and ran TomEE with some opens and exports and did not get any
> exception.
> But I'm happy to do a second round and override the default name
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, Nov 15, 2018 at 11:40 AM Romain Manni-Bucau  >
> wrote:
>
> > Hey JL, did you check these names are valid? Think the - can be an issue
> > (jdk.internal.module.Checks#requireModuleName)
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > -- Forwarded message -
> > From: 
> > Date: jeu. 15 nov. 2018 à 11:32
> > Subject: tomee git commit: TOMEE-2277 Java 11 - define modules for TomEE
> At
> > the moment, they are tight to maven artifact but we can improve later.
> > To: 
> >
> >
> > Repository: tomee
> > Updated Branches:
> >   refs/heads/master b470fc8ce -> 127207255
> >
> >
> > TOMEE-2277 Java 11 - define modules for TomEE
> > At the moment, they are tight to maven artifact but we can improve later.
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/12720725
> > Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/12720725
> > Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/12720725
> >
> > Branch: refs/heads/master
> > Commit: 12720725544cd731f7192d7d9d4483974c62ac06
> > Parents: b470fc8
> > Author: Jean-Louis Monteiro 
> > Authored: Thu Nov 15 11:32:12 2018 +0100
> > Committer: Jean-Louis Monteiro 
> > Committed: Thu Nov 15 11:32:12 2018 +0100
> >
> > --
> >  container/openejb-core/pom.xml   | 3 ++-
> >  container/openejb-javaagent/pom.xml  | 3 ++-
> >  itests/openejb-itests-client/pom.xml | 5 -
> >  pom.xml  | 8 +++-
> >  server/openejb-client/pom.xml| 5 -
> >  tomee/apache-tomee/pom.xml   | 5 +
> >  tomee/tomee-embedded/pom.xml | 5 -
> >  tomee/tomee-webapp/pom.xml   | 5 +
> >  8 files changed, 33 insertions(+), 6 deletions(-)
> > --
> >
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/tomee/blob/12720725/container/openejb-core/pom.xml
> > --
> > diff --git a/container/openejb-core/pom.xml
> > b/container/openejb-core/pom.xml
> > index bcd6dd6..7aadde4 100644
> > --- a/container/openejb-core/pom.xml
> > +++ b/container/openejb-core/pom.xml
> > @@ -392,12 +392,13 @@
> >  org.apache.maven.plugins
> >  maven-jar-plugin
> >  
> > -  
> > +  
> >  
> >org.apache.openejb.cli.Bootstrap
> >
> >  
> >  
> > +  ${tomee.build.name
> > }
> >openejb-loader-${project.version}.jar
> > openejb-client-${project.version}.jar
> >  xbean-finder-shaded-${xbeanVersion}.jar
> > xbean-asm7-shaded-${xbeanVersion}.jar
> >
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/tomee/blob/12720725/container/openejb-javaagent/pom.xml
> > --
> > diff --git a/container/openejb-javaagent/pom.xml
> > b/container/openejb-javaagent/pom.xml
> > index 5e69a63..4405551 100644

Fwd: tomee git commit: TOMEE-2277 Java 11 - define modules for TomEE At the moment, they are tight to maven artifact but we can improve later.

[Romain Manni-Bucau]

Hey JL, did you check these names are valid? Think the - can be an issue
(jdk.internal.module.Checks#requireModuleName)

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


-- Forwarded message -
From: 
Date: jeu. 15 nov. 2018 à 11:32
Subject: tomee git commit: TOMEE-2277 Java 11 - define modules for TomEE At
the moment, they are tight to maven artifact but we can improve later.
To: 


Repository: tomee
Updated Branches:
  refs/heads/master b470fc8ce -> 127207255


TOMEE-2277 Java 11 - define modules for TomEE
At the moment, they are tight to maven artifact but we can improve later.


Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/12720725
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/12720725
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/12720725

Branch: refs/heads/master
Commit: 12720725544cd731f7192d7d9d4483974c62ac06
Parents: b470fc8
Author: Jean-Louis Monteiro 
Authored: Thu Nov 15 11:32:12 2018 +0100
Committer: Jean-Louis Monteiro 
Committed: Thu Nov 15 11:32:12 2018 +0100

--
 container/openejb-core/pom.xml   | 3 ++-
 container/openejb-javaagent/pom.xml  | 3 ++-
 itests/openejb-itests-client/pom.xml | 5 -
 pom.xml  | 8 +++-
 server/openejb-client/pom.xml| 5 -
 tomee/apache-tomee/pom.xml   | 5 +
 tomee/tomee-embedded/pom.xml | 5 -
 tomee/tomee-webapp/pom.xml   | 5 +
 8 files changed, 33 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/tomee/blob/12720725/container/openejb-core/pom.xml
--
diff --git a/container/openejb-core/pom.xml b/container/openejb-core/pom.xml
index bcd6dd6..7aadde4 100644
--- a/container/openejb-core/pom.xml
+++ b/container/openejb-core/pom.xml
@@ -392,12 +392,13 @@
 org.apache.maven.plugins
 maven-jar-plugin
 
-  
+  
 
   org.apache.openejb.cli.Bootstrap
   
 
 
+  ${tomee.build.name
}
   openejb-loader-${project.version}.jar
openejb-client-${project.version}.jar
 xbean-finder-shaded-${xbeanVersion}.jar
xbean-asm7-shaded-${xbeanVersion}.jar
   

http://git-wip-us.apache.org/repos/asf/tomee/blob/12720725/container/openejb-javaagent/pom.xml
--
diff --git a/container/openejb-javaagent/pom.xml
b/container/openejb-javaagent/pom.xml
index 5e69a63..4405551 100644
--- a/container/openejb-javaagent/pom.xml
+++ b/container/openejb-javaagent/pom.xml
@@ -32,8 +32,9 @@
 org.apache.maven.plugins
 maven-jar-plugin
 
-  
+  
 
+  ${tomee.build.name
}

 org.apache.openejb.javaagent.Agent
   org.apache.openejb.javaagent.Agent
   true

http://git-wip-us.apache.org/repos/asf/tomee/blob/12720725/itests/openejb-itests-client/pom.xml
--
diff --git a/itests/openejb-itests-client/pom.xml
b/itests/openejb-itests-client/pom.xml
index 626a74d..fe3b24b 100644
--- a/itests/openejb-itests-client/pom.xml
+++ b/itests/openejb-itests-client/pom.xml
@@ -45,11 +45,14 @@
 org.apache.maven.plugins
 maven-jar-plugin
 
-  
+  
 
   org.apache.openejb.test.Main
   true
 
+
+  ${tomee.build.name
}
+
   
 
   

http://git-wip-us.apache.org/repos/asf/tomee/blob/12720725/pom.xml
--
diff --git a/pom.xml b/pom.xml
index 537ec3a..404521e 100644
--- a/pom.xml
+++ b/pom.xml
@@ -99,6 +99,9 @@
 1.8
 2.21.0

+
+${project.groupId}.${project.artifactId}
+
 
 8.0

@@ -455,8 +458,11 @@
 org.apache.maven.plugins
 maven-jar-plugin
 
-  
+  

 
${project.build.outputDirectory}/META-INF/MANIFEST.MF
+
+  ${tomee.build.name
}
+
   
 
   

http://git-wip-us.apache.org/repos/asf/tomee/blob/12720725/server/openejb-client/pom.xml
--
diff --git a/server/openejb-client/pom.xml b/server/openejb-client/pom.xml
index c40d60c..5618ec4 100644
--- a/ser

Fwd: tomee git commit: TomEE-2274 Java 11 compatibility - upgrade to Jaxb 2.3.1 Thanks Cees Bos

[Romain Manni-Bucau]

Hi JL,

did you mean 2.3.0.1? 2.3.1 does not exist under these coordinates

also take care it is built with java 9 so maybe not what we want to deliver
in tomee

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


-- Forwarded message -
From: 
Date: mar. 13 nov. 2018 à 14:20
Subject: tomee git commit: TomEE-2274 Java 11 compatibility - upgrade to
Jaxb 2.3.1 Thanks Cees Bos
To: 


Repository: tomee
Updated Branches:
  refs/heads/master 03a4ca9f9 -> 7aa041047


TomEE-2274 Java 11 compatibility - upgrade to Jaxb 2.3.1
Thanks Cees Bos


Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/7aa04104
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/7aa04104
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/7aa04104

Branch: refs/heads/master
Commit: 7aa0410472acd3010577007889d4a3076f7891b3
Parents: 03a4ca9
Author: Jean-Louis Monteiro 
Authored: Tue Nov 13 14:19:50 2018 +0100
Committer: Jean-Louis Monteiro 
Committed: Tue Nov 13 14:19:50 2018 +0100

--
 pom.xml | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/tomee/blob/7aa04104/pom.xml
--
diff --git a/pom.xml b/pom.xml
index 537ec3a..d00622f 100644
--- a/pom.xml
+++ b/pom.xml
@@ -137,6 +137,8 @@

 3.2.7
 2.10.3
+2.3.1
+
 
 7.5.3.v20111011
 1.3.5
@@ -1695,17 +1697,17 @@
   
 javax.xml.bind
 jaxb-api
-2.3.0
+${jaxb.version}
   
   
 com.sun.xml.bind
 jaxb-impl
-2.3.0
+${jaxb.version}
   
   
 com.sun.xml.bind
 jaxb-core
-2.3.0
+${jaxb.version}
   

 org.fusesource.jansi

Re: Some jars in TomEE 8 SNAPSHOT are not Java 11 compatible

[Romain Manni-Bucau]

I'm running cxf under java 11 since some time now so it can be important in
that work to split the statements between "it runs on java11" and "it uses
java11 natively" - which is not done by any lib today AFAIK.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 13 nov. 2018 à 14:22, Jean-Louis Monteiro 
a écrit :

> Hi,
>
> Thank you very much for the detailed list.
>
> I have upgraded yesterday and today XBean and OWB so they are Java 11
> compatible.
> I'll do the Jaxb upgrade in few minutes.
>
> BVal - I'll chat with Romain or Mark. They are both committers.
>
> ECJ - this is a Tomcat dependency, so I'd check first with Tomcat community
> CXF - also need to check with the community
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Nov 13, 2018 at 2:02 PM Cees Bos  wrote:
>
> > Hi all,
> >
> >
> > We are doing a Java 11 validation for our product.
> >
> > We validate all our own code, Third party jars we use and TomEE jars.
> >
> >
> > We validate it with jdeprscan, jdeps (both tools from the JDK) and we
> > decompile the code and grep for known issue patterns.
> >
> > We found an issue in Openwebbean 2.0.7, which is fixed in 2.0.8. That is
> > released yesterday and updated for TomEE 8, that is great.
> >
> >
> > Problems we found more:
> >
> >
> >   *   2 bval jars in bval-jsr-2.0.1-20181030.140436-1.jar and
> > bval-jsr-2.0.1-SNAPSHOT.jar
> >  *   bval uses javafx from an abstract class. Javafx is not part of
> > Java 11 anymore. But it looks like it is not used by default. So at first
> > glace this does not look like a problem
> >  *   2 jars seems overkill, so 1 can be removed I guess
> >
> >   *   ecj-4.7.3a.jar There are some checks with java.version which only
> > deal with Java 9 and 10, but 11 and higher fail.
> > See org.eclipse.jdt.internal.compiler.impl.CompilerOptions (methods
> > versionFromJdkLevel, releaseToJDKLevel, versionToJdkLevel)
> > Eclipse JDT code has done fixes for Java 11, see <
> >
> https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=aecd2d1f6ce62d2ae12bcc68e57f73ab4cf27583
> >
> >
> >
> https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/impl/CompilerOptions.java?id=aecd2d1f6ce62d2ae12bcc68e57f73ab4cf27583
> > So the latest version support Java 11 as well.
> >
> >   *   CXF 3.2.7 is not yet Java 11 ready.
> >  *
> >
> https://github.com/apache/cxf/commit/a3295e61bcf8c00c13a79707841a58131fd9c97d#diff-b3f6b10d6fc20e1c16fbaef5d67ba228
> > Fixed Java 11 issue, see https://issues.apache.org/jira/browse/CXF-7741
> > This will be part of 3.3.0, which is not released yet.
> >
> >   *   Jaxb Impl 2.3.0 class
> > com.sun.xml.bind.v2.runtime.reflect.opt.Injector.java is using
> > Unsafe.defineClass which cannot be used anymore in Java 11, see
> >
> https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html#JDK-8193033
> > In Jaxb impl 2.3.1 the Injector class is gone. So upgrade to 2.3.1 to
> > prevent issues with Java 11 here.
> >
> >   *   OpenEJB client and core use some Corba classes which are not part
> of
> > Java anymore. That can give issues for some users, as these classes are
> not
> > available in the runtime anymore. For us it is no problem.
> >
> >
> > Hopefully this can help to make TomEE 8 ready for Java 11 usage for all
> > users.
> >
> > With kind regards,
> > Cees
> >
> >
> >
> >
> >
>

Re: HikariCP Connection Pooling

[Romain Manni-Bucau]

Side note: tomee already supports it - or any fancy pool - through resource
definition

Le lun. 12 nov. 2018 22:29, Jonathan Gallimore 
a écrit :

> Yeah, I saw that a while back and thought it was interesting. I'd be
> interested in adding support for it in TomEE.
>
> Jon
>
> On Mon, Nov 12, 2018 at 9:01 PM exabrial12  wrote:
>
> > Could be an interesting enhancement to TomEE:
> > https://github.com/exabrial/HikariCP
> >
> > Also, I found this fascinating:
> > https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
> >
> >
> >
> > --
> > Sent from:
> > http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> >
>

Re: Java 11 status

[Romain Manni-Bucau]

The unit tests point is likely easy to solve either using another pool or
just not using a pool for tests. Also the bug you fixed happens under some
particular case we can workaround using bigger pools I think.
Asm upgrade is really a few seds (I can help end of next week - thursday I
think - if needed).

Overall point was to not lock an ecosystem for features not used in half of
it. Commons-[pool|dbcp] is not required dependency of openjpa so shouldnt
block its release and if it does we must work to fix that issue IMHO.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le dim. 11 nov. 2018 à 12:11, Mark Struberg  a
écrit :

>  The problem is that the unit tests in OpenJPA do not pass with the old
> pool.
> So for getting OpenJPA-3.0.1 we need commons-pool.
> OpenJPA-3.0.0 still uses xbean-asm6. Means different package.We would need
> to package both xbean-asm6 and xbean-asm7 if we want to ship TomEE with
> OpenJPA-3.0.0.
> LieGrue,strub
>
> On Saturday, 10 November 2018, 22:52:48 CET, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
>  Agreed. Probably we don't need to wait for it. At least we could do a M2
> which is Java 11 ready.
>
>
>
> Le sam. 10 nov. 2018 à 21:49, Romain Manni-Bucau  a
> écrit :
>
> > Shouldnt be the case Mark since openjpa is not bound to a pool - except
> in
> > tests - and tomee default pool is not dbcp2 but tomcat-jdbc. So it is
> not a
> > requirement but more a nice to have IMHO. Also not a regression since
> last
> > release so not a blocker ;).
> >
> >
> > Le sam. 10 nov. 2018 21:02, Mark Struberg  a
> > écrit :
> >
> > >  We also need to wait for commons-pool and commons-dbcp. I fixed a
> > > deadlock in the pool.Only after that I'll be able to release OpenJPA.
> > > LieGrue,strub
> > >
> > >On Friday, 9 November 2018, 21:02:13 CET, Mark Struberg
> > >  wrote:
> > >
> > >  Right now I do a lot of OpenJPA hacking.
> > > One of the tasks is to also support xbean-asm7.
> > > That should go into openjpa-3.0.1.
> > >
> > > What is the timeframe we want to target?
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > > Am 09.11.2018 um 14:18 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > >
> > > > I don't have the list handy but tomee will need at least some
> > --add-opens
> > > > etc to run on java11 (you can add it in setenv.sh) - likely for
> unsafe
> > > and
> > > > the agent.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > > Le ven. 9 nov. 2018 à 14:09, Thomas Andraschko <
> > > andraschko.tho...@gmail.com>
> > > > a écrit :
> > > >
> > > >> (e.g. Tomcat and DeltaSpike still uses the old namespace it's in
> > > >> web/beans.xml)
> > > >>
> > > >> Am Fr., 9. Nov. 2018 um 13:35 Uhr schrieb Thomas Andraschko <
> > > >> andraschko.tho...@gmail.com>:
> > > >>
> > > >>> Also looks like XML unmarshalling is broken:
> > > >>>
> > > >>> Caused by: javax.xml.bind.UnmarshalException: unerwartetes Element
> > > (URI:"
> > > >>> http://java.sun.com/xml/ns/javaee;, lokal:"interceptors").
> Erwartete
> > > >>> Elemente
> > > >>> sind
> > <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
> > > >>>at
> > > >>>
> > >
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
> > > >>> (UnmarshallingContext.java:744)
> > > >>>at com.sun.xml.bind.v2.runtime.unmarshall

Re: Java 11 status

[Romain Manni-Bucau]

Shouldnt be the case Mark since openjpa is not bound to a pool - except in
tests - and tomee default pool is not dbcp2 but tomcat-jdbc. So it is not a
requirement but more a nice to have IMHO. Also not a regression since last
release so not a blocker ;).


Le sam. 10 nov. 2018 21:02, Mark Struberg  a
écrit :

>  We also need to wait for commons-pool and commons-dbcp. I fixed a
> deadlock in the pool.Only after that I'll be able to release OpenJPA.
> LieGrue,strub
>
> On Friday, 9 November 2018, 21:02:13 CET, Mark Struberg
>  wrote:
>
>  Right now I do a lot of OpenJPA hacking.
> One of the tasks is to also support xbean-asm7.
> That should go into openjpa-3.0.1.
>
> What is the timeframe we want to target?
>
> LieGrue,
> strub
>
>
> > Am 09.11.2018 um 14:18 schrieb Romain Manni-Bucau  >:
> >
> > I don't have the list handy but tomee will need at least some --add-opens
> > etc to run on java11 (you can add it in setenv.sh) - likely for unsafe
> and
> > the agent.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le ven. 9 nov. 2018 à 14:09, Thomas Andraschko <
> andraschko.tho...@gmail.com>
> > a écrit :
> >
> >> (e.g. Tomcat and DeltaSpike still uses the old namespace it's in
> >> web/beans.xml)
> >>
> >> Am Fr., 9. Nov. 2018 um 13:35 Uhr schrieb Thomas Andraschko <
> >> andraschko.tho...@gmail.com>:
> >>
> >>> Also looks like XML unmarshalling is broken:
> >>>
> >>> Caused by: javax.xml.bind.UnmarshalException: unerwartetes Element
> (URI:"
> >>> http://java.sun.com/xml/ns/javaee;, lokal:"interceptors"). Erwartete
> >>> Elemente
> >>> sind <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
> >>>at
> >>>
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
> >>> (UnmarshallingContext.java:744)
> >>>at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> >>> (Loader.java:262)
> >>>at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> >>> (Loader.java:257)
> >>>at
> >>>
> >>
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
> >>> (Loader.java:124)
> >>>at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
> >>> (Loader.java:105)
> >>>at
> >>> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
> >>> (StructureLoader.java:268)
> >>>at
> >>>
> >>
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> >>> (UnmarshallingContext.java:574)
> >>>at
> >>>
> >>
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
> >>> (UnmarshallingContext.java:556)
> >>>at
> com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
> >>> (SAXConnector.java:168)
> >>>at org.xml.sax.helpers.XMLFilterImpl.startElement
> >>> (XMLFilterImpl.java:551)
> >>>at
> >>> org.apache.openejb.jee.JaxbJavaee$JavaeeNamespaceFilter.startElement
> >>> (JaxbJavaee.java:293)
> >>>at
> >>>
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
> >>> (AbstractSAXParser.java:510)
> >>>at
> >>>
> >>
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
> >>> (XMLNSDocumentScannerImpl.java:374)
> >>>at
> >>>
> >>
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
> >>> (XMLDocumentFragmentScannerImpl.java:2708)
> >>>at
> >> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> >>> (XMLDocumentScannerImpl.java:605)
> >>>at
> >>> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> >>> (XMLNSDocumentScannerImpl.java:112)
> >>>at
> >>>
> >>
> com.sun.org.apache

Re: Java 11 status

[Romain Manni-Bucau]

I don't have the list handy but tomee will need at least some --add-opens
etc to run on java11 (you can add it in setenv.sh) - likely for unsafe and
the agent.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 9 nov. 2018 à 14:09, Thomas Andraschko 
a écrit :

> (e.g. Tomcat and DeltaSpike still uses the old namespace it's in
> web/beans.xml)
>
> Am Fr., 9. Nov. 2018 um 13:35 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
> > Also looks like XML unmarshalling is broken:
> >
> > Caused by: javax.xml.bind.UnmarshalException: unerwartetes Element (URI:"
> > http://java.sun.com/xml/ns/javaee;, lokal:"interceptors"). Erwartete
> > Elemente
> >  sind <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
> > at
> > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
> > (UnmarshallingContext.java:744)
> > at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> > (Loader.java:262)
> > at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> > (Loader.java:257)
> > at
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
> > (Loader.java:124)
> > at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
> > (Loader.java:105)
> > at
> > com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
> > (StructureLoader.java:268)
> > at
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> > (UnmarshallingContext.java:574)
> > at
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
> > (UnmarshallingContext.java:556)
> > at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
> > (SAXConnector.java:168)
> > at org.xml.sax.helpers.XMLFilterImpl.startElement
> > (XMLFilterImpl.java:551)
> > at
> > org.apache.openejb.jee.JaxbJavaee$JavaeeNamespaceFilter.startElement
> > (JaxbJavaee.java:293)
> > at
> > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
> > (AbstractSAXParser.java:510)
> > at
> >
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
> > (XMLNSDocumentScannerImpl.java:374)
> > at
> >
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
> > (XMLDocumentFragmentScannerImpl.java:2708)
> > at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> > (XMLDocumentScannerImpl.java:605)
> > at
> > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
> > (XMLNSDocumentScannerImpl.java:112)
> > at
> >
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> > (XMLDocumentFragmentScannerImpl.java:534)
> > at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> > (XML11Configuration.java:888)
> > at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> > (XML11Configuration.java:824)
> > at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> > (XMLParser.java:141)
> > at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> > (AbstractSAXParser.java:1216)
> > at
> > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> > (SAXParserImpl.java:635)
> > at org.xml.sax.helpers.XMLFilterImpl.parse (XMLFilterImpl.java:357)
> > at
> > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0
> > (UnmarshallerImpl.java:258)
> > at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> > (UnmarshallerImpl.java:236)
> > at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
> > (UnmarshallerImpl.java:288)
> > at org.apache.openejb.jee.JaxbJavaee.unmarshalJavaee
> > (JaxbJavaee.java:133)
> > at org.apache.openejb.config.ReadDescriptors.readBeans
> > (ReadDescriptors.java:691)
> > at org.apache.openejb.config.DeploymentLoader.mergeBeansXml
> > (DeploymentLoader.java:1196)
> > at org.apache.openejb.config.DeploymentLoader.addBeansXmls
> > (Deplo

Re: Java 11 status

[Romain Manni-Bucau]

Hi JL

Openjpa needs xbean upgrade but should be quick. Cxf stack needs some jaxb
upgrades from memory. After the stack "supports" java11 as "run it" but
think no spec in EE is java >= 9 compatible (modules, spi etc).

Should be enough for tomee that said.


Le jeu. 8 nov. 2018 20:27, Jean-Louis Monteiro  a
écrit :

> Hey TomEE lovers,
>
> I would like to push the Java 11 support forward.
>
> I tried to gather information here and there. Here is a status with my
> view. Please, lemme know if you have further updates or any additional
> information.
>
> XBean: ready and released
> OWB: ready and released
> TomEE itself (OpenEJB and other integration): ready but not released yet
> OpenJPA: not clear, but looks like there is still some work to be done
> CXF: ready and released
> MyFaces, ActiveMQ, EclipseLink, Mojorra: unknown
> Tomcat: ready and released
>
> Are we on the same page?
>
> I propose to reach out to communities when libraries are not yet ready or
> released and see how we can help.
>
> Thoughts?
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Re: TomEE 8 M1 - MP

[Romain Manni-Bucau]

The built-in apps should have a MP config entry with the
value geronimo.opentracing.filter.active=false, you can workaround it
adding in the exploded webapp a
WEB-INF/classes/META-INF/microprofile-config.properties with this value

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 5 nov. 2018 à 09:18, j4fm  a écrit :

> Tested with an app and without an app present.  Without an app, shouldn't I
> still be able to reach the tomee status/manager pages?
>
> If I remove MP opentracing jars, status/manager pages are reachable both
> with and without an app.
>
> Thanks
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: MicroProfile JWT 1.1

[Romain Manni-Bucau]

Answered hopefully "long enough" on dev@geronimo so will just do a short
one here and shout if not enough: ManagedSecurityService in cdi package of
openejb-core must make the getCurrentPrincipal contextual so hidden behind
a proxy. The proxied API must be Principal and JsonWebToken when available
(try { add if can load } catch { ignore } works as pattern). The proxy
instance can be created once for all app using the container loader or per
app using the app loader and avoiding to leak between apps since the API
can use different loaders.

Le ven. 2 nov. 2018 14:44, Jonathan Gallimore 
a écrit :

> Thanks for the reply, but I am confused by your response. The PR I
> referenced adds a single test to the geronimo-jwt-auth project (
> https://github.com/apache/geronimo-jwt-auth/pull/3), based on
> org.eclipse.microprofile.jwt.tck.container.jaxrs.PrincipalInjectionTest
> from the TCK. It fails at present (hopefully we agree on that - my results
> attached). The geronimo-jwt-auth project doesn't touch TomEE at all - it
> uses OWB/Meecrowave to run the MicroProfile JWT TCK. I have not modified
> the project config at all, so it is using the SecurityService code you
> previously posted. If this additional test were part of the MicroProfile
> JWT TCK (and I'm going to propose it), the Geronimo JWT Auth implementation
> would *not* pass the TCK.
>
> I posted this here as I originally found the issue when continuing
> Roberto's efforts, but this has probably contributed to some confusion. I
> would suggest we continue this over on the Geronimo and OWB lists to avoid
> further confusion.
>
> Jon
>
> On Fri, Nov 2, 2018 at 12:46 PM Romain Manni-Bucau 
> wrote:
>
>> Hi
>>
>> Yes this is an owb misconfiguration/integration
>>
>> Geronimo is fine here so likely tomee owb spi to update as in geronimo tck
>>
>> Le ven. 2 nov. 2018 10:42, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com>
>> a écrit :
>>
>> > Thanks for the reply. I am still sure there is some sort of issue.
>> Putting
>> > TomEE to one side for the moment, I am able to reproduce this in the
>> > Geronimo JWT auth library as well. This PR includes a test to show what
>> I
>> > mean: https://github.com/apache/geronimo-jwt-auth/pull/3.
>> >
>> > I can confirm that this change:
>> > https://github.com/apache/openwebbeans/pull/12 enables that new test to
>> > pass.
>> >
>> > In short, if you @Inject JsonWebToken, or individual claims, or
>> > use @RolesAllowed, I think you're ok, but if you @Inject Principal, you
>> > will most likely get the wrong principal because the instance is cache
>> in a
>> > field in the org.apache.webbeans.portable.ProviderBasedProducer class,
>> and
>> > that looks like a security issue.
>> >
>> > Jon
>> >
>> > On Tue, Oct 30, 2018 at 5:56 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> > > Hi Jon,
>> > >
>> > > yes and no, idea is to be fast and for all producers it works except
>> the
>> > > principal which is broken anyway in CDI 1.x so guess this was not
>> fixed
>> > >
>> > > in CDI 2 (tomee 8) we can impl it this way:
>> > >
>> > >
>> >
>> https://github.com/apache/geronimo-jwt-auth/blob/master/src/test/java/org/apache/geronimo/microprofile/impl/jwtauth/tck/TckSecurityService.java
>> > >
>> > > Romain Manni-Bucau
>> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > > <https://rmannibucau.metawerx.net/> | Old Blog
>> > > <http://rmannibucau.wordpress.com> | Github <
>> > > https://github.com/rmannibucau> |
>> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > <
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > >
>> > >
>> > >
>> > > Le mar. 30 oct. 2018 à 00:58, Jonathan Gallimore <
>> > > jonathan.gallim...@gmail.com> a écrit :
>> > >
>> > > > Here's a question, probably for Mark or Romain. If I turn the proxy
>> > *off*
>> > > > in org.apache.webbeans.component.PrincipalBean, I'm finding that I
>> get
>> > > the
>> > > > wrong principal injected sometimes. Specifically, I get the
>> whatever is
>> > > on
>> > > > the proxyInstance field here:
>> > > >
>> > > >
>> 

Re: MicroProfile JWT 1.1

[Romain Manni-Bucau]

Hi

Yes this is an owb misconfiguration/integration

Geronimo is fine here so likely tomee owb spi to update as in geronimo tck

Le ven. 2 nov. 2018 10:42, Jonathan Gallimore 
a écrit :

> Thanks for the reply. I am still sure there is some sort of issue. Putting
> TomEE to one side for the moment, I am able to reproduce this in the
> Geronimo JWT auth library as well. This PR includes a test to show what I
> mean: https://github.com/apache/geronimo-jwt-auth/pull/3.
>
> I can confirm that this change:
> https://github.com/apache/openwebbeans/pull/12 enables that new test to
> pass.
>
> In short, if you @Inject JsonWebToken, or individual claims, or
> use @RolesAllowed, I think you're ok, but if you @Inject Principal, you
> will most likely get the wrong principal because the instance is cache in a
> field in the org.apache.webbeans.portable.ProviderBasedProducer class, and
> that looks like a security issue.
>
> Jon
>
> On Tue, Oct 30, 2018 at 5:56 AM Romain Manni-Bucau 
> wrote:
>
> > Hi Jon,
> >
> > yes and no, idea is to be fast and for all producers it works except the
> > principal which is broken anyway in CDI 1.x so guess this was not fixed
> >
> > in CDI 2 (tomee 8) we can impl it this way:
> >
> >
> https://github.com/apache/geronimo-jwt-auth/blob/master/src/test/java/org/apache/geronimo/microprofile/impl/jwtauth/tck/TckSecurityService.java
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 30 oct. 2018 à 00:58, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> a écrit :
> >
> > > Here's a question, probably for Mark or Romain. If I turn the proxy
> *off*
> > > in org.apache.webbeans.component.PrincipalBean, I'm finding that I get
> > the
> > > wrong principal injected sometimes. Specifically, I get the whatever is
> > on
> > > the proxyInstance field here:
> > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/ProviderBasedProducer.java#L51
> > >
> > > Should this line (line 66)
> > >
> > >
> >
> https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/ProviderBasedProducer.java#L66
> > > ,
> > > not simply be:
> > >
> > > return provider.get();
> > >
> > > as opposed to
> > >
> > > proxyInstance = provider.get(); ?
> > >
> > > That way, the proxyInstance field would never get set if proxy mode is
> > set
> > > to false. When proxy is true, this seems to work correctly (although I
> > have
> > > other unrelated issues in TomEE).
> > >
> > > I can probably work around this some other way, but it seems to me like
> > > that behaviour isn't quite right.
> > >
> > > Trying to think of a way to test it - I can probably come up with
> > > something, but I'd appreciate some pointers. Happy to shift this to
> > > openwebbeans-dev, and submit a PR. Replying here initially as I ran
> into
> > > this while hacking on the JWT code.
> > >
> > > Jon
> > >
> > > On Wed, Oct 17, 2018 at 12:41 AM Roberto Cortez
> > > 
> > > wrote:
> > >
> > > > Please, go ahead. Let me know if need anything. Thanks!
> > > >
> > > > > On 16 Oct 2018, at 21:53, Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> wrote:
> > > > >
> > > > > Any objection if I pick this up and have a go at the last tests, or
> > is
> > > > > someone already working on this?
> > > > >
> > > > > On Thu, Sep 27, 2018 at 5:44 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Yep this feature. Then it must works since we support user
> principal
> > > if
> > > > the
> > > > >> jwt filter is corretly placed in the filter chain and we must
> > inherit
> > > > from
> > > > >> the request principal.
> > > > >>
> > > 

Re: Finish the bval setup

[Romain Manni-Bucau]

It is mainly about ensuring it is ok then merge yes

The jfx tests are not executed if not configured as such, the flag does it
If I got it right

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 31 oct. 2018 à 14:32, Matthew Broadhead
 a écrit :

> i  installed JavaFX on OpenJDK as I use it on another project.  but is
> he saying to use a flag to include it in TomEE??
>
> On 31/10/2018 14:25, Matthew Broadhead wrote:
> > does that mean pull the branch including the PR and compile?
> >
> > On 31/10/2018 12:09, Romain Manni-Bucau wrote:
> >> Hi guys,
> >>
> >> Wonder if somebody wants to review
> >> https://github.com/apache/tomee/pull/180
> >> for merge
> >>
> >>  From my point of view it looks good and would enable us (bval+tomee) to
> >> appear on bean validation site being certified once we'll release bval
> >> 2.0.1.
> >>
> >> If anyone has a few cycles to check the PR and potentially do the javafx
> >> setup it would be awesome.
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
> >>
> >>
> >
>
>

Re: TOMEE-2253 - tomee.sh -version not working properly with Java 11

[Romain Manni-Bucau]

Le mer. 31 oct. 2018 à 14:52, Daniel Cunha  a écrit :

> Em seg, 29 de out de 2018 às 14:01, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> escreveu:
>
> > We should write a test case for both of these, and agree on them. I'd
> like
> > to be able to merge this in with confidence, and without the tests I
> don't
> > see how we can do that.
> >
> > Jon
> >
> > On Mon, Oct 29, 2018 at 3:35 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hi Daniel,
> > >
> > > the point is that this code is reused in several places so we must be
> as
> > > clean as we can, here the cases I had in mind:
> > >
> > > 1. reused main in another main (so an app calls the main): here the
> > pitfall
> > > is that the property openejb.classloader.first.disallow-system-load is
> > not
> > > resetted and the TCLL neither so after the main you use a closed
> > > classloader (so will likely easily fail)
> >
>
> I really didn't get your point. Side note we are create a classloader only
> for tomee cli execution, which keep alive only for a short time during
> command execution.
>
> That part of code is not reused in another place, if yes, just point me
> where, because I can't find it.
>
> It will close only after the program finish, since it is inside a try-catch
> block, no?
>

Assuming the main is launch but this main is sometimes launched
programmatically (like in a webapp)
When not you are right


>
>
> > > 2. if a user relies in java 8 on the classloader being the system one
> > then
> > > your new classloader level breaks it so we shouldnt create this new
> > > classloader when not needed and the old ClassPath impl is working IMO.
> We
> > > can enrich it with a warn log saying "it will fail in next version"
> (and
> > we
> > > drop that code after 1 or 2 releases). Idea is to not break directly
> > users
> > > who can not even know some of the libs they added in the classpath for
> > > logging purposes rely on that classloader setup - random example indeed
> > ;).
> > >
> >
>
> Yeah, I probably could use the SystemClassPath, but it is doing much more
> than I need to CLI. I don't think that I need to change the java.class.path
> property to make it works or other property like
> openejb.classloader.first.disallow-system-load.
>

We should likely be cleaner here but not your PR, fair enough


>
> And to be honest, I didn't understand what is
> openejb.classloader.first.disallow-system-load and why do we have it. :)
>

It is used in the "webapp" loader to check if we should load some well
known classes from the system classloader or not.
It is likely the kind of property you rely on when you want to be
embeddable but also standalone.


>
>
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 29 oct. 2018 à 16:14, Daniel Cunha  a
> > > écrit :
> > >
> > > > Hi,
> > > >
> > > > I updated the PR with tests!
> > > >
> > > > Em seg, 29 de out de 2018 às 08:27, Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> escreveu:
> > > >
> > > > > I saw your note on the PR regarding Romain's feedback.
> > > > >
> > > > > For visibility here, Romain is querying whether this patch will
> cause
> > > an
> > > > > issue with folks calling the CLI with a custom classpath using
> `java
> > > -cp
> > > > > ...` under Java 8. I'd suggest we add a test for it, which looks to
> > be
> > > > what
> > > > > Daniel is doing.
> > > > >
> > > > > Thanks guys.
> > > > >
> > > > > Jon
> > > > >
> > > > > On Thu, Oct 25, 2018 at 12:35 PM Daniel Cunha <
> daniels...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > Hi Folks,
> > > > > >
> > > > > > I sent a PR on TomEE to fix the TOMEE-2253. I got a lot of
> feedback
> > > > from
> > > > > > Romain (thank you Romain for all comments and help)
> > > > > >
> > > > > > I believe which we are in good shape to merge.
> > > > > > The changes cover from Java 8 till Java 11 which not provide any
> > > impact
> > > > > for
> > > > > > TomEE or application deployed on it.
> > > > > >
> > > > > > Please, look at the PR and let me know what you think.
> > > > > >
> > > > > > PR: https://github.com/apache/tomee/pull/176
> > > > > >
> > > > > > --
> > > > > > Daniel "soro" Cunha
> > > > > > https://twitter.com/dvlc_
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Daniel "soro" Cunha
> > > > https://twitter.com/dvlc_
> > > >
> > >
> >
>
> Thank you! :)
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
>

Finish the bval setup

[Romain Manni-Bucau]

Hi guys,

Wonder if somebody wants to review https://github.com/apache/tomee/pull/180
for merge

>From my point of view it looks good and would enable us (bval+tomee) to
appear on bean validation site being certified once we'll release bval
2.0.1.

If anyone has a few cycles to check the PR and potentially do the javafx
setup it would be awesome.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

Re: MicroProfile JWT 1.1

[Romain Manni-Bucau]

Hi Jon,

yes and no, idea is to be fast and for all producers it works except the
principal which is broken anyway in CDI 1.x so guess this was not fixed

in CDI 2 (tomee 8) we can impl it this way:
https://github.com/apache/geronimo-jwt-auth/blob/master/src/test/java/org/apache/geronimo/microprofile/impl/jwtauth/tck/TckSecurityService.java

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 30 oct. 2018 à 00:58, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> Here's a question, probably for Mark or Romain. If I turn the proxy *off*
> in org.apache.webbeans.component.PrincipalBean, I'm finding that I get the
> wrong principal injected sometimes. Specifically, I get the whatever is on
> the proxyInstance field here:
>
> https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/ProviderBasedProducer.java#L51
>
> Should this line (line 66)
>
> https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/ProviderBasedProducer.java#L66
> ,
> not simply be:
>
> return provider.get();
>
> as opposed to
>
> proxyInstance = provider.get(); ?
>
> That way, the proxyInstance field would never get set if proxy mode is set
> to false. When proxy is true, this seems to work correctly (although I have
> other unrelated issues in TomEE).
>
> I can probably work around this some other way, but it seems to me like
> that behaviour isn't quite right.
>
> Trying to think of a way to test it - I can probably come up with
> something, but I'd appreciate some pointers. Happy to shift this to
> openwebbeans-dev, and submit a PR. Replying here initially as I ran into
> this while hacking on the JWT code.
>
> Jon
>
> On Wed, Oct 17, 2018 at 12:41 AM Roberto Cortez
> 
> wrote:
>
> > Please, go ahead. Let me know if need anything. Thanks!
> >
> > > On 16 Oct 2018, at 21:53, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> > >
> > > Any objection if I pick this up and have a go at the last tests, or is
> > > someone already working on this?
> > >
> > > On Thu, Sep 27, 2018 at 5:44 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> Yep this feature. Then it must works since we support user principal
> if
> > the
> > >> jwt filter is corretly placed in the filter chain and we must inherit
> > from
> > >> the request principal.
> > >>
> > >> Le jeu. 27 sept. 2018 18:37, Roberto Cortez
>  > >
> > >> a
> > >> écrit :
> > >>
> > >>> I guess you are referring to this, to remove the proxy?
> > >>>
> > >>>
> > >>
> >
> https://github.com/apache/openwebbeans/commit/a21a949fb19247dcc39ee89292a1554b2cf1388e
> > >>> <
> > >>>
> > >>
> >
> https://github.com/apache/openwebbeans/commit/a21a949fb19247dcc39ee89292a1554b2cf1388e
> > >>>>
> > >>>
> > >>> Yes, this one step.
> > >>>
> > >>> By default, we do inject the generic Principal of Tomcat. We probably
> > >> need
> > >>> to check first about the existence of a JWT Principal and then
> fallback
> > >> to
> > >>> the Tomcat one. I think I know how to do it, I was just trying to
> > broaden
> > >>> up the conversation about general integration with EE security.
> > >>>
> > >>> Cheers,
> > >>> Roberto
> > >>>
> > >>>> On 26 Sep 2018, at 07:21, Romain Manni-Bucau  >
> > >>> wrote:
> > >>>>
> > >>>> OWB enable to do it - we did it in geronimo impl to pass tck of jwt
> > >> auth
> > >>>> spec.
> > >>>>
> > >>>> Le mer. 26 sept. 2018 03:28, Roberto Cortez
> > >> 
> > >>> a
> > >>>> écrit :
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> I’ve done some work to push our MP JWT implementation from 1.0 to
> > 1.1.
> > >>>>>
> > >>>>> You can check it here:
&

Re: Shutdown issues with ManagedScheduledExecutorService

[Romain Manni-Bucau]

Did you try a semaphore waiting all tasks are done? It likely also needs a
boolean to prevent new submissions before starting waiting for completion.

Side note: @Schedule sounds not bad for your use case ;)

Le lun. 29 oct. 2018 20:55, ChrisOwens  a écrit :

> This is with TomEE plus 7.0.5
>
> I'm getting /Bean ... has been undeployed/ exception on shutdown, which is
> preventing orderly cleanup.  The issue appears to be that a POJO
> implementing Runnable is scheduled for periodic execution; that POJO was
> created with a reference to a @Stateless bean; and the @Stateless bean is
> undeployed before the POJO completes execution.
>
> "Supervisor" is a @Singleton. Supervisor injects, via @Resource, a
> ManagedScheduledExecutorService. I don't do any configuration on this
> service; I just accept what the container gives me.
>
> "Processor" is a @Stateless bean that does all sorts of work including
> entity management, transactions, etc.
>
> Supervisor obtains an instance of Processor via @Inject.
>
> "Runner" is a POJO that implements Runnable. One of its constructor method
> accepts an instance of Processor. (as an aside, The run method of Runner
> checks for Thread.currentThread().isInterrupted and returns immediately if
> true. It also catches InterruptedException (which might be thrown by some
> of
> the blocking methods it invokes), and calls
> Thread.currentThread().interrupt() and returns.)
>
> To get the work done on a regular basis, Supervisor creates an instance of
> Runner, passing Processor as an argument to its constructor, and then uses
> the ManagedScheduledExecutorService to run with fixed delay.  Supervisor
> keeps a list of all the Runner tasks it has created.
>
> Supervisor has a stop() method that performs task.cancel(true) on every
> Runner task it has created. I have tried, alternatively, annotating the
> stop
> method with @PreDestroy, or explicitly invoking it from a
> ServletContextListener.
>
> At shutdown, it looks like Processor is being undeployed before the tasks
> in
> Supervisor are canceled. It appears that the container doesn't know that
> Processor needs to be kept deployed while the Runner tasks are still
> active.
>
> This happens before the Supervisor's stop() method is invoked:
>
>
> I'm having a hard time reducing this to a test case I can provide.
>
>
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>