Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

Thanks all.
Hope clear all conflicts. Jon, can you now merge the PR?
Regards.
Gurkan

On Mon, Jan 7, 2019 at 5:21 PM Jean-Louis Monteiro 
wrote:

> Yes I agree and take it as you describe so it's all good. It's definitely a
> step forward
>
> Le lun. 7 janv. 2019 à 12:21, Gurkan Erdogdu  a
> écrit :
>
> > Hello Jean-Louis and team,
> > I want to emphasize again that this PR will not change anything regarding
> > system properties. Its sole aim is to centralize all literal system
> > properties into its own module. Maybe, for the future, if needed, we can
> > update this module to add more configuration related functions. Currently
> > all literal constants are distributed around the codebase. Before adding
> > any more property, we need to discuss it first in here. So, one can
> easily
> > find the used property this way.
> > Regards.
> > Gurkan
> >
> > On Mon, Jan 7, 2019 at 1:30 PM Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com>
> > wrote:
> >
> > > Just want to make sure we don't forget System Properties were meant to
> be
> > > used to override configuration and not to be the main configuration
> > system
> > > for TomEE.
> > >
> > > We can discuss it and decide to change our mind and TomEE, but as per
> > now,
> > > I'm not really keen to relying on system properties to configure TomEE.
> > I'd
> > > rather take the opportunity to yank some system properties when
> possible.
> > >
> > >
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu 
> > wrote:
> > >
> > > > Thanks Jon.
> > > >
> > > > I don't have any aim to replace service-jar.xml approach. We will
> just
> > > add
> > > > another YAML based configuration support. Therefore, all tomee.xml,
> > > > resources.xml etc will be stay in there. YAML is just an additional
> > > > feature.
> > > >
> > > > Introducing new module , tomee-config, allow us to centralise all
> > > > configuration into one place and all other modules can use it via
> > > > dependency. In the future, we can remove all configuration codes from
> > > > openejb-core, etc. into this module. There are lots of system
> > properties
> > > > using in different modules, therefore each such module will add their
> > > > properties into TomEESystemConfig class and then use it.
> > > >
> > > > Currently, openejb-core is a one large module. We may also think to
> > > divide
> > > > this module into smaller modules which are having special purpose.
> > > >
> > > > Hope it clears your concerns.
> > > >
> > > > Regards.
> > > > Gurkan
> > > >
> > > > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> wrote:
> > > >
> > > > > I commented on your PR - thanks for sending that over. I think it
> > would
> > > > be
> > > > > worthwhile structuring the class with the constants in such a way
> > that
> > > > the
> > > > > javadoc could end up on the website via David's site generation
> code.
> > > > That
> > > > > would be extremely cool and I'm sure a very useful piece of
> > > > documentation.
> > > > >
> > > > > While I appreciate your service-jar.xml visibility comment, I
> suspect
> > > > that
> > > > > is because of something missing in its documentation, as opposed to
> > an
> > > > > issue with the design choice. I don't necessarily object to
> something
> > > > that
> > > > > can parse the config in YAML (I believe there is something that
> > handles
> > > > > JSON already), providing the existing config mechanism in XML, with
> > the
> > > > > defaults in service-jar.xml continued to work, and that I wouldn't
> be
> > > > > forced to migrate from XML to YAML. Many users make use of
> tomee.xml
> > > and
> > > > > resources.xml in a huge number of applications. Forcing a migration
> > on
> > > > them
> > > > > to YAML "just because" doesn't make sense to me. The concept of the
> > > > > service-jar.xml is a very core design concept in TomEE and I would
> > not
> > > be
> > > > > favour of changing it unless there was a really good rationale and
> a
> > > > better
> > > > > design proposed and discussed.
> > > > >
> > > > > I agree that system properties can lead to "magic" parameters that
> > > aren't
> > > > > well documented, and I'm definitely in favour of improving the
> > > > > documentation of those properties. The ability to override config
> > with
> > > > > system properties, however, is useful and also widely used so we'll
> > > need
> > > > to
> > > > > keep it.
> > > > >
> > > > > Jon
> > > > >
> > > > > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu  >
> > > > wrote:
> > > > >
> > > > > > For me, using services-jar.xml approach is not so visible to
> users.
> > > All
> > > > > > defaults are configured in this file and packaged within JAR
> file.
> > > > Users
> > > > > > are not able to read the parameter explanation from
> > services-jar.xml
> > > > > files.
> > > > > > Also, services.-jar.xml is somebit differ

Re: Ejemplos en Español

[César Hernández Mendoza]

Hi,

I rebase the PR with the latest master and did code clean up.
The PR for https://issues.apache.org/jira/browse/TOMEE-2444 is ready for
review.
I included in the PR the instructions to check the feature:
https://github.com/apache/tomee-site-generator/pull/16

To review this PR you need:

1. build the project: `tomee-site-generator$ mvn clean install`
2. Choose any example like for example
`tomee-site-generator/repos/tomee-8.0/examples/mp-config-example/` and
create a readme file with a suffix that represents the translation for the
readme. For example: ` README_fr.adoc `.
3. Build and run the project: `tomee-site-generator$ mvn  clean compile
-Djbake.http=true`
4. The project should show in `http://localhost:8080/docs.html` the [fr]
link to the examples in French.


El vie., 4 ene. 2019 a las 20:47, César Hernández Mendoza (<
cesargu...@gmail.com>) escribió:

> Update:
> My PR is still WIP. I identified a missing requirement: how we are going
> to present the available languages for each Source.
> After doing some mocks, I come up with this solution:
>
> tomee-8.0 (latest)
> Documentation
> Examples [fr] [es]
>
> When you click [fr] or [es], then the page for the translated examples
> appears: http://localhost:8080/tomee-8.0/examples/es/ or
> http://localhost:8080/tomee-8.0/examples/fr/
> Keeping the link for `Examples` the default in English:
> http://localhost:8080/tomee-8.0/examples/
>
> The site automatically generates the / structure based on the
> suffix for the readme file:   README_<2LetterLanguage>.adoc
>
> A video can clear out a lot of questions, you can check the video of the
> current PR that I expect to finish on Monday next week. I think I'm very
> close :)!
>
> https://issues.apache.org/jira/browse/TOMEE-2444?focusedCommentId=16734742&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16734742
>
> El jue., 3 ene. 2019 a las 13:28, David Blevins ()
> escribió:
>
>>
>> > On Jan 3, 2019, at 8:40 AM, César Hernández Mendoza <
>> cesargu...@gmail.com> wrote:
>> >
>> > Now that we have the main task (TomEE-2442), I created the first sub
>> tast:
>> > "Update tomee-site-generator to allow examples and docs
>> > internationalization- [TOMEE-2444]"
>> >
>> > Can some of the Jira admins please assign
>> > https://issues.apache.org/jira/browse/TOMEE-2444 to me?
>>
>> Assigned!
>>
>> > This will implement and validate David's proposal, if I make it work
>> then
>> > the door will be open to starting the translation marathon :)
>>
>> I recommend we translate a few examples now so you have something to code
>> against.
>>
>> Great to see excitement behind this :)  It could be huge :)
>>
>> -David
>>
>>
>> > El jue., 3 ene. 2019 a las 3:10, Bruno Baptista ()
>> > escribió:
>> >
>> >> Hi Carlos,
>> >>
>> >> Just chose a few documents, create the jiras and let us know them.
>> >>
>> >> Cheers!
>> >>
>> >> Bruno Baptista
>> >> https://twitter.com/brunobat_
>> >>
>> >>
>> >> On 03/01/19 01:11, Carlos Chacín wrote:
>> >>> +1 please let me know how I can help
>> >>>
>> >>> On Mon, Dec 24, 2018, 8:24 PM Daniel Dias Dos Santos <
>> >>> daniel.dias.analist...@gmail.com wrote:
>> >>>
>>  +1  :  )
>>  --
>> 
>>  *Daniel Dias dos Santos*
>>  Java Developer
>>  SouJava & JCP Member
>>  GitHub: https://github.com/Daniel-Dos
>>  Linkedin: www.linkedin.com/in/danieldiasjava
>>  Twitter: http://twitter.com/danieldiasjava
>> 
>> 
>>  Em seg, 24 de dez de 2018 às 21:28, David Blevins <
>> >> david.blev...@gmail.com
>>  escreveu:
>> 
>> > I say “game on” to any languages people want to contribute :)
>> >
>> > In fact, let the PRs fly. I’ll write the site logic this week.
>> >
>> > -David
>> >
>> > On Mon, Dec 24, 2018 at 2:45 PM Mohammed Aboullaite <
>> > aboullaite.moham...@gmail.com> wrote:
>> >
>> >> I think its a brilliant idea. it'll open the door for not only
>> >> Spanish,
>> > but
>> >> other languages as well (I'm thinking of French as well).
>> >>
>> >>
>> >>
>> >> On Mon, Dec 24, 2018, 11:35 PM David Blevins <
>> david.blev...@gmail.com
>> >> wrote:
>> >>
>> >>> I was talking with Hillmer on twitter about potentially
>> translating
>> >>> examples into Spanish.
>> >>>
>> >>> The idea is that we could potentially do examples and
>> documentation
>>  in
>> >>> Spanish.  Perhaps:
>> >>>
>> >>>  - http://tomee.apache.org/tomee-8.0/es/docs/
>> >>>  - http://tomee.apache.org/tomee-8.0/es/ejemplos/
>> >>>
>> >>> First note is that how we organize the files in the git repo and
>> how
>>  we
>> >>> organize them on the website can be completely different.  We use
>> the
>> >>> following code to collect all the examples together and do various
>> > things
>> >>> to them:
>> >>>
>> >>>  -
>> >>>
>> 
>> >>
>> https://github.com/apache/tomee-site-generator/blob/master/src/main/java/

[GitHub] cesarhernandezgt commented on issue #16: TOMEE-2444 Enable language support for examples

[GitBox]

cesarhernandezgt commented on issue #16: TOMEE-2444 Enable language support for 
examples
URL: 
https://github.com/apache/tomee-site-generator/pull/16#issuecomment-452160452
 
 
   To review this PR you need:
   
   1. build the project: `tomee-site-generator$ mvn clean install`
   2. Choose any example like for example 
`tomee-site-generator/repos/tomee-8.0/examples/mp-config-example/` and create a 
readme file with a suffix that represents the translation for the readme. For 
example: ` README_fr.adoc `.
   3. Build and run the project: `tomee-site-generator$ mvn  clean compile 
-Djbake.http=true`
   4. The project should show in `http://localhost:8080/docs.html` the [fr] 
link to the examples in french.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Performance issue with JMS on Tomee 7.0.5

[Wiesner, Martin]

Thanks Jonathan for such a quick reaction and the openness to provide a MWE for 
that issue to the community.

Best
Martin
—
https://twitter.com/mawiesne 




smime.p7s
Description: S/MIME cryptographic signature

Re: Investigating TOMEE-2403 AutoConnectionTrackerTest fails randomly

[Jonathan Gallimore]

Thanks. I'll set the rig up again and run some volume through with these
changes.

Jon

On Mon, Jan 7, 2019 at 8:46 PM Doychin Bondzhev 
wrote:

> Hi Jon,
>
> Please check this PR:
> https://github.com/apache/tomee/pull/360
>
> We can discuss the details there.
>
> I also found this bug report which is still open:
> https://issues.apache.org/jira/browse/TOMEE-2257
>
> Is that the problem you describe?
>
> On 7.1.2019 г. 18:51, jgallimore [via TomEE & OpenEJB] wrote:
>
> This test was a pain to write, and I am grateful for the feedback. Please
> do send a PR and I'll take a look.
>
> Some background to the problem here is that the the AutoConnectionTracker
> failed in some circumstances when servers were under heavy load with lots
> of GC happening - there appeared to be a timing issue where a resource
> that
> was actually in use was being forcefully closed by the auto connection
> tracker, but because something else still had a hold of it, it ended up
> going back in the pool and a broken resource being served up to the next
> thing that requested it. The requests for GC were quite key in reproducing
> the actual issue originally, so removing them might not actually be the
> right approach.
>
> It was particularly hard to reproduce and pin down and I ended up going
> through something like 40GB of heap dumps and logs to figure out what was
> happening. Previously there was no test, which made this even harder to
> pin
> down. I'm definitely happy to explore some options to make this more
> solid.
>
> Jon
>
> On Sun, Jan 6, 2019 at 8:28 PM Doychin Bondzhev <[hidden email]
> >
> wrote:
>
> > I use IDE to run test multiple times. It failed only once here.
> >
> > I also did some changes in the test code.
> >
> > I removed the line
> >
> >
> >
> https://github.com/apache/tomee/blob/7318a1db025878b3f1f56587c60b47a14d55ef68/container/openejb-core/src/test/java/org/apache/openejb/resource/AutoConnectionTrackerTest.java#L162
> >
> > This made test many times faster. It is not needed. This tests non
> leaking
> > business method so we expect everything to be cleared.
> >
> > Also I removed the all the code that waits for log messages. I left only
> > the line
> >
> > assertEquals(message, times, logCapture.find(message).size());
> >
> >
> > There is no need to wait for anything. All the waiting is already done
> for
> > the first and second tests in
> >
> > runTest method
> >
> > Regarding
> >
> > System.gc();
> >
> >
> > It is needed only for the tests that leak so I removed it from all other
> > tests.
> >
> > Third and fourth test are run in the main thread and there is no need to
> > wait before processing the log to.
> > You can see the change here :
> >
> >
> https://github.com/doychin/tomee/commit/76e090b482825682a859d6a1637f572d8128f30a
> >
> > In case you like it I can create PR.
> >
> > On 6.1.2019 г. 19:47, David Blevins-2 [via TomEE & OpenEJB] wrote:
> >
> > > On Jan 6, 2019, at 2:25 AM, Doychin Bondzhev <[hidden email]
> > > wrote:
> > >
> > > I would like to investigate this issue:
> > https://issues.apache.org/jira/browse/TOMEE-2403
> > >
> > > Where I can get more detailed error log regarding this issue?
> > >
> > > I tried to run the test locally but it works.
> >
> > Here's a technique I use sometimes to check random failures:
> >
> > $ for n in {1..50}; do mvn clean install
> > -Dtest=AutoConnectionTrackerTest 2>&1 | tee run-$n.log; done
> >
> > So far 3 out 17 have failed.  Debugging them will still be a pain in the
> > butt, but at least there's some hope.
> >
> >
> > My shallow observation is that the approach taken in the test itself
> looks
> > conspicuous.  Particularly, I'd say this test is not "correct" until it
> can
> > pass without the System.gc() statements.
> >
> >  -
> >
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/resource/AutoConnectionTrackerTest.java#L197
> >
> > More importantly, this method is using thread sleeps and retries to wait
> > for log output which *will* cause random failures.  We should have a
> > discussion on if there is a better way to make this more deterministic.
> >
> >  -
> >
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/resource/AutoConnectionTrackerTest.java#L216
> >
> > Testing log output can work, however the test logic is ultimately "if
> you
> > do or don't see this message in n seconds, we're good."  It needs to be
> "if
> > you do or don't see this message *when the test is over*, we're good."
> >
> > Since it's looking in log output, one way to do that might be to simply
> > log a "test complete" statement (perhaps with a random number on it),
> and
> > then wait for that in the log output.
> >
> >
> > -David
> >
> >
> >
> >
> >
> > *signature.asc* (499 bytes) Download Attachment
> > <
> http://tomee-openejb.979440.n4.nabble.c

Re: Investigating TOMEE-2403 AutoConnectionTrackerTest fails randomly

[Doychin Bondzhev]

Hi Jon,

Please check this PR:
https://github.com/apache/tomee/pull/360

We can discuss the details there.

I also found this bug report which is still open:
https://issues.apache.org/jira/browse/TOMEE-2257

Is that the problem you describe?

On 7.1.2019 г. 18:51, jgallimore [via TomEE & OpenEJB] wrote:

This test was a pain to write, and I am grateful for the feedback. Please
do send a PR and I'll take a look.

Some background to the problem here is that the the AutoConnectionTracker
failed in some circumstances when servers were under heavy load with lots
of GC happening - there appeared to be a timing issue where a resource 
that

was actually in use was being forcefully closed by the auto connection
tracker, but because something else still had a hold of it, it ended up
going back in the pool and a broken resource being served up to the next
thing that requested it. The requests for GC were quite key in 
reproducing

the actual issue originally, so removing them might not actually be the
right approach.

It was particularly hard to reproduce and pin down and I ended up going
through something like 40GB of heap dumps and logs to figure out what was
happening. Previously there was no test, which made this even harder 
to pin
down. I'm definitely happy to explore some options to make this more 
solid.


Jon

On Sun, Jan 6, 2019 at 8:28 PM Doychin Bondzhev <[hidden email] 
>

wrote:

> I use IDE to run test multiple times. It failed only once here.
>
> I also did some changes in the test code.
>
> I removed the line
>
>
> 
https://github.com/apache/tomee/blob/7318a1db025878b3f1f56587c60b47a14d55ef68/container/openejb-core/src/test/java/org/apache/openejb/resource/AutoConnectionTrackerTest.java#L162

>
> This made test many times faster. It is not needed. This tests non 
leaking

> business method so we expect everything to be cleared.
>
> Also I removed the all the code that waits for log messages. I left 
only

> the line
>
> assertEquals(message, times, logCapture.find(message).size());
>
>
> There is no need to wait for anything. All the waiting is already 
done for

> the first and second tests in
>
> runTest method
>
> Regarding
>
> System.gc();
>
>
> It is needed only for the tests that leak so I removed it from all 
other

> tests.
>
> Third and fourth test are run in the main thread and there is no 
need to

> wait before processing the log to.
> You can see the change here :
>
> 
https://github.com/doychin/tomee/commit/76e090b482825682a859d6a1637f572d8128f30a

>
> In case you like it I can create PR.
>
> On 6.1.2019 г. 19:47, David Blevins-2 [via TomEE & OpenEJB] wrote:
>
> > On Jan 6, 2019, at 2:25 AM, Doychin Bondzhev <[hidden email]
> > wrote:
> >
> > I would like to investigate this issue:
> https://issues.apache.org/jira/browse/TOMEE-2403
> >
> > Where I can get more detailed error log regarding this issue?
> >
> > I tried to run the test locally but it works.
>
> Here's a technique I use sometimes to check random failures:
>
>     $ for n in {1..50}; do mvn clean install
> -Dtest=AutoConnectionTrackerTest 2>&1 | tee run-$n.log; done
>
> So far 3 out 17 have failed.  Debugging them will still be a pain in 
the

> butt, but at least there's some hope.
>
>
> My shallow observation is that the approach taken in the test itself 
looks
> conspicuous.  Particularly, I'd say this test is not "correct" until 
it can

> pass without the System.gc() statements.
>
>  -
> 
https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/resource/AutoConnectionTrackerTest.java#L197

>
> More importantly, this method is using thread sleeps and retries to 
wait

> for log output which *will* cause random failures.  We should have a
> discussion on if there is a better way to make this more deterministic.
>
>  -
> 
https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/resource/AutoConnectionTrackerTest.java#L216

>
> Testing log output can work, however the test logic is ultimately 
"if you
> do or don't see this message in n seconds, we're good."  It needs to 
be "if

> you do or don't see this message *when the test is over*, we're good."
>
> Since it's looking in log output, one way to do that might be to simply
> log a "test complete" statement (perhaps with a random number on 
it), and

> then wait for that in the log output.
>
>
> -David
>
>
>
>
>
> *signature.asc* (499 bytes) Download Attachment
> 
 


>
>
> --
> If you reply to this email, your message will be added to the 
discussion

> below:
>
> 
http://tomee-openejb.979440.n4.nabble.com/Investigating-https-issues-apache-org-jira-browse-TOMEE-2403-tp4687290p4687291.html

> To start a new topic under TomEE Dev, email
> [hidden email] 
> To unsubscribe from TomEE Dev, click here
> <
> .
> NAML
> 

Re: Investigating TOMEE-2403 AutoConnectionTrackerTest fails randomly

[Jonathan Gallimore]

This test was a pain to write, and I am grateful for the feedback. Please
do send a PR and I'll take a look.

Some background to the problem here is that the the AutoConnectionTracker
failed in some circumstances when servers were under heavy load with lots
of GC happening - there appeared to be a timing issue where a resource that
was actually in use was being forcefully closed by the auto connection
tracker, but because something else still had a hold of it, it ended up
going back in the pool and a broken resource being served up to the next
thing that requested it. The requests for GC were quite key in reproducing
the actual issue originally, so removing them might not actually be the
right approach.

It was particularly hard to reproduce and pin down and I ended up going
through something like 40GB of heap dumps and logs to figure out what was
happening. Previously there was no test, which made this even harder to pin
down. I'm definitely happy to explore some options to make this more solid.

Jon

On Sun, Jan 6, 2019 at 8:28 PM Doychin Bondzhev 
wrote:

> I use IDE to run test multiple times. It failed only once here.
>
> I also did some changes in the test code.
>
> I removed the line
>
>
> https://github.com/apache/tomee/blob/7318a1db025878b3f1f56587c60b47a14d55ef68/container/openejb-core/src/test/java/org/apache/openejb/resource/AutoConnectionTrackerTest.java#L162
>
> This made test many times faster. It is not needed. This tests non leaking
> business method so we expect everything to be cleared.
>
> Also I removed the all the code that waits for log messages. I left only
> the line
>
> assertEquals(message, times, logCapture.find(message).size());
>
>
> There is no need to wait for anything. All the waiting is already done for
> the first and second tests in
>
> runTest method
>
> Regarding
>
> System.gc();
>
>
> It is needed only for the tests that leak so I removed it from all other
> tests.
>
> Third and fourth test are run in the main thread and there is no need to
> wait before processing the log to.
> You can see the change here :
>
> https://github.com/doychin/tomee/commit/76e090b482825682a859d6a1637f572d8128f30a
>
> In case you like it I can create PR.
>
> On 6.1.2019 г. 19:47, David Blevins-2 [via TomEE & OpenEJB] wrote:
>
> > On Jan 6, 2019, at 2:25 AM, Doychin Bondzhev <[hidden email]
> > wrote:
> >
> > I would like to investigate this issue:
> https://issues.apache.org/jira/browse/TOMEE-2403
> >
> > Where I can get more detailed error log regarding this issue?
> >
> > I tried to run the test locally but it works.
>
> Here's a technique I use sometimes to check random failures:
>
> $ for n in {1..50}; do mvn clean install
> -Dtest=AutoConnectionTrackerTest 2>&1 | tee run-$n.log; done
>
> So far 3 out 17 have failed.  Debugging them will still be a pain in the
> butt, but at least there's some hope.
>
>
> My shallow observation is that the approach taken in the test itself looks
> conspicuous.  Particularly, I'd say this test is not "correct" until it can
> pass without the System.gc() statements.
>
>  -
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/resource/AutoConnectionTrackerTest.java#L197
>
> More importantly, this method is using thread sleeps and retries to wait
> for log output which *will* cause random failures.  We should have a
> discussion on if there is a better way to make this more deterministic.
>
>  -
> https://github.com/apache/tomee/blob/master/container/openejb-core/src/test/java/org/apache/openejb/resource/AutoConnectionTrackerTest.java#L216
>
> Testing log output can work, however the test logic is ultimately "if you
> do or don't see this message in n seconds, we're good."  It needs to be "if
> you do or don't see this message *when the test is over*, we're good."
>
> Since it's looking in log output, one way to do that might be to simply
> log a "test complete" statement (perhaps with a random number on it), and
> then wait for that in the log output.
>
>
> -David
>
>
>
>
>
> *signature.asc* (499 bytes) Download Attachment
> 
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomee-openejb.979440.n4.nabble.com/Investigating-https-issues-apache-org-jira-browse-TOMEE-2403-tp4687290p4687291.html
> To start a new topic under TomEE Dev, email
> ml+s979440n982480...@n4.nabble.com
> To unsubscribe from TomEE Dev, click here
> 
> .
> NAML
> 

Re: Investigating https://issues.apache.org/jira/browse/TOMEE-2403

[Doychin Bondzhev]

Hi César,

I found the CI pages but looks like logs are not kept for long enough.

Any way I managed to reproduce the problem and I already implemented 
some changes in the test code and in the code that is tested.


You can check them here in case you are interested and let me know if 
you have comments.


http://tomee-openejb.979440.n4.nabble.com/Investigating-https-issues-apache-org-jira-browse-TOMEE-2403-tt4687290.html#a4687294


On 7.1.2019 г. 16:44, César Hernández Mendoza [via TomEE & OpenEJB] wrote:

Hi Doychin,
By looking at TomEE-2403, it seems the issue was occurring only on 
TomEE CI

[1].
If you click on a specific build you can have access to the entire 
log, see

for instance:
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/987/steps/test/logs/stdio

As a side note, I think this CI information can be something we can 
improve

on the TomEE website.

[1] https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8

El dom., 6 ene. 2019 a las 4:25, Doychin Bondzhev (<[hidden email] 
>)

escribió:

> Hi,
>
> I would like to investigate this issue:
> https://issues.apache.org/jira/browse/TOMEE-2403
>
> Where I can get more detailed error log regarding this issue?
>
> I tried to run the test locally but it works.
>
> --
> Doychin Bondzhev
> dSoft-Bulgaria Ltd.
> PowerPro - billing & provisioning solution for Service providers
> http://www.dsoft-bg.com/
> Mobile: +359888243116
>
>

--
Atentamente:
César Hernández Mendoza.



If you reply to this email, your message will be added to the 
discussion below:
http://tomee-openejb.979440.n4.nabble.com/Investigating-https-issues-apache-org-jira-browse-TOMEE-2403-tp4687290p4687324.html 

To start a new topic under TomEE Dev, email 
ml+s979440n982480...@n4.nabble.com
To unsubscribe from TomEE Dev, click here 
.
NAML 
 




--
Doychin Bondzhev
dSoft-Bulgaria Ltd.
PowerPro - billing & provisioning solution for Service providers
http://www.dsoft-bg.com/
Mobile: +359888243116

<>

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Javadoc is online / How deployment works

[César Hernández Mendoza]

nice improvement to the website.
I'm getting more familiar with the site-generator, today I'll rebase my PR
and try to finish the languages pr.

One question, why do you mean by "referenced classes"?

El sáb., 5 ene. 2019 a las 13:59, David Blevins ()
escribió:

> Javadoc is now online!  I still have more ideas for hacking on it, but
> it's good enough to open up for more people to start filling in
> documentation.
>
> Some important classes
>
> When you deploy an application, all annotations and xml are merged into
> one single meta-data tree by this class.  After this point, annotations and
> xml are no longer read or referenced.  It outputs an AppModule which is a
> mutable object and a little bit "fancy."
>
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/config/AnnotationDeployer.html
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/config/AppModule.html
>
> The next major step is this class which will take this data and analyze
> it, figuring out what corresponding container parts would need to be built
> in order to run the app as described.  It outputs an AppInfo which is an
> immutable data object that can have no methods or logic whatsoever.  After
> this point, the complexity of roughly 100k lines of deployment code is
> erased and all that remains is the AppInfo tree.  This tree can be thought
> of as an AST (abstract syntax tree) using compiler terms.
>
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/config/ConfigurationFactory.html
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/assembler/classic/AppInfo.html
>
> The AppInfo is blindly built by the Assembler.  The Assembler does no
> validation.  It should have been done in the steps leading to the creation
> of the AppInfo.  The objects built by the Assembler are the true,
> thread-safe, runtime objects that make your apps actually work (aka the
> "runtime").  The Assembler is the only bit of code allowed to see both the
> AppInfo and the runtime classes.  The runtime classes themselves are not
> allowed to see the AppInfo tree or the Assembler.  After this point the
> AppInfo tree and Assembler itself are gone.
>
>  -
> http://tomee.apache.org/tomee-8.0/javadoc/org/apache/openejb/assembler/classic/Assembler.html
>
> Now you have a working and running container wrapped around your code and
> ready to serve requests.  This runtime is completely unaware of what came
> before it or built it and therefore it's most simple self.  This runtime is
> as immutable as possible and thread-safe.
>
> This process is a major part of why TomEE is so light at runtime.  The
> deployment process is a bit like launching a space shuttle where heavy bits
> keep falling away until only a tiny part remains.
>
> The best way to understand that code is to study the Assembler is it is
> the last "heavy bit" that builds the actual runtime, before falling away
> itself.
>
>
>
> Contribution Opportunity:
>
>  - Take this email and try and fill out the Javadoc of the referenced
> classes
>
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

-- 
Atentamente:
César Hernández Mendoza.

Re: Stabilize TomEE Build

[César Hernández Mendoza]

>
> one suggestion was for committers to be able to kick off builds using a
> specific commit hash, rather than automatically for each PR.

My only observation about it is that this will require a non commiter to
send an email to the dev list to request kick builds before actually
sending the "Please review" email.

could offer a nice balance - enable shorter cycles with CI builds, but not
> consuming vast amounts of resource with PRs that might not be ready.


+1, because we don't want to waste resource on WIP PRs.

El lun., 7 ene. 2019 a las 5:58, Jonathan Gallimore (<
jonathan.gallim...@gmail.com>) escribió:

> A couple of updates on this. I have a Jenkins install at home, which now
> runs master with 5 test failures that we don't see on buildbot, so I don't
> think there is technically much that holds us back from using Jenkins over
> something else.
>
> In terms of PR building, there's an interesting discussion on
> bui...@apache.org. going on right now:
>
> https://lists.apache.org/thread.html/fa6332c09cb0de56c7f9c88af794edb4f86f1b54734c6bf21c0faf6c@%3Cbuilds.apache.org%3E
> - one suggestion was for committers to be able to kick off builds using a
> specific commit hash, rather than automatically for each PR. I thought that
> could offer a nice balance - enable shorter cycles with CI builds, but not
> consuming vast amounts of resource with PRs that might not be ready.
>
> Jon
>
> On Mon, Jan 7, 2019 at 11:33 AM Ivan Junckes Filho 
> wrote:
>
> > On Fri, Jan 4, 2019 at 7:24 PM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > On Fri, Jan 4, 2019 at 6:39 PM Ivan Junckes Filho <
> ivanjunc...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hey guys, can someone provide me the way to check if my PR is green?
> > > >
> > >
> > > Yep, run the build on your branch :-). I run builds on PRs when I
> review
> > > them. If you don't want to run the full build, you could run tests that
> > are
> > > relevant to your change. If you need guidance on possible impacts of a
> > PR,
> > > please ask :).
> > >
> > I know, just thought would be cool to have it on github so it is
> available
> > for whoever will review the PR and others to see.
> >
> > >
> > > Also, I wouldn't be scared of things being merged in and the build
> > > breaking. The key thing is to check it, and help fix it if there is a
> > > problem. The current CI builds on buildbot are available from here:
> > > https://ci.apache.org/buildbot.html
> > >
> > > Thanks for the url.
> >
> > >
> > > > Also, now that apache has migrated to gitbox, is there a way to
> > integrate
> > > > the build with github?
> > > >
> > >
> > > This wasn't a pre-requisite of being able to build PRs on a CI. If
> > someone
> > > wants to have a go at setting up something to run against PRs on Travis
> > or
> > > on ASF infrastructure, please do go for it. Its not something we can
> just
> > > "switch on" though I'm afraid. We do also need to be mindful that we
> have
> > > 27 open PRs and a build that takes 5 hours to run fully - so if we do
> > setup
> > > something like this, it will consume a fair bit of resource.
> > >
> > Jon
> > >
> > > I see your point, makes sense.
> >
> > >
> > > >
> > > > On Thu, Jan 3, 2019 at 10:03 AM Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com> wrote:
> > > >
> > > > > That'd be great indeed
> > > > >
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > >
> > > > > On Thu, Jan 3, 2019 at 12:26 PM Roberto Cortez
> > > >  > > > > >
> > > > > wrote:
> > > > >
> > > > > > Maybe Bruno would like to work on that, since he is heavily
> > involved
> > > > with
> > > > > > the EG and he did the integration for the last version?
> > > > > >
> > > > > > > On 3 Jan 2019, at 11:16, Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Ok, looks like the build is back to stable.
> > > > > > > There are 2 other votes currently. I'll do an update when the
> > vote
> > > is
> > > > > > > closed.
> > > > > > >
> > > > > > > Meanwhile, we need an action plan for fault tolerance. We need
> to
> > > > > > > investigate what happened or if we need to rework the
> > integration.
> > > > > > >
> > > > > > > --
> > > > > > > Jean-Louis Monteiro
> > > > > > > http://twitter.com/jlouismonteiro
> > > > > > > http://www.tomitribe.com
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Jan 2, 2019 at 7:57 PM Bruno Baptista <
> > bruno...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > >> I think there's a vote for a minor release fixing an issue
> > there.
> > > > > > >>
> > > > > > >> Bruno Baptista
> > > > > > >> https://twitter.com/brunobat_
> > > > > > >>
> > > > > > >>
> > > > > > >> On 02/01/19 18:56, Roberto Cortez wrote:
> > > > > > >>> The OpenTracing update was also failing the TCK. I’ve
> reverted
> > it
> > > > > back
> > > > > > >> until we figure out what is going on.
> > > > > > >>>

Re: Investigating https://issues.apache.org/jira/browse/TOMEE-2403

[César Hernández Mendoza]

Hi Doychin,
By looking at TomEE-2403, it seems the issue was occurring only on TomEE CI
[1].
If you click on a specific build you can have access to the entire log, see
for instance:
https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8/builds/987/steps/test/logs/stdio

As a side note, I think this CI information can be something we can improve
on the TomEE website.

[1] https://ci.apache.org/builders/tomee-trunk-ubuntu-jvm8

El dom., 6 ene. 2019 a las 4:25, Doychin Bondzhev ()
escribió:

> Hi,
>
> I would like to investigate this issue:
> https://issues.apache.org/jira/browse/TOMEE-2403
>
> Where I can get more detailed error log regarding this issue?
>
> I tried to run the test locally but it works.
>
> --
> Doychin Bondzhev
> dSoft-Bulgaria Ltd.
> PowerPro - billing & provisioning solution for Service providers
> http://www.dsoft-bg.com/
> Mobile: +359888243116
>
>

-- 
Atentamente:
César Hernández Mendoza.

Re: Performance issue with JMS on Tomee 7.0.5

[exabrial12]

Thanks,

Issue opened here:
https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2449

We'll try and create a project that demonstrates the issue.



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: MicroProfile Fault Tolerance 1.1?

[Doychin Bondzhev]

I see now two issues.

I will try to report the the problem I found with jitter now.

On 7.1.2019 г. 15:05, Roberto Cortez [via TomEE & OpenEJB] wrote:
Hum… weird. Apparently you need to be logged in. Do you have an Apache 
JIRA account? If not, just create one and try again, please.


> On 7 Jan 2019, at 12:42, Doychin Bondzhev <[hidden email] 
> wrote:

>
> Thanks Roberto,
>
> Strange thing is that when I click the link that should display 
unresolved issues of safeguard I don't see any issues.

>
> I also don't see any issues at all when I remove the filter for status.
>
> On 7.1.2019 г. 14:10, Roberto Cortez [via TomEE & OpenEJB] wrote:
>> Hi Doychin,
>>
>> Safeguard is implemented under the Geronimo project umbrella, so if 
you need to report any issue, you need to report them in Geronimo JIRA:
>> 
https://jira.apache.org/jira/projects/GERONIMO  
> 


>>
>> Here you can find some issues:
>> 
https://jira.apache.org/jira/issues/?jql=project%20%3D%20GERONIMO%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22safeguard%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC  
> 


>>
>> Hope it helps!
>>
>> Cheers,
>> Roberto
>>
>> > On 7 Jan 2019, at 11:46, Doychin Bondzhev <[hidden email] 
> wrote:

>> >
>> > Actually this version of safegurad is not behaving properly with 
some tests which fail for different reasons.

>> >
>> > For example there is a bug in the implementation for jitter where 
if you provide 0 as value it will fail.
>> > Another problem I've noticed is when you run the tests for fault 
tolerance they fail because some embedded classes in safeguard are not 
recognized as CDI beans and when and instance have to be injected 
during test run test fails.

>> >
>> > If I add the these classes as part of the module and also add 
metrics API as test dependency test passes.

>> >
>> > That is why I asked where such problems can be reported back to 
safeguard developers.

>> > I can't find anything in Jirra regarding safeguard.
>> >
>> > On 7.1.2019 г. 13:16, Roberto Cortez [via TomEE & OpenEJB] wrote:
>> >> Yes,
>> >>
>> >> There is already a 1.1 Geronimo implementation compliant version 
(Safeguard). JL added it, but it was failing the TCK. We think we need 
to do some integration code to be able to use it properly. Bruno was 
going to do that, so we reverted back to 1.0 version so we can have a 
green build until we figure that out.

>> >>
>> >> Please check the following thread:
>> >> 
https://lists.apache.org/thread.html/0bc1c82d064f16f1cf0a5b70a9670cfcabe6b6aa9b0397fa396638f6@%3Cdev.tomee.apache.org%3E  
> 
 
>> 


>> >>
>> >> Cheers,
>> >> Roberto
>> >>
>> >> > On 6 Jan 2019, at 19:47, David Blevins <[hidden email] 
> wrote:

>> >> >
>> >> > Noticed we're using Fault Tolerance 1.0, whereas MicroProfile 
2.0 has Fault Tolerance 1.1.

>> >> >
>> >> > Is there a 1.1 implementation we can use?
>> >> >
>> >> >
>> >> > --
>> >> > David Blevins
>> >> > http://twitter.com/dblevins  
>
>> >> > http://www.tomitribe.com  
>

>> >> >
>> >>
>> >>
>> >>
>> >> If you reply to this email, your message will be added to the 
discussion below:
>> >> 
http://tomee-openejb.979440.n4.nabble.com/MicroProfile-Fault-Tolerance-1-1-tp4687293p4687306.html 

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Jean-Louis Monteiro]

Yes I agree and take it as you describe so it's all good. It's definitely a
step forward

Le lun. 7 janv. 2019 à 12:21, Gurkan Erdogdu  a écrit :

> Hello Jean-Louis and team,
> I want to emphasize again that this PR will not change anything regarding
> system properties. Its sole aim is to centralize all literal system
> properties into its own module. Maybe, for the future, if needed, we can
> update this module to add more configuration related functions. Currently
> all literal constants are distributed around the codebase. Before adding
> any more property, we need to discuss it first in here. So, one can easily
> find the used property this way.
> Regards.
> Gurkan
>
> On Mon, Jan 7, 2019 at 1:30 PM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> wrote:
>
> > Just want to make sure we don't forget System Properties were meant to be
> > used to override configuration and not to be the main configuration
> system
> > for TomEE.
> >
> > We can discuss it and decide to change our mind and TomEE, but as per
> now,
> > I'm not really keen to relying on system properties to configure TomEE.
> I'd
> > rather take the opportunity to yank some system properties when possible.
> >
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu 
> wrote:
> >
> > > Thanks Jon.
> > >
> > > I don't have any aim to replace service-jar.xml approach. We will just
> > add
> > > another YAML based configuration support. Therefore, all tomee.xml,
> > > resources.xml etc will be stay in there. YAML is just an additional
> > > feature.
> > >
> > > Introducing new module , tomee-config, allow us to centralise all
> > > configuration into one place and all other modules can use it via
> > > dependency. In the future, we can remove all configuration codes from
> > > openejb-core, etc. into this module. There are lots of system
> properties
> > > using in different modules, therefore each such module will add their
> > > properties into TomEESystemConfig class and then use it.
> > >
> > > Currently, openejb-core is a one large module. We may also think to
> > divide
> > > this module into smaller modules which are having special purpose.
> > >
> > > Hope it clears your concerns.
> > >
> > > Regards.
> > > Gurkan
> > >
> > > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > > > I commented on your PR - thanks for sending that over. I think it
> would
> > > be
> > > > worthwhile structuring the class with the constants in such a way
> that
> > > the
> > > > javadoc could end up on the website via David's site generation code.
> > > That
> > > > would be extremely cool and I'm sure a very useful piece of
> > > documentation.
> > > >
> > > > While I appreciate your service-jar.xml visibility comment, I suspect
> > > that
> > > > is because of something missing in its documentation, as opposed to
> an
> > > > issue with the design choice. I don't necessarily object to something
> > > that
> > > > can parse the config in YAML (I believe there is something that
> handles
> > > > JSON already), providing the existing config mechanism in XML, with
> the
> > > > defaults in service-jar.xml continued to work, and that I wouldn't be
> > > > forced to migrate from XML to YAML. Many users make use of tomee.xml
> > and
> > > > resources.xml in a huge number of applications. Forcing a migration
> on
> > > them
> > > > to YAML "just because" doesn't make sense to me. The concept of the
> > > > service-jar.xml is a very core design concept in TomEE and I would
> not
> > be
> > > > favour of changing it unless there was a really good rationale and a
> > > better
> > > > design proposed and discussed.
> > > >
> > > > I agree that system properties can lead to "magic" parameters that
> > aren't
> > > > well documented, and I'm definitely in favour of improving the
> > > > documentation of those properties. The ability to override config
> with
> > > > system properties, however, is useful and also widely used so we'll
> > need
> > > to
> > > > keep it.
> > > >
> > > > Jon
> > > >
> > > > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu 
> > > wrote:
> > > >
> > > > > For me, using services-jar.xml approach is not so visible to users.
> > All
> > > > > defaults are configured in this file and packaged within JAR file.
> > > Users
> > > > > are not able to read the parameter explanation from
> services-jar.xml
> > > > files.
> > > > > Also, services.-jar.xml is somebit different from using the system
> > > > > properties to turn-on/off something. I am also thinking to
> introduce
> > > YAML
> > > > > based configuration.
> > > > >
> > > > > But first step is to centralise all of these system parameters into
> > two
> > > > > classes. Maybe, we will see that some of them are unnecessary etc.
> > > > >
> > > > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista  >
> > > > wrote:
> > > > >
> > > > > >

Re: Metrics question

[Roberto Cortez]

Is just added as a library.

Any glue code is going to:
https://github.com/apache/tomee/tree/master/tomee/tomee-microprofile/mp-common 

> On 7 Jan 2019, at 12:51, Jonathan Gallimore  
> wrote:
> 
> Thanks Roberto.
> 
> One more question - metrics-wise, is there any gluecode, or is the
> implementation jar just added to lib/ and picked up through scanning?
> 
> Jon
> 
> On Mon, Jan 7, 2019 at 12:34 PM Roberto Cortez 
> wrote:
> 
>> The spec does not seem to be clear in that regard, maybe on purpose.
>> 
>> It if was supposed to work that way, that should be included in the TCK. I
>> find it hard to believe that it was not included, because someone forgot to
>> add it…
>> 
>> On the other hand, I can see the possible conflicts that it would cause on
>> the "/" context, and even considering that nothing is stopping you to
>> deploy your own app to "/“. Maybe we need to ask in the MP list about this..
>> 
>> I did found this on the MP Metrics project:
>> https://github.com/eclipse/microprofile-metrics/issues/65 <
>> https://github.com/eclipse/microprofile-metrics/issues/65>
>> 
>> Cheers,
>> Roberto
>> 
>>> On 7 Jan 2019, at 11:48, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>> 
>>> This: `curl -v
>>> http://localhost:8080/mp-metrics-counted-8.0.0-SNAPSHOT/metrics`
>>  - does
>>> work and includes both the base and application metrics.
>>> 
>>> Looking through the tests in microprofile-metrics-api-tck and
>>> microprofile-metrics-rest-tck, it looks like only accessing metrics via a
>>> CDI enabled application is actually tested. Should accessing /metrics
>> work?
>>> From my brief reading of the spec, it feels like it should work. There's
>> a
>>> fairly obvious conflict with the ROOT application, of course. Adding an
>>> empty beans.xml and setting metadata-complete to "false" in web.xml for
>> the
>>> ROOT app did make it work (although the output comes back as JSON as
>>> opposed to prometheus). Removing the ROOT app didn't work.
>>> 
>>> My reading of §2.3 of the spec here:
>>> 
>> https://github.com/eclipse/microprofile-metrics/releases/download/1.0.2-RC2/metrics_spec.pdf
>>> does suggest that /metrics should work, but I'd be interested in what
>>> others think.
>>> 
>>> Next question: is there a way that one could/should go about adding a
>>> vendor specific metric? I'd like to have a go at that.
>>> 
>>> Thanks,
>>> 
>>> Jon
>>> 
>>> On Mon, Jan 7, 2019 at 11:28 AM Jonathan Gallimore <
>>> jonathan.gallim...@gmail.com> wrote:
>>> 
 Even with one of the metrics samples deployed, I still get a 404 from
 http://localhost:8080/metrics.
 
 Jon
 
 On Mon, Jan 7, 2019 at 11:24 AM Roberto Cortez
>> 
 wrote:
 
> I believe it never worked that way. It always required to have an app
> deployed.
> 
>> On 7 Jan 2019, at 11:12, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
> wrote:
>> 
>> I'll have a look after lunch
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>> 
>> 
>> On Mon, Jan 7, 2019 at 12:10 PM Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>> 
>>> Ah right. It isn't working for me on a build of master. All I've done
> is
>>> build it, extract the tar.gz for MicroProfile, run catalina.sh run,
> and try
>>> the curl command I mentioned. No other customization, no additional
> apps
>>> deployed.
>>> 
>>> I'm not sure if I have missed a step, or a switch. Looking at the TCK
> now
>>> to see if there is something I have missed. If anyone knows anything
>>> obvious, please let me know!
>>> 
>>> Jon
>>> 
>>> On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
>>> jlmonte...@tomitribe.com> wrote:
>>> 
 Yes you should get vendor, system and app name space
 
 Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
 jonathan.gallim...@gmail.com> a écrit :
 
> Apologies if this is a stupid question... but if I extract the
 MicroProfile
> flavor of TomEE, and try and do `curl
>> http://localhost:8080/metrics` 
> 
>>> 
 
>  -
> should I get some built in basic metric data back?
> 
> Thanks
> 
> Jon
> 
 
>>> 
> 
> 
>> 
>> 

Re: MicroProfile Fault Tolerance 1.1?

[Roberto Cortez]

Hum… weird. Apparently you need to be logged in. Do you have an Apache JIRA 
account? If not, just create one and try again, please.

> On 7 Jan 2019, at 12:42, Doychin Bondzhev  wrote:
> 
> Thanks Roberto, 
> 
> Strange thing is that when I click the link that should display unresolved 
> issues of safeguard I don't see any issues. 
> 
> I also don't see any issues at all when I remove the filter for status.
> 
> On 7.1.2019 г. 14:10, Roberto Cortez [via TomEE & OpenEJB] wrote:
>> Hi Doychin, 
>> 
>> Safeguard is implemented under the Geronimo project umbrella, so if you need 
>> to report any issue, you need to report them in Geronimo JIRA: 
>> https://jira.apache.org/jira/projects/GERONIMO 
>>  
>> > > 
>> 
>> Here you can find some issues: 
>> https://jira.apache.org/jira/issues/?jql=project%20%3D%20GERONIMO%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22safeguard%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>  
>> 
>>  
>> >  
>> >
>>  
>> 
>> Hope it helps! 
>> 
>> Cheers, 
>> Roberto 
>> 
>> > On 7 Jan 2019, at 11:46, Doychin Bondzhev <[hidden email] 
>> > > wrote: 
>> > 
>> > Actually this version of safegurad is not behaving properly with some 
>> > tests which fail for different reasons. 
>> > 
>> > For example there is a bug in the implementation for jitter where if you 
>> > provide 0 as value it will fail. 
>> > Another problem I've noticed is when you run the tests for fault tolerance 
>> > they fail because some embedded classes in safeguard are not recognized as 
>> > CDI beans and when and instance have to be injected during test run test 
>> > fails. 
>> > 
>> > If I add the these classes as part of the module and also add metrics API 
>> > as test dependency test passes. 
>> > 
>> > That is why I asked where such problems can be reported back to safeguard 
>> > developers. 
>> > I can't find anything in Jirra regarding safeguard. 
>> > 
>> > On 7.1.2019 г. 13:16, Roberto Cortez [via TomEE & OpenEJB] wrote: 
>> >> Yes, 
>> >> 
>> >> There is already a 1.1 Geronimo implementation compliant version 
>> >> (Safeguard). JL added it, but it was failing the TCK. We think we need to 
>> >> do some integration code to be able to use it properly. Bruno was going 
>> >> to do that, so we reverted back to 1.0 version so we can have a green 
>> >> build until we figure that out. 
>> >> 
>> >> Please check the following thread: 
>> >> https://lists.apache.org/thread.html/0bc1c82d064f16f1cf0a5b70a9670cfcabe6b6aa9b0397fa396638f6@%3Cdev.tomee.apache.org%3E
>> >>  
>> >> 
>> >>  
>> >> > >>  
>> >> >
>> >>  
>> >> > >>  
>> >> 
>> >>  
>> >> > >>  
>> >> >>
>> >>  
>> >> 
>> >> Cheers, 
>> >> Roberto 
>> >> 
>> >> > On 6 Jan 2019, at 19:47, David Blevins <[hidden email] 
>> >> > > wrote: 
>> >> > 
>> >> > Noticed we're using Fault Tolerance 1.0, whereas MicroProfile 2.0 has 
>> >> > Fault Tolerance 1.1. 
>> >> > 
>> >> > Is there a 1.1 implementation we can use? 
>> >> > 
>> >> > 
>> >> > -- 
>> >> > David Blevins 
>> >> > http://twitter.com/dblevins  
>> >> > > 
>> >> > http://www.tomitribe.com  
>> >> > > 
>> >> > 
>> >> 
>> >> 
>> >> 
>> >> If you reply to this email, your message will be added to the discussion 
>> >> below: 
>> >> http://tomee-openejb.979440.n4.nabble.com/MicroP

Re: Metrics question

[Jonathan Gallimore]

Thanks Roberto.

One more question - metrics-wise, is there any gluecode, or is the
implementation jar just added to lib/ and picked up through scanning?

Jon

On Mon, Jan 7, 2019 at 12:34 PM Roberto Cortez 
wrote:

> The spec does not seem to be clear in that regard, maybe on purpose.
>
> It if was supposed to work that way, that should be included in the TCK. I
> find it hard to believe that it was not included, because someone forgot to
> add it…
>
> On the other hand, I can see the possible conflicts that it would cause on
> the "/" context, and even considering that nothing is stopping you to
> deploy your own app to "/“. Maybe we need to ask in the MP list about this..
>
> I did found this on the MP Metrics project:
> https://github.com/eclipse/microprofile-metrics/issues/65 <
> https://github.com/eclipse/microprofile-metrics/issues/65>
>
> Cheers,
> Roberto
>
> > On 7 Jan 2019, at 11:48, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> >
> > This: `curl -v
> > http://localhost:8080/mp-metrics-counted-8.0.0-SNAPSHOT/metrics`
>  - does
> > work and includes both the base and application metrics.
> >
> > Looking through the tests in microprofile-metrics-api-tck and
> > microprofile-metrics-rest-tck, it looks like only accessing metrics via a
> > CDI enabled application is actually tested. Should accessing /metrics
> work?
> > From my brief reading of the spec, it feels like it should work. There's
> a
> > fairly obvious conflict with the ROOT application, of course. Adding an
> > empty beans.xml and setting metadata-complete to "false" in web.xml for
> the
> > ROOT app did make it work (although the output comes back as JSON as
> > opposed to prometheus). Removing the ROOT app didn't work.
> >
> > My reading of §2.3 of the spec here:
> >
> https://github.com/eclipse/microprofile-metrics/releases/download/1.0.2-RC2/metrics_spec.pdf
> > does suggest that /metrics should work, but I'd be interested in what
> > others think.
> >
> > Next question: is there a way that one could/should go about adding a
> > vendor specific metric? I'd like to have a go at that.
> >
> > Thanks,
> >
> > Jon
> >
> > On Mon, Jan 7, 2019 at 11:28 AM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> >> Even with one of the metrics samples deployed, I still get a 404 from
> >> http://localhost:8080/metrics.
> >>
> >> Jon
> >>
> >> On Mon, Jan 7, 2019 at 11:24 AM Roberto Cortez
> 
> >> wrote:
> >>
> >>> I believe it never worked that way. It always required to have an app
> >>> deployed.
> >>>
>  On 7 Jan 2019, at 11:12, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> >>> wrote:
> 
>  I'll have a look after lunch
>  --
>  Jean-Louis Monteiro
>  http://twitter.com/jlouismonteiro
>  http://www.tomitribe.com
> 
> 
>  On Mon, Jan 7, 2019 at 12:10 PM Jonathan Gallimore <
>  jonathan.gallim...@gmail.com> wrote:
> 
> > Ah right. It isn't working for me on a build of master. All I've done
> >>> is
> > build it, extract the tar.gz for MicroProfile, run catalina.sh run,
> >>> and try
> > the curl command I mentioned. No other customization, no additional
> >>> apps
> > deployed.
> >
> > I'm not sure if I have missed a step, or a switch. Looking at the TCK
> >>> now
> > to see if there is something I have missed. If anyone knows anything
> > obvious, please let me know!
> >
> > Jon
> >
> > On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> >> Yes you should get vendor, system and app name space
> >>
> >> Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> a écrit :
> >>
> >>> Apologies if this is a stupid question... but if I extract the
> >> MicroProfile
> >>> flavor of TomEE, and try and do `curl
> http://localhost:8080/metrics` 
> >>> 
> > 
> >> 
> >>>  -
> >>> should I get some built in basic metric data back?
> >>>
> >>> Thanks
> >>>
> >>> Jon
> >>>
> >>
> >
> >>>
> >>>
>
>

Re: MicroProfile Fault Tolerance 1.1?

[Doychin Bondzhev]

Thanks Roberto,

Strange thing is that when I click the link that should display 
unresolved issues of safeguard I don't see any issues.


I also don't see any issues at all when I remove the filter for status.

On 7.1.2019 г. 14:10, Roberto Cortez [via TomEE & OpenEJB] wrote:

Hi Doychin,

Safeguard is implemented under the Geronimo project umbrella, so if 
you need to report any issue, you need to report them in Geronimo JIRA:
https://jira.apache.org/jira/projects/GERONIMO  



Here you can find some issues:
https://jira.apache.org/jira/issues/?jql=project%20%3D%20GERONIMO%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22safeguard%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC  



Hope it helps!

Cheers,
Roberto

> On 7 Jan 2019, at 11:46, Doychin Bondzhev <[hidden email] 
> wrote:

>
> Actually this version of safegurad is not behaving properly with 
some tests which fail for different reasons.

>
> For example there is a bug in the implementation for jitter where if 
you provide 0 as value it will fail.
> Another problem I've noticed is when you run the tests for fault 
tolerance they fail because some embedded classes in safeguard are not 
recognized as CDI beans and when and instance have to be injected 
during test run test fails.

>
> If I add the these classes as part of the module and also add 
metrics API as test dependency test passes.

>
> That is why I asked where such problems can be reported back to 
safeguard developers.

> I can't find anything in Jirra regarding safeguard.
>
> On 7.1.2019 г. 13:16, Roberto Cortez [via TomEE & OpenEJB] wrote:
>> Yes,
>>
>> There is already a 1.1 Geronimo implementation compliant version 
(Safeguard). JL added it, but it was failing the TCK. We think we need 
to do some integration code to be able to use it properly. Bruno was 
going to do that, so we reverted back to 1.0 version so we can have a 
green build until we figure that out.

>>
>> Please check the following thread:
>> 
https://lists.apache.org/thread.html/0bc1c82d064f16f1cf0a5b70a9670cfcabe6b6aa9b0397fa396638f6@%3Cdev.tomee.apache.org%3E  
> 


>>
>> Cheers,
>> Roberto
>>
>> > On 6 Jan 2019, at 19:47, David Blevins <[hidden email] 
> wrote:

>> >
>> > Noticed we're using Fault Tolerance 1.0, whereas MicroProfile 2.0 
has Fault Tolerance 1.1.

>> >
>> > Is there a 1.1 implementation we can use?
>> >
>> >
>> > --
>> > David Blevins
>> > http://twitter.com/dblevins 
>> > http://www.tomitribe.com 
>> >
>>
>>
>>
>> If you reply to this email, your message will be added to the 
discussion below:
>> 
http://tomee-openejb.979440.n4.nabble.com/MicroProfile-Fault-Tolerance-1-1-tp4687293p4687306.html  

>> To start a new topic under TomEE Dev, email [hidden email] 
 

>> To unsubscribe from TomEE Dev, click here <
>> NAML 
 


> --
> Doychin Bondzhev
> dSoft-Bulgaria Ltd.
> PowerPro - billing & provisioning solution for Service providers
> http://www.dsoft-bg.com/ 
> Mobile: +359888243116
> 




If you reply to this email, your message will be added to the 
discussion below:
http://tomee-openejb.979440.n4.nabble.com/MicroProfile-Fault-Tolerance-1-1-tp4687293p4687315.html 

To start a new topic under TomEE Dev, email 
ml+s979440n982480...@n4.nabble.com
To unsubscribe from TomEE Dev, click here 
.
NAML 

Re: Metrics question

[Roberto Cortez]

The spec does not seem to be clear in that regard, maybe on purpose.

It if was supposed to work that way, that should be included in the TCK. I find 
it hard to believe that it was not included, because someone forgot to add it…

On the other hand, I can see the possible conflicts that it would cause on the 
"/" context, and even considering that nothing is stopping you to deploy your 
own app to "/“. Maybe we need to ask in the MP list about this..

I did found this on the MP Metrics project:
https://github.com/eclipse/microprofile-metrics/issues/65 


Cheers,
Roberto

> On 7 Jan 2019, at 11:48, Jonathan Gallimore  
> wrote:
> 
> This: `curl -v
> http://localhost:8080/mp-metrics-counted-8.0.0-SNAPSHOT/metrics` - does
> work and includes both the base and application metrics.
> 
> Looking through the tests in microprofile-metrics-api-tck and
> microprofile-metrics-rest-tck, it looks like only accessing metrics via a
> CDI enabled application is actually tested. Should accessing /metrics work?
> From my brief reading of the spec, it feels like it should work. There's a
> fairly obvious conflict with the ROOT application, of course. Adding an
> empty beans.xml and setting metadata-complete to "false" in web.xml for the
> ROOT app did make it work (although the output comes back as JSON as
> opposed to prometheus). Removing the ROOT app didn't work.
> 
> My reading of §2.3 of the spec here:
> https://github.com/eclipse/microprofile-metrics/releases/download/1.0.2-RC2/metrics_spec.pdf
> does suggest that /metrics should work, but I'd be interested in what
> others think.
> 
> Next question: is there a way that one could/should go about adding a
> vendor specific metric? I'd like to have a go at that.
> 
> Thanks,
> 
> Jon
> 
> On Mon, Jan 7, 2019 at 11:28 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
>> Even with one of the metrics samples deployed, I still get a 404 from
>> http://localhost:8080/metrics.
>> 
>> Jon
>> 
>> On Mon, Jan 7, 2019 at 11:24 AM Roberto Cortez 
>> wrote:
>> 
>>> I believe it never worked that way. It always required to have an app
>>> deployed.
>>> 
 On 7 Jan 2019, at 11:12, Jean-Louis Monteiro 
>>> wrote:
 
 I'll have a look after lunch
 --
 Jean-Louis Monteiro
 http://twitter.com/jlouismonteiro
 http://www.tomitribe.com
 
 
 On Mon, Jan 7, 2019 at 12:10 PM Jonathan Gallimore <
 jonathan.gallim...@gmail.com> wrote:
 
> Ah right. It isn't working for me on a build of master. All I've done
>>> is
> build it, extract the tar.gz for MicroProfile, run catalina.sh run,
>>> and try
> the curl command I mentioned. No other customization, no additional
>>> apps
> deployed.
> 
> I'm not sure if I have missed a step, or a switch. Looking at the TCK
>>> now
> to see if there is something I have missed. If anyone knows anything
> obvious, please let me know!
> 
> Jon
> 
> On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> 
>> Yes you should get vendor, system and app name space
>> 
>> Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> a écrit :
>> 
>>> Apologies if this is a stupid question... but if I extract the
>> MicroProfile
>>> flavor of TomEE, and try and do `curl http://localhost:8080/metrics`
>>> 
> 
>> 
>>>  -
>>> should I get some built in basic metric data back?
>>> 
>>> Thanks
>>> 
>>> Jon
>>> 
>> 
> 
>>> 
>>> 

Re: MicroProfile Fault Tolerance 1.1?

[Roberto Cortez]

Hi Doychin,

Safeguard is implemented under the Geronimo project umbrella, so if you need to 
report any issue, you need to report them in Geronimo JIRA:
https://jira.apache.org/jira/projects/GERONIMO 


Here you can find some issues:
https://jira.apache.org/jira/issues/?jql=project%20%3D%20GERONIMO%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22safeguard%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
 


Hope it helps!

Cheers,
Roberto

> On 7 Jan 2019, at 11:46, Doychin Bondzhev  wrote:
> 
> Actually this version of safegurad is not behaving properly with some tests 
> which fail for different reasons. 
> 
> For example there is a bug in the implementation for jitter where if you 
> provide 0 as value it will fail.
> Another problem I've noticed is when you run the tests for fault tolerance 
> they fail because some embedded classes in safeguard are not recognized as 
> CDI beans and when and instance have to be injected during test run test 
> fails. 
> 
> If I add the these classes as part of the module and also add metrics API as 
> test dependency test passes.
> 
> That is why I asked where such problems can be reported back to safeguard 
> developers.
> I can't find anything in Jirra regarding safeguard.
> 
> On 7.1.2019 г. 13:16, Roberto Cortez [via TomEE & OpenEJB] wrote:
>> Yes, 
>> 
>> There is already a 1.1 Geronimo implementation compliant version 
>> (Safeguard). JL added it, but it was failing the TCK. We think we need to do 
>> some integration code to be able to use it properly. Bruno was going to do 
>> that, so we reverted back to 1.0 version so we can have a green build until 
>> we figure that out. 
>> 
>> Please check the following thread: 
>> https://lists.apache.org/thread.html/0bc1c82d064f16f1cf0a5b70a9670cfcabe6b6aa9b0397fa396638f6@%3Cdev.tomee.apache.org%3E
>>  
>> 
>>  
>> >  
>> >
>>  
>> 
>> Cheers, 
>> Roberto 
>> 
>> > On 6 Jan 2019, at 19:47, David Blevins <[hidden email] 
>> > > wrote: 
>> > 
>> > Noticed we're using Fault Tolerance 1.0, whereas MicroProfile 2.0 has 
>> > Fault Tolerance 1.1. 
>> > 
>> > Is there a 1.1 implementation we can use? 
>> > 
>> > 
>> > -- 
>> > David Blevins 
>> > http://twitter.com/dblevins 
>> > http://www.tomitribe.com 
>> > 
>> 
>> 
>> 
>> If you reply to this email, your message will be added to the discussion 
>> below:
>> http://tomee-openejb.979440.n4.nabble.com/MicroProfile-Fault-Tolerance-1-1-tp4687293p4687306.html
>>  
>> 
>> To start a new topic under TomEE Dev, email 
>> ml+s979440n982480...@n4.nabble.com 
>>  
>> To unsubscribe from TomEE Dev, click here 
>> .
>> NAML 
>> 
> -- 
> Doychin Bondzhev
> dSoft-Bulgaria Ltd.
> PowerPro - billing & provisioning solution for Service providers
> http://www.dsoft-bg.com/ 
> Mobile: +359888243116
> 

Re: Stabilize TomEE Build

[Jonathan Gallimore]

A couple of updates on this. I have a Jenkins install at home, which now
runs master with 5 test failures that we don't see on buildbot, so I don't
think there is technically much that holds us back from using Jenkins over
something else.

In terms of PR building, there's an interesting discussion on
bui...@apache.org. going on right now:
https://lists.apache.org/thread.html/fa6332c09cb0de56c7f9c88af794edb4f86f1b54734c6bf21c0faf6c@%3Cbuilds.apache.org%3E
- one suggestion was for committers to be able to kick off builds using a
specific commit hash, rather than automatically for each PR. I thought that
could offer a nice balance - enable shorter cycles with CI builds, but not
consuming vast amounts of resource with PRs that might not be ready.

Jon

On Mon, Jan 7, 2019 at 11:33 AM Ivan Junckes Filho 
wrote:

> On Fri, Jan 4, 2019 at 7:24 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > On Fri, Jan 4, 2019 at 6:39 PM Ivan Junckes Filho  >
> > wrote:
> >
> > > Hey guys, can someone provide me the way to check if my PR is green?
> > >
> >
> > Yep, run the build on your branch :-). I run builds on PRs when I review
> > them. If you don't want to run the full build, you could run tests that
> are
> > relevant to your change. If you need guidance on possible impacts of a
> PR,
> > please ask :).
> >
> I know, just thought would be cool to have it on github so it is available
> for whoever will review the PR and others to see.
>
> >
> > Also, I wouldn't be scared of things being merged in and the build
> > breaking. The key thing is to check it, and help fix it if there is a
> > problem. The current CI builds on buildbot are available from here:
> > https://ci.apache.org/buildbot.html
> >
> > Thanks for the url.
>
> >
> > > Also, now that apache has migrated to gitbox, is there a way to
> integrate
> > > the build with github?
> > >
> >
> > This wasn't a pre-requisite of being able to build PRs on a CI. If
> someone
> > wants to have a go at setting up something to run against PRs on Travis
> or
> > on ASF infrastructure, please do go for it. Its not something we can just
> > "switch on" though I'm afraid. We do also need to be mindful that we have
> > 27 open PRs and a build that takes 5 hours to run fully - so if we do
> setup
> > something like this, it will consume a fair bit of resource.
> >
> Jon
> >
> > I see your point, makes sense.
>
> >
> > >
> > > On Thu, Jan 3, 2019 at 10:03 AM Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com> wrote:
> > >
> > > > That'd be great indeed
> > > >
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > >
> > > >
> > > > On Thu, Jan 3, 2019 at 12:26 PM Roberto Cortez
> > >  > > > >
> > > > wrote:
> > > >
> > > > > Maybe Bruno would like to work on that, since he is heavily
> involved
> > > with
> > > > > the EG and he did the integration for the last version?
> > > > >
> > > > > > On 3 Jan 2019, at 11:16, Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > Ok, looks like the build is back to stable.
> > > > > > There are 2 other votes currently. I'll do an update when the
> vote
> > is
> > > > > > closed.
> > > > > >
> > > > > > Meanwhile, we need an action plan for fault tolerance. We need to
> > > > > > investigate what happened or if we need to rework the
> integration.
> > > > > >
> > > > > > --
> > > > > > Jean-Louis Monteiro
> > > > > > http://twitter.com/jlouismonteiro
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > > >
> > > > > > On Wed, Jan 2, 2019 at 7:57 PM Bruno Baptista <
> bruno...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> I think there's a vote for a minor release fixing an issue
> there.
> > > > > >>
> > > > > >> Bruno Baptista
> > > > > >> https://twitter.com/brunobat_
> > > > > >>
> > > > > >>
> > > > > >> On 02/01/19 18:56, Roberto Cortez wrote:
> > > > > >>> The OpenTracing update was also failing the TCK. I’ve reverted
> it
> > > > back
> > > > > >> until we figure out what is going on.
> > > > > >>>
> > > > >  On 2 Jan 2019, at 16:50, Roberto Cortez
> > >  > > > >
> > > > > >> wrote:
> > > > > 
> > > > >  It seems to fail intermittently. It took me a few tries to
> make
> > it
> > > > > >> fail. On the latest buildbot it seems fine.
> > > > > 
> > > > >  Not sure if it was like this before or if it was something we
> > did.
> > > > > 
> > > > > > On 2 Jan 2019, at 12:14, Jean-Louis Monteiro <
> > > > > jlmonte...@tomitribe.com>
> > > > > >> wrote:
> > > > > >
> > > > > > [ERROR] Failures:
> > > > > > [ERROR]   LegacyServerTest.test:208->assertBalance:219 Bad
> > number
> > > > of
> > > > > > invocations for the bean "green". expected:<2> but was:<1>
> > > > > >
> > > > > > --
> > > > > > Jean-Louis Monteiro
> > > > > > http://twitter.com/jlouismonteiro
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > > >
> > > > > 

Re: Metrics question

[Jonathan Gallimore]

This: `curl -v
http://localhost:8080/mp-metrics-counted-8.0.0-SNAPSHOT/metrics` - does
work and includes both the base and application metrics.

Looking through the tests in microprofile-metrics-api-tck and
microprofile-metrics-rest-tck, it looks like only accessing metrics via a
CDI enabled application is actually tested. Should accessing /metrics work?
>From my brief reading of the spec, it feels like it should work. There's a
fairly obvious conflict with the ROOT application, of course. Adding an
empty beans.xml and setting metadata-complete to "false" in web.xml for the
ROOT app did make it work (although the output comes back as JSON as
opposed to prometheus). Removing the ROOT app didn't work.

My reading of §2.3 of the spec here:
https://github.com/eclipse/microprofile-metrics/releases/download/1.0.2-RC2/metrics_spec.pdf
does suggest that /metrics should work, but I'd be interested in what
others think.

Next question: is there a way that one could/should go about adding a
vendor specific metric? I'd like to have a go at that.

Thanks,

Jon

On Mon, Jan 7, 2019 at 11:28 AM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Even with one of the metrics samples deployed, I still get a 404 from
> http://localhost:8080/metrics.
>
> Jon
>
> On Mon, Jan 7, 2019 at 11:24 AM Roberto Cortez 
> wrote:
>
>> I believe it never worked that way. It always required to have an app
>> deployed.
>>
>> > On 7 Jan 2019, at 11:12, Jean-Louis Monteiro 
>> wrote:
>> >
>> > I'll have a look after lunch
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>> >
>> > On Mon, Jan 7, 2019 at 12:10 PM Jonathan Gallimore <
>> > jonathan.gallim...@gmail.com> wrote:
>> >
>> >> Ah right. It isn't working for me on a build of master. All I've done
>> is
>> >> build it, extract the tar.gz for MicroProfile, run catalina.sh run,
>> and try
>> >> the curl command I mentioned. No other customization, no additional
>> apps
>> >> deployed.
>> >>
>> >> I'm not sure if I have missed a step, or a switch. Looking at the TCK
>> now
>> >> to see if there is something I have missed. If anyone knows anything
>> >> obvious, please let me know!
>> >>
>> >> Jon
>> >>
>> >> On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
>> >> jlmonte...@tomitribe.com> wrote:
>> >>
>> >>> Yes you should get vendor, system and app name space
>> >>>
>> >>> Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
>> >>> jonathan.gallim...@gmail.com> a écrit :
>> >>>
>>  Apologies if this is a stupid question... but if I extract the
>> >>> MicroProfile
>>  flavor of TomEE, and try and do `curl http://localhost:8080/metrics`
>> 
>> >> 
>> >>> 
>>   -
>>  should I get some built in basic metric data back?
>> 
>>  Thanks
>> 
>>  Jon
>> 
>> >>>
>> >>
>>
>>

Re: MicroProfile Fault Tolerance 1.1?

[Doychin Bondzhev]

Actually this version of safegurad is not behaving properly with some 
tests which fail for different reasons.


For example there is a bug in the implementation for jitter where if you 
provide 0 as value it will fail.
Another problem I've noticed is when you run the tests for fault 
tolerance they fail because some embedded classes in safeguard are not 
recognized as CDI beans and when and instance have to be injected during 
test run test fails.


If I add the these classes as part of the module and also add metrics 
API as test dependency test passes.


That is why I asked where such problems can be reported back to 
safeguard developers.

I can't find anything in Jirra regarding safeguard.

On 7.1.2019 г. 13:16, Roberto Cortez [via TomEE & OpenEJB] wrote:

Yes,

There is already a 1.1 Geronimo implementation compliant version 
(Safeguard). JL added it, but it was failing the TCK. We think we need 
to do some integration code to be able to use it properly. Bruno was 
going to do that, so we reverted back to 1.0 version so we can have a 
green build until we figure that out.


Please check the following thread:
https://lists.apache.org/thread.html/0bc1c82d064f16f1cf0a5b70a9670cfcabe6b6aa9b0397fa396638f6@%3Cdev.tomee.apache.org%3E  



Cheers,
Roberto

> On 6 Jan 2019, at 19:47, David Blevins <[hidden email] 
> wrote:

>
> Noticed we're using Fault Tolerance 1.0, whereas MicroProfile 2.0 
has Fault Tolerance 1.1.

>
> Is there a 1.1 implementation we can use?
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>




If you reply to this email, your message will be added to the 
discussion below:
http://tomee-openejb.979440.n4.nabble.com/MicroProfile-Fault-Tolerance-1-1-tp4687293p4687306.html 

To start a new topic under TomEE Dev, email 
ml+s979440n982480...@n4.nabble.com
To unsubscribe from TomEE Dev, click here 
.
NAML 
 




--
Doychin Bondzhev
dSoft-Bulgaria Ltd.
PowerPro - billing & provisioning solution for Service providers
http://www.dsoft-bg.com/
Mobile: +359888243116

<>

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Stabilize TomEE Build

[Ivan Junckes Filho]

On Fri, Jan 4, 2019 at 7:24 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> On Fri, Jan 4, 2019 at 6:39 PM Ivan Junckes Filho 
> wrote:
>
> > Hey guys, can someone provide me the way to check if my PR is green?
> >
>
> Yep, run the build on your branch :-). I run builds on PRs when I review
> them. If you don't want to run the full build, you could run tests that are
> relevant to your change. If you need guidance on possible impacts of a PR,
> please ask :).
>
I know, just thought would be cool to have it on github so it is available
for whoever will review the PR and others to see.

>
> Also, I wouldn't be scared of things being merged in and the build
> breaking. The key thing is to check it, and help fix it if there is a
> problem. The current CI builds on buildbot are available from here:
> https://ci.apache.org/buildbot.html
>
> Thanks for the url.

>
> > Also, now that apache has migrated to gitbox, is there a way to integrate
> > the build with github?
> >
>
> This wasn't a pre-requisite of being able to build PRs on a CI. If someone
> wants to have a go at setting up something to run against PRs on Travis or
> on ASF infrastructure, please do go for it. Its not something we can just
> "switch on" though I'm afraid. We do also need to be mindful that we have
> 27 open PRs and a build that takes 5 hours to run fully - so if we do setup
> something like this, it will consume a fair bit of resource.
>
Jon
>
> I see your point, makes sense.

>
> >
> > On Thu, Jan 3, 2019 at 10:03 AM Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> > > That'd be great indeed
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Thu, Jan 3, 2019 at 12:26 PM Roberto Cortez
> >  > > >
> > > wrote:
> > >
> > > > Maybe Bruno would like to work on that, since he is heavily involved
> > with
> > > > the EG and he did the integration for the last version?
> > > >
> > > > > On 3 Jan 2019, at 11:16, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com
> > > >
> > > > wrote:
> > > > >
> > > > > Ok, looks like the build is back to stable.
> > > > > There are 2 other votes currently. I'll do an update when the vote
> is
> > > > > closed.
> > > > >
> > > > > Meanwhile, we need an action plan for fault tolerance. We need to
> > > > > investigate what happened or if we need to rework the integration.
> > > > >
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > >
> > > > > On Wed, Jan 2, 2019 at 7:57 PM Bruno Baptista 
> > > > wrote:
> > > > >
> > > > >> I think there's a vote for a minor release fixing an issue there.
> > > > >>
> > > > >> Bruno Baptista
> > > > >> https://twitter.com/brunobat_
> > > > >>
> > > > >>
> > > > >> On 02/01/19 18:56, Roberto Cortez wrote:
> > > > >>> The OpenTracing update was also failing the TCK. I’ve reverted it
> > > back
> > > > >> until we figure out what is going on.
> > > > >>>
> > > >  On 2 Jan 2019, at 16:50, Roberto Cortez
> >  > > >
> > > > >> wrote:
> > > > 
> > > >  It seems to fail intermittently. It took me a few tries to make
> it
> > > > >> fail. On the latest buildbot it seems fine.
> > > > 
> > > >  Not sure if it was like this before or if it was something we
> did.
> > > > 
> > > > > On 2 Jan 2019, at 12:14, Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com>
> > > > >> wrote:
> > > > >
> > > > > [ERROR] Failures:
> > > > > [ERROR]   LegacyServerTest.test:208->assertBalance:219 Bad
> number
> > > of
> > > > > invocations for the bean "green". expected:<2> but was:<1>
> > > > >
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > >
> > > > > On Wed, Jan 2, 2019 at 1:14 PM Jean-Louis Monteiro <
> > > > >> jlmonte...@tomitribe.com>
> > > > > wrote:
> > > > >
> > > > >> I also get this one locally
> > > > >>
> > > > >> --
> > > > >> Jean-Louis Monteiro
> > > > >> http://twitter.com/jlouismonteiro
> > > > >> http://www.tomitribe.com
> > > > >>
> > > > >>
> > > > >> On Wed, Jan 2, 2019 at 1:05 PM Roberto Cortez
> > > > >> 
> > > > >> wrote:
> > > > >>
> > > > >>> One issue at least was with the Safeguard upgrade. I’ve
> > reverted
> > > it
> > > > >> back.
> > > > >>> Lets see if this helps.
> > > > >>>
> > > >  On 2 Jan 2019, at 11:33, Roberto Cortez
> > > >  > > > >>>
> > > > >>> wrote:
> > > >  Yeah, just noticed it as well. Was about to send a message
> > too.
> > > I
> > > > >> can
> > > > >>> have a look.
> > > > > On 2 Jan 2019, at 11:00, Jean-Louis Monteiro <
> > > > >> jlmonte...@tomitribe.com>
> > > > >>> wrote:
> > > > > Ok, looks like we are back to red.
> > > > > Someone working on it?
> > > > > --

Re: Metrics question

[Jonathan Gallimore]

Even with one of the metrics samples deployed, I still get a 404 from
http://localhost:8080/metrics.

Jon

On Mon, Jan 7, 2019 at 11:24 AM Roberto Cortez 
wrote:

> I believe it never worked that way. It always required to have an app
> deployed.
>
> > On 7 Jan 2019, at 11:12, Jean-Louis Monteiro 
> wrote:
> >
> > I'll have a look after lunch
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Mon, Jan 7, 2019 at 12:10 PM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> >> Ah right. It isn't working for me on a build of master. All I've done is
> >> build it, extract the tar.gz for MicroProfile, run catalina.sh run, and
> try
> >> the curl command I mentioned. No other customization, no additional apps
> >> deployed.
> >>
> >> I'm not sure if I have missed a step, or a switch. Looking at the TCK
> now
> >> to see if there is something I have missed. If anyone knows anything
> >> obvious, please let me know!
> >>
> >> Jon
> >>
> >> On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com> wrote:
> >>
> >>> Yes you should get vendor, system and app name space
> >>>
> >>> Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
> >>> jonathan.gallim...@gmail.com> a écrit :
> >>>
>  Apologies if this is a stupid question... but if I extract the
> >>> MicroProfile
>  flavor of TomEE, and try and do `curl http://localhost:8080/metrics`
> 
> >> 
> >>> 
>   -
>  should I get some built in basic metric data back?
> 
>  Thanks
> 
>  Jon
> 
> >>>
> >>
>
>

Re: Metrics question

[Roberto Cortez]

I believe it never worked that way. It always required to have an app deployed.

> On 7 Jan 2019, at 11:12, Jean-Louis Monteiro  wrote:
> 
> I'll have a look after lunch
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Mon, Jan 7, 2019 at 12:10 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
>> Ah right. It isn't working for me on a build of master. All I've done is
>> build it, extract the tar.gz for MicroProfile, run catalina.sh run, and try
>> the curl command I mentioned. No other customization, no additional apps
>> deployed.
>> 
>> I'm not sure if I have missed a step, or a switch. Looking at the TCK now
>> to see if there is something I have missed. If anyone knows anything
>> obvious, please let me know!
>> 
>> Jon
>> 
>> On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com> wrote:
>> 
>>> Yes you should get vendor, system and app name space
>>> 
>>> Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
>>> jonathan.gallim...@gmail.com> a écrit :
>>> 
 Apologies if this is a stupid question... but if I extract the
>>> MicroProfile
 flavor of TomEE, and try and do `curl http://localhost:8080/metrics`
>> 
>>> 
  -
 should I get some built in basic metric data back?
 
 Thanks
 
 Jon
 
>>> 
>> 

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Gurkan Erdogdu]

Hello Jean-Louis and team,
I want to emphasize again that this PR will not change anything regarding
system properties. Its sole aim is to centralize all literal system
properties into its own module. Maybe, for the future, if needed, we can
update this module to add more configuration related functions. Currently
all literal constants are distributed around the codebase. Before adding
any more property, we need to discuss it first in here. So, one can easily
find the used property this way.
Regards.
Gurkan

On Mon, Jan 7, 2019 at 1:30 PM Jean-Louis Monteiro 
wrote:

> Just want to make sure we don't forget System Properties were meant to be
> used to override configuration and not to be the main configuration system
> for TomEE.
>
> We can discuss it and decide to change our mind and TomEE, but as per now,
> I'm not really keen to relying on system properties to configure TomEE. I'd
> rather take the opportunity to yank some system properties when possible.
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu  wrote:
>
> > Thanks Jon.
> >
> > I don't have any aim to replace service-jar.xml approach. We will just
> add
> > another YAML based configuration support. Therefore, all tomee.xml,
> > resources.xml etc will be stay in there. YAML is just an additional
> > feature.
> >
> > Introducing new module , tomee-config, allow us to centralise all
> > configuration into one place and all other modules can use it via
> > dependency. In the future, we can remove all configuration codes from
> > openejb-core, etc. into this module. There are lots of system properties
> > using in different modules, therefore each such module will add their
> > properties into TomEESystemConfig class and then use it.
> >
> > Currently, openejb-core is a one large module. We may also think to
> divide
> > this module into smaller modules which are having special purpose.
> >
> > Hope it clears your concerns.
> >
> > Regards.
> > Gurkan
> >
> > On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > I commented on your PR - thanks for sending that over. I think it would
> > be
> > > worthwhile structuring the class with the constants in such a way that
> > the
> > > javadoc could end up on the website via David's site generation code.
> > That
> > > would be extremely cool and I'm sure a very useful piece of
> > documentation.
> > >
> > > While I appreciate your service-jar.xml visibility comment, I suspect
> > that
> > > is because of something missing in its documentation, as opposed to an
> > > issue with the design choice. I don't necessarily object to something
> > that
> > > can parse the config in YAML (I believe there is something that handles
> > > JSON already), providing the existing config mechanism in XML, with the
> > > defaults in service-jar.xml continued to work, and that I wouldn't be
> > > forced to migrate from XML to YAML. Many users make use of tomee.xml
> and
> > > resources.xml in a huge number of applications. Forcing a migration on
> > them
> > > to YAML "just because" doesn't make sense to me. The concept of the
> > > service-jar.xml is a very core design concept in TomEE and I would not
> be
> > > favour of changing it unless there was a really good rationale and a
> > better
> > > design proposed and discussed.
> > >
> > > I agree that system properties can lead to "magic" parameters that
> aren't
> > > well documented, and I'm definitely in favour of improving the
> > > documentation of those properties. The ability to override config with
> > > system properties, however, is useful and also widely used so we'll
> need
> > to
> > > keep it.
> > >
> > > Jon
> > >
> > > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu 
> > wrote:
> > >
> > > > For me, using services-jar.xml approach is not so visible to users.
> All
> > > > defaults are configured in this file and packaged within JAR file.
> > Users
> > > > are not able to read the parameter explanation from services-jar.xml
> > > files.
> > > > Also, services.-jar.xml is somebit different from using the system
> > > > properties to turn-on/off something. I am also thinking to introduce
> > YAML
> > > > based configuration.
> > > >
> > > > But first step is to centralise all of these system parameters into
> two
> > > > classes. Maybe, we will see that some of them are unnecessary etc.
> > > >
> > > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista 
> > > wrote:
> > > >
> > > > > Yes, there is.
> > > > >
> > > > > This is also the most basic MP spec and nothing prevents us from
> > using
> > > > > it everywhere.
> > > > >
> > > > > There might be Jakarta EE restrictions in how to handle
> > configurations
> > > > > that need to be assessed.
> > > > >
> > > > > Overall, I think that if we are going to mess with configs, we
> should
> > > > > use state of the art.
> > > > >
> > > > > Cheers
> > > > >
> > > > > Bruno Ba

Re: Metrics question

[Jonathan Gallimore]

Thanks, I appreciate it. I'll run the tests and post my output.

Jon

On Mon, Jan 7, 2019 at 11:12 AM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> I'll have a look after lunch
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Mon, Jan 7, 2019 at 12:10 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Ah right. It isn't working for me on a build of master. All I've done is
> > build it, extract the tar.gz for MicroProfile, run catalina.sh run, and
> try
> > the curl command I mentioned. No other customization, no additional apps
> > deployed.
> >
> > I'm not sure if I have missed a step, or a switch. Looking at the TCK now
> > to see if there is something I have missed. If anyone knows anything
> > obvious, please let me know!
> >
> > Jon
> >
> > On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> > > Yes you should get vendor, system and app name space
> > >
> > > Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> a écrit :
> > >
> > > > Apologies if this is a stupid question... but if I extract the
> > > MicroProfile
> > > > flavor of TomEE, and try and do `curl http://localhost:8080/metrics`
> 
> > 
> > > 
> > > >  -
> > > > should I get some built in basic metric data back?
> > > >
> > > > Thanks
> > > >
> > > > Jon
> > > >
> > >
> >
>

Re: MicroProfile Fault Tolerance 1.1?

[Roberto Cortez]

Yes,

There is already a 1.1 Geronimo implementation compliant version (Safeguard). 
JL added it, but it was failing the TCK. We think we need to do some 
integration code to be able to use it properly. Bruno was going to do that, so 
we reverted back to 1.0 version so we can have a green build until we figure 
that out.

Please check the following thread:
https://lists.apache.org/thread.html/0bc1c82d064f16f1cf0a5b70a9670cfcabe6b6aa9b0397fa396638f6@%3Cdev.tomee.apache.org%3E
 


Cheers,
Roberto

> On 6 Jan 2019, at 19:47, David Blevins  wrote:
> 
> Noticed we're using Fault Tolerance 1.0, whereas MicroProfile 2.0 has Fault 
> Tolerance 1.1.
> 
> Is there a 1.1 implementation we can use?
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 

Re: Metrics question

[Jean-Louis Monteiro]

I'll have a look after lunch
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Mon, Jan 7, 2019 at 12:10 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Ah right. It isn't working for me on a build of master. All I've done is
> build it, extract the tar.gz for MicroProfile, run catalina.sh run, and try
> the curl command I mentioned. No other customization, no additional apps
> deployed.
>
> I'm not sure if I have missed a step, or a switch. Looking at the TCK now
> to see if there is something I have missed. If anyone knows anything
> obvious, please let me know!
>
> Jon
>
> On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
> > Yes you should get vendor, system and app name space
> >
> > Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> a écrit :
> >
> > > Apologies if this is a stupid question... but if I extract the
> > MicroProfile
> > > flavor of TomEE, and try and do `curl http://localhost:8080/metrics`
> 
> > 
> > >  -
> > > should I get some built in basic metric data back?
> > >
> > > Thanks
> > >
> > > Jon
> > >
> >
>

Re: Metrics question

[Jean-Louis Monteiro]

I used it and demoed it at Devoxx MA. So something might have changed if it
does not work now.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Mon, Jan 7, 2019 at 12:10 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Ah right. It isn't working for me on a build of master. All I've done is
> build it, extract the tar.gz for MicroProfile, run catalina.sh run, and try
> the curl command I mentioned. No other customization, no additional apps
> deployed.
>
> I'm not sure if I have missed a step, or a switch. Looking at the TCK now
> to see if there is something I have missed. If anyone knows anything
> obvious, please let me know!
>
> Jon
>
> On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
> > Yes you should get vendor, system and app name space
> >
> > Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> a écrit :
> >
> > > Apologies if this is a stupid question... but if I extract the
> > MicroProfile
> > > flavor of TomEE, and try and do `curl http://localhost:8080/metrics`
> 
> > 
> > >  -
> > > should I get some built in basic metric data back?
> > >
> > > Thanks
> > >
> > > Jon
> > >
> >
>

Re: Metrics question

[Jonathan Gallimore]

Ah right. It isn't working for me on a build of master. All I've done is
build it, extract the tar.gz for MicroProfile, run catalina.sh run, and try
the curl command I mentioned. No other customization, no additional apps
deployed.

I'm not sure if I have missed a step, or a switch. Looking at the TCK now
to see if there is something I have missed. If anyone knows anything
obvious, please let me know!

Jon

On Mon, Jan 7, 2019 at 11:05 AM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Yes you should get vendor, system and app name space
>
> Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> a écrit :
>
> > Apologies if this is a stupid question... but if I extract the
> MicroProfile
> > flavor of TomEE, and try and do `curl http://localhost:8080/metrics`
> 
> >  -
> > should I get some built in basic metric data back?
> >
> > Thanks
> >
> > Jon
> >
>

Re: Metrics question

[Jean-Louis Monteiro]

Yes you should get vendor, system and app name space

Le lun. 7 janv. 2019 à 12:03, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> Apologies if this is a stupid question... but if I extract the MicroProfile
> flavor of TomEE, and try and do `curl http://localhost:8080/metrics`
>  -
> should I get some built in basic metric data back?
>
> Thanks
>
> Jon
>

Metrics question

[Jonathan Gallimore]

Apologies if this is a stupid question... but if I extract the MicroProfile
flavor of TomEE, and try and do `curl http://localhost:8080/metrics` -
should I get some built in basic metric data back?

Thanks

Jon

Re: [DISCUSS] Regarding TomEE and OpenEJB related system properties

[Jean-Louis Monteiro]

Just want to make sure we don't forget System Properties were meant to be
used to override configuration and not to be the main configuration system
for TomEE.

We can discuss it and decide to change our mind and TomEE, but as per now,
I'm not really keen to relying on system properties to configure TomEE. I'd
rather take the opportunity to yank some system properties when possible.



--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Fri, Jan 4, 2019 at 7:28 AM Gurkan Erdogdu  wrote:

> Thanks Jon.
>
> I don't have any aim to replace service-jar.xml approach. We will just add
> another YAML based configuration support. Therefore, all tomee.xml,
> resources.xml etc will be stay in there. YAML is just an additional
> feature.
>
> Introducing new module , tomee-config, allow us to centralise all
> configuration into one place and all other modules can use it via
> dependency. In the future, we can remove all configuration codes from
> openejb-core, etc. into this module. There are lots of system properties
> using in different modules, therefore each such module will add their
> properties into TomEESystemConfig class and then use it.
>
> Currently, openejb-core is a one large module. We may also think to divide
> this module into smaller modules which are having special purpose.
>
> Hope it clears your concerns.
>
> Regards.
> Gurkan
>
> On Thu, Jan 3, 2019 at 11:30 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > I commented on your PR - thanks for sending that over. I think it would
> be
> > worthwhile structuring the class with the constants in such a way that
> the
> > javadoc could end up on the website via David's site generation code.
> That
> > would be extremely cool and I'm sure a very useful piece of
> documentation.
> >
> > While I appreciate your service-jar.xml visibility comment, I suspect
> that
> > is because of something missing in its documentation, as opposed to an
> > issue with the design choice. I don't necessarily object to something
> that
> > can parse the config in YAML (I believe there is something that handles
> > JSON already), providing the existing config mechanism in XML, with the
> > defaults in service-jar.xml continued to work, and that I wouldn't be
> > forced to migrate from XML to YAML. Many users make use of tomee.xml and
> > resources.xml in a huge number of applications. Forcing a migration on
> them
> > to YAML "just because" doesn't make sense to me. The concept of the
> > service-jar.xml is a very core design concept in TomEE and I would not be
> > favour of changing it unless there was a really good rationale and a
> better
> > design proposed and discussed.
> >
> > I agree that system properties can lead to "magic" parameters that aren't
> > well documented, and I'm definitely in favour of improving the
> > documentation of those properties. The ability to override config with
> > system properties, however, is useful and also widely used so we'll need
> to
> > keep it.
> >
> > Jon
> >
> > On Wed, Jan 2, 2019 at 9:53 AM Gurkan Erdogdu 
> wrote:
> >
> > > For me, using services-jar.xml approach is not so visible to users. All
> > > defaults are configured in this file and packaged within JAR file.
> Users
> > > are not able to read the parameter explanation from services-jar.xml
> > files.
> > > Also, services.-jar.xml is somebit different from using the system
> > > properties to turn-on/off something. I am also thinking to introduce
> YAML
> > > based configuration.
> > >
> > > But first step is to centralise all of these system parameters into two
> > > classes. Maybe, we will see that some of them are unnecessary etc.
> > >
> > > On Wed, Jan 2, 2019 at 12:44 PM Bruno Baptista 
> > wrote:
> > >
> > > > Yes, there is.
> > > >
> > > > This is also the most basic MP spec and nothing prevents us from
> using
> > > > it everywhere.
> > > >
> > > > There might be Jakarta EE restrictions in how to handle
> configurations
> > > > that need to be assessed.
> > > >
> > > > Overall, I think that if we are going to mess with configs, we should
> > > > use state of the art.
> > > >
> > > > Cheers
> > > >
> > > > Bruno Baptista
> > > > https://twitter.com/brunobat_
> > > >
> > > >
> > > > On 02/01/19 09:35, Jean-Louis Monteiro wrote:
> > > > > I think with microprofile-config we may have a chicken and the egg
> > > > problem,
> > > > > isn't it?
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > >
> > > > > On Wed, Jan 2, 2019 at 10:30 AM Bruno Baptista  >
> > > > wrote:
> > > > >
> > > > >> Hi Gurkan,
> > > > >>
> > > > >> I agree we have a problem with the documentation of the different
> > > > >> properties and that we need to improve it.
> > > > >>
> > > > >> Doing the inventory and using the proposed syntax looks ok to me
> > but I
> > > > >> also think we should go even further.
> > > > >>
> > > > >> How about to migrate al

Re: Performance issue with JMS on Tomee 7.0.5

[Wiesner, Martin]

Hi Jonathan,

could you open a JIRA for the below topic, please? It makes it a lot easier to 
track the weird behaviour and it is so important to document your observations. 
Thereby, we’ll be able to reference this issue in upcoming discussions. Please 
put additional material into the JIRA, as long as you can provide it (legally 
speaking).

Optional: Can you a MWE that demonstrates the issue somehow?

Best
Martin
—
https://twitter.com/mawiesne 


> Am 07.01.2019 um 03:47 schrieb exabrial12 :
> 
> Hey guys,
> 
> We're noticing a pretty strange issue processing a large number of JMS
> messages. After about 20k messages, messages consumed per second drops off
> and there's heavy GC activity (smells like a memory leak). What interesting
> though is the server continues to run and doesn't OutOfMemoryError. A simple
> restart of TomEE (but not the broker) temporarily fixes the problem. We're
> using an external broker, not the internal one
> 
> What's interesting, is that Jonathan Gallimore and I were talking about a
> similar issue with Websockets. We noticed that eventually the servers will
> exhibit the same behavior once enough websockets are opened and closed. This
> issue occurs infrequently enough because we might handle 20,000 websockets
> over the course of a few days, but we can process 20,000 JMS messages in a
> few mins.
> 
> 
> I have a heap dump from the issue and several jstacks. I'll be honest, I'm
> not sure where to start. In the past I've solved memory leaks by careful
> code audits. Our codebase happens to be mostly stateless, with everything
> else being managed by CDI scopes (ApplicationScoped and TransactionScoped).
> 
> What's a good way to get started?
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html



smime.p7s
Description: S/MIME cryptographic signature