Re: Potentially having some part of documentation in the main repo

[Romain Manni-Bucau]

arent we already using asciidoc? (
https://github.com/apache/tomee-site-generator/tree/master/src/main/jbake/content
)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-09-25 16:56 GMT+02:00 Andy Gumbrecht <andy...@gmx.de>:

> +1 for asciidoc
>
> Andy Gumbrecht.
>
>
>
> On 19/09/17 10:15, Jean-Louis Monteiro wrote:
>
>> I totally agree that our documentation is a pain and does not help us
>> first
>> to right it and contributors to help.
>> Each time I have to do a fix or add something it's a pain.
>>
>> So +1 to simplify it.
>> JBake, plain asciidoc, whatever. Just something simple.
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>> On Sun, Sep 17, 2017 at 8:09 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> wrote:
>>
>> +0 to have it all and sync somehow in the site build process - i like
>>> having it with the code since it enables some more stuff to happen but it
>>> increases contribution cost
>>> -0 to have it partially to ensure we dont loose contributors
>>>
>>> Side note: if you import it, ensure to update all the contributor docs
>>> and
>>> github proxies please
>>>
>>> Side note 2: we can still generate doc in another project depending on
>>> main
>>> artifacts ;)
>>>
>>> Le 17 sept. 2017 05:26, "David Blevins" <david.blev...@gmail.com> a
>>> écrit
>>> :
>>>
>>> Just wrote a long description on the definition of InvocationTime and
>>>> MonitoredMethods in the JMX `@Monitor` functionality and I'm reminded on
>>>> how much of a pain it is to contribute to the documentation.  It would
>>>> be
>>>> so much easier if some part of it was in the build.
>>>>
>>>> I'm wondering if we want some sort of docs/ directory in our main repo.
>>>> Not thinking we add jbake to the main build, just the asciidoc.  The
>>>>
>>> fancy
>>>
>>>> processing can still happen elsewhere.
>>>>
>>>> Docs like "how to contribute to the website" would stay where they are,
>>>> but things like "configuring datasources" would definitely come in.
>>>> We'd
>>>> then follow the Tomcat approach of:
>>>>
>>>>   - https://tomcat.apache.org/tomcat-8.5-doc/index.html <
>>>> https://tomcat.apache.org/tomcat-8.5-doc/index.html>
>>>>   - https://tomcat.apache.org/tomcat-8.0-doc/index.html <
>>>> https://tomcat.apache.org/tomcat-8.0-doc/index.html>
>>>>
>>>> etc.
>>>>
>>>> I don't think we'd need to get too fancy and do one doc base per Web
>>>> Profile, Plume, etc.  just this would be enough:
>>>>
>>>>   - https://tomee.apache.org/tomee-8.0-doc/index.html <
>>>> https://tomee.apache.org/tomee-8.0-doc/index.html>
>>>>   - https://tomee.apache.org/tomee-7.0-doc/index.html <
>>>> https://tomee.apache.org/tomee-7.0-doc/index.html>
>>>>   - https://tomee.apache.org/tomee-1.7-doc/index.html <
>>>> https://tomee.apache.org/tomee-1.7-doc/index.html>
>>>>
>>>> When sheldon/chatterbox come in, they'd go:
>>>>
>>>>   - https://tomee.apache.org/sheldon-3.0-doc/index.html <
>>>> https://tomee.apache.org/sheldon-3.0-doc/index.html>
>>>>   - https://tomee.apache.org/chatterbox-2.1-doc/index.html <
>>>> https://tomee.apache.org/chatterbox-2.1-doc/index.html>
>>>>
>>>> I totally made up those version numbers for illustrative purposes.  You
>>>> get the idea.
>>>>
>>>> Related note, we actually have some documentation generated from the
>>>>
>>> build
>>>
>>>> and not regenerated.  This page for example was entirely generated from
>>>>
>>> the
>>>
>>>> default service-jar.xml:
>>>>
>>>>   - http://tomee.apache.org/containers-and-resources.html <
>>>> http://tomee.apache.org/containers-and-resources.html>
>>>>
>>>> I remember doing that ages ago, like 2008-2011 range.  Aside from being
>>>> likely out of date, it definitely highlights the awkward relationship
>>>> between the docs and the source we currently have.
>>>>
>>>>
>>>> --
>>>> David Blevins
>>>> http://twitter.com/dblevins
>>>> http://www.tomitribe.com
>>>>
>>>>
>>>>
>

Re: Potentially having some part of documentation in the main repo

[Romain Manni-Bucau]

+0 to have it all and sync somehow in the site build process - i like
having it with the code since it enables some more stuff to happen but it
increases contribution cost
-0 to have it partially to ensure we dont loose contributors

Side note: if you import it, ensure to update all the contributor docs and
github proxies please

Side note 2: we can still generate doc in another project depending on main
artifacts ;)

Le 17 sept. 2017 05:26, "David Blevins"  a écrit :

> Just wrote a long description on the definition of InvocationTime and
> MonitoredMethods in the JMX `@Monitor` functionality and I'm reminded on
> how much of a pain it is to contribute to the documentation.  It would be
> so much easier if some part of it was in the build.
>
> I'm wondering if we want some sort of docs/ directory in our main repo.
> Not thinking we add jbake to the main build, just the asciidoc.  The fancy
> processing can still happen elsewhere.
>
> Docs like "how to contribute to the website" would stay where they are,
> but things like "configuring datasources" would definitely come in.  We'd
> then follow the Tomcat approach of:
>
>  - https://tomcat.apache.org/tomcat-8.5-doc/index.html <
> https://tomcat.apache.org/tomcat-8.5-doc/index.html>
>  - https://tomcat.apache.org/tomcat-8.0-doc/index.html <
> https://tomcat.apache.org/tomcat-8.0-doc/index.html>
>
> etc.
>
> I don't think we'd need to get too fancy and do one doc base per Web
> Profile, Plume, etc.  just this would be enough:
>
>  - https://tomee.apache.org/tomee-8.0-doc/index.html <
> https://tomee.apache.org/tomee-8.0-doc/index.html>
>  - https://tomee.apache.org/tomee-7.0-doc/index.html <
> https://tomee.apache.org/tomee-7.0-doc/index.html>
>  - https://tomee.apache.org/tomee-1.7-doc/index.html <
> https://tomee.apache.org/tomee-1.7-doc/index.html>
>
> When sheldon/chatterbox come in, they'd go:
>
>  - https://tomee.apache.org/sheldon-3.0-doc/index.html <
> https://tomee.apache.org/sheldon-3.0-doc/index.html>
>  - https://tomee.apache.org/chatterbox-2.1-doc/index.html <
> https://tomee.apache.org/chatterbox-2.1-doc/index.html>
>
> I totally made up those version numbers for illustrative purposes.  You
> get the idea.
>
> Related note, we actually have some documentation generated from the build
> and not regenerated.  This page for example was entirely generated from the
> default service-jar.xml:
>
>  - http://tomee.apache.org/containers-and-resources.html <
> http://tomee.apache.org/containers-and-resources.html>
>
> I remember doing that ages ago, like 2008-2011 range.  Aside from being
> likely out of date, it definitely highlights the awkward relationship
> between the docs and the source we currently have.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

Re: want to use load balancer while doing lookup , so that request can go to multiple instances for EJB

[Romain Manni-Bucau]

Hi

You can use failover:url1,url2 or failover:roundrobin:url1,url2 for
instance to pass multiple instance. If you want a custom strategy just do N
lookups and implement a proxy with the custom strategy - like circuit
breaker for instance.

Le 16 sept. 2017 04:35, "VikasRathee"  a écrit :

> Hi
>
> In my application , from  web module, I want to access EJBModule deployed
> on
> multiple instances.
> So I want to add something like load balancer while doing lookup. What i
> need to do.
>
> /  Properties properties = new Properties();
> properties.put(Context.INITIAL_CONTEXT_FACTORY,
>   "org.apache.openejb.client.RemoteInitialContextFactory");
> properties.put(Context.PROVIDER_URL,
> "http://127.0.0.1:8081/tomee/ejb;);
> InitialContext ic=new InitialContext(properties);/
>
> This code is working fine with one PROVIDER_URL, but if i'm giving other
> URL
> also with comma separated, i'm getting naming exception.
> Is there anything like i can implement a EJB broker kind of thing which can
> manage requests to multiple app servers.
>
>
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
> f982480.html
>

Re: tomee git commit: Fix licence issues

[Romain Manni-Bucau]

Hey Andy

Livereload is under MIT license as written in the notice file, not asf one,
we should probably strip the header from it to keep the original file. If
better we can dowload the file during the build to make it more obvious it
is not ours.



Le 14 sept. 2017 21:39,  a écrit :

Repository: tomee
Updated Branches:
  refs/heads/master 5d0b2726f -> 5df2bd805


Fix licence issues


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

Branch: refs/heads/master
Commit: 5df2bd805eb8c4096529e84fbf8aacf0e8b12972
Parents: 5d0b272
Author: andygumbrecht 
Authored: Thu Sep 14 21:39:28 2017 +0200
Committer: andygumbrecht 
Committed: Thu Sep 14 21:39:28 2017 +0200

--
 .../resource/activemq/jms2/TomEEXAConnection.java   | 16 
 .../assembler/classic/AppNamingReadOnlyTest.java| 16 
 .../openejb/core/ivm/EjbObjectInputStreamTest.java  | 16 
 .../server/cxf/rs/JSonStreamingOutputTest.java  | 16 
 .../src/main/resources/js/livereload.js | 16 
 5 files changed, 80 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/tomee/blob/5df2bd80/
container/openejb-core/src/main/java/org/apache/openejb/
resource/activemq/jms2/TomEEXAConnection.java
--
diff --git a/container/openejb-core/src/main/java/org/apache/openejb/
resource/activemq/jms2/TomEEXAConnection.java b/container/openejb-core/src/
main/java/org/apache/openejb/resource/activemq/jms2/TomEEXAConnection.java
index efe07cc..ff54579 100644
--- a/container/openejb-core/src/main/java/org/apache/openejb/
resource/activemq/jms2/TomEEXAConnection.java
+++ b/container/openejb-core/src/main/java/org/apache/openejb/
resource/activemq/jms2/TomEEXAConnection.java
@@ -1,3 +1,19 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
 package org.apache.openejb.resource.activemq.jms2;

 import org.apache.activemq.ActiveMQXAConnection;

http://git-wip-us.apache.org/repos/asf/tomee/blob/5df2bd80/
container/openejb-core/src/test/java/org/apache/openejb/assembler/classic/
AppNamingReadOnlyTest.java
--
diff --git a/container/openejb-core/src/test/java/org/apache/openejb/
assembler/classic/AppNamingReadOnlyTest.java b/container/openejb-core/src/
test/java/org/apache/openejb/assembler/classic/AppNamingReadOnlyTest.java
index 8ea3a02..e63a275 100644
--- a/container/openejb-core/src/test/java/org/apache/openejb/
assembler/classic/AppNamingReadOnlyTest.java
+++ b/container/openejb-core/src/test/java/org/apache/openejb/
assembler/classic/AppNamingReadOnlyTest.java
@@ -1,3 +1,19 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
 package org.apache.openejb.assembler.classic;

 import java.net.URI;

http://git-wip-us.apache.org/repos/asf/tomee/blob/5df2bd80/
container/openejb-core/src/test/java/org/apache/openejb/core/ivm/
EjbObjectInputStreamTest.java
--
diff --git 

Re: lookup failed in tomee

[Romain Manni-Bucau]

Hi Vikas

You dont use the remote context factory, is it intended? If so the provider
url is ignored

Le 8 sept. 2017 17:49, "VikasRathee"  a écrit :


I have one webservice project and one EJB 3.0 project deployed in Tomee
plume in same EAR. From webservice class i'm calling EJB bean class using
remote interface. i have used multiple InitialContextFactory object, but
nothing seems to work . Each time i'm getting

*javax.naming.NameNotFoundException: Name "TestRemote" not found*

while deployment, this log is coming in server.

*08-Sep-2017 16:23:09.587 INFO [main]
org.apache.openejb.assembler.classic.JndiBuilder.bind Jndi(name=TestRemote)
--> Ejb(deployment-id=Test)*

Here is the code from my webservice class

/Properties properties = new Properties();
properties.put("java.naming.factory.initial",
"org.apache.openejb.core.OpenEJBInitialContextFactory");
properties.put("java.naming.provider.url", "http://localhost:8081;);
InitialContext ic = new InitialContext(properties);
TestRemote PSBR = (TestRemote) ic.lookup("TestRemote");/

Apart from OpenEJBInitialContextFactory, i have tried
*org.apache.openejb.core.LocalInitialContextFactory and
RemoteInitialContextFactory* but getting the same error each time.



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

Re: 7.0.4 release plans

[Romain Manni-Bucau]

I think we don't depend on snapshots except surefire and we can downgrade
on 2.19 so compared to 7.0.3 we don't have any regression and can release
as soon as somebody has time (and connection ;)) to do it. We can want to
review the deps and upgrade a few before (like johnzon out of mind) but
nothing really blocking compared to 7.0.3 AFAIK.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-09-06 14:23 GMT+02:00 Frankie <kamin.feuer.2...@gmx.de>:

> Of cource I understand ... and I hope, you are well again.
> I know and honor the effort in open source development. And if there is no
> definite release date because of some blockers thats fine for me.
> My intention was not to pressure anyone but to get information about the
> dependencies or blockers for the release. I checked out the page with JIRA
> issues but I can't determine which of them have to be resolved for a new
> release.
> Thats why I asked that questions to get a better understanding of the
> release process of TomEE. Perhaps you or somebody else could help me by
> answering this questions.
>
> Thank you!
>
>
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
> f982480.html
>

Re: @Provider scan not working

[Romain Manni-Bucau]

Hi

if you put it in tomee/lib then it is not scanned by default for backward
compatibility reasons

you can try to set -Dopenejb.scan.webapp.container=true


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-09-05 9:44 GMT+02:00 Aruna Kalagnanam <kaar...@gmail.com>:

> Hi,
>
> I have a JAX-RS service running on TomEE with an empty Application
> subclass. The WAR doesnt have any Providers, but the TomEE runtime library
> has a custom jar that has filters and exception mappers annotated with
> @Provider.
>
> My expectation is that those @Provider classes will be scanned
> automatically and will be invoked on the request-response path. But, they
> are not recognized as provider classes.
>
> cxf.jaxrs.skip-provider-scanning is not set.
> cxf.jaxrs.providers is set to JohnzonProvider.
>
> Are those @Provider classes not being scanned because they are not part of
> the application WAR file ? If no, then why are the @Provider classes not
> being recognized.
> As a workaround, I have listed all of the provider classes in the value for
> cxf.jaxrs.providers, but I really want them to auto scanned.
>
> Please help me resolve this.
>
> Thanks,
> Aruna.
>

Re: TomEE documenation

[Romain Manni-Bucau]

Hi Mark

Doesnt the xa part cover it?


Le 1 sept. 2017 22:47, "Márk"  a écrit :

> Hi,
>
> I had a problem with tomee:
> https://stackoverflow.com/questions/45964924/tomee-ora-
> 01017-server-tries-to-authenticate-with-os-user/45965073
>
> http://tomee.apache.org/datasource-config.html is wrong. The userNameis
> not
> a valid declaration of the username. The valid declaration is user. (using
> TomEE 7.0.2)
>
> Mark
>

Re: geronimo-javamail_1.4_mail-1.9.0-alpha-2: sending email fails

[Romain Manni-Bucau]

If you use tomee.xml or resources.xml yes, if you don't use the built-in
factory then you need to handle it yourself


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-09-01 9:25 GMT+02:00 chongma <matthew.broadh...@nbmlaw.co.uk>:

> so looking at line 31:
> final String password = properties.getProperty("password");
>
> that might mean the password should be passed as:
> p.put("password", "smtppassword");
>
> and it is not necessary to pass an Authenticator with
> PasswordAuthentication?
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
> f982480.html
>

Re: geronimo-javamail_1.4_mail-1.9.0-alpha-2: sending email fails

[Romain Manni-Bucau]

For reference there can be some config changes after the 1.9 upgrade (
https://issues.apache.org/jira/browse/TOMEE-1697). Would be good to ensure
1. you authenticator is actually called (if the LOGIN fails it can be it
read the password from the session properties where it is not. FYI here is
how tomee instantiate sessions
https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/core/MailSessionFactory.java
(which is not the case if you use context.xml)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-09-01 9:00 GMT+02:00 chongma <matthew.broadh...@nbmlaw.co.uk>:

> is the server protected by TLS or SSL?  or is it open?
>
> if SSL protected have you tried:
> p.put("mail.smtp.auth", "true");
> p.put("mail.smtp.ssl.enable", "true");
>
> Also have you tried loading Mail Session as a Resource in context.xml (or
> tomee.xml) as per my previous example?  I didn't have much luck configuring
> it the way you are describing.
>
> Regards,
> Matthew
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-
> f982480.html
>

Re: geronimo-javamail_1.4_mail-1.9.0-alpha-2: sending email fails

[Romain Manni-Bucau]

Hi Dignesh,

Can you try to set mail.smtp.auth before creating the session? Also maybe
debug in your authenticator to check it is well used.

Le 1 sept. 2017 06:22, "Dignesh"  a écrit :

Loading javamail.default.providers from
jar:file:/C:/Users/dgoyal/Desktop/geronimo-javamail_1.4_
mail-1.7.jar!/META-INF/javamail.default.providers
DEBUG: loading new provider protocol=smtp,
className=org.apache.geronimo.javamail.transport.smtp.SMTPTransport,
vendor=Apache Software Foundation, version=1.0
DEBUG: loading new provider protocol=smtps,
className=org.apache.geronimo.javamail.transport.smtp.SMTPSTransport,
vendor=Apache Software Foundation, version=1.0
DEBUG: loading new provider protocol=nntp-post,
className=org.apache.geronimo.javamail.transport.nntp.NNTPTransport,
vendor=Apache Software Foundation, version=1.0
DEBUG: loading new provider protocol=nntp-posts,
className=org.apache.geronimo.javamail.transport.nntp.NNTPSSLTransport,
vendor=Apache Software Foundation, version=1.0
DEBUG: loading new provider protocol=nntp,
className=org.apache.geronimo.javamail.store.nntp.NNTPStore, vendor=Apache
Software Foundation, version=1.0
DEBUG: loading new provider protocol=nntps,
className=org.apache.geronimo.javamail.store.nntp.NNTPSSLStore,
vendor=Apache Software Foundation, version=1.0
DEBUG: loading new provider protocol=pop3,
className=org.apache.geronimo.javamail.store.pop3.POP3Store, vendor=Apache
Software Foundation, version=1.0
DEBUG: loading new provider protocol=pop3s,
className=org.apache.geronimo.javamail.store.pop3.POP3SSLStore,
vendor=Apache Software Foundation, version=1.0
DEBUG: loading new provider protocol=imap,
className=org.apache.geronimo.javamail.store.imap.IMAPStore, vendor=Apache
Software Foundation, version=1.0
DEBUG: loading new provider protocol=imaps,
className=org.apache.geronimo.javamail.store.imap.IMAPSSLStore,
vendor=Apache Software Foundation, version=1.0
DEBUG: getProvider() returning provider protocol=smtp;
type=javax.mail.Provider$Type@4769b07b;
class=org.apache.geronimo.javamail.transport.smtp.SMTPTransport;
vendor=Apache Software Foundation;version=1.0
smtp DEBUG: Attempting plain socket connection to server 10.96.132.189:25
220 10.96.132.189m Microsoft ESMTP MAIL Service, Version: 8.5.9600.16384
ready at  Fri, 1 Sep 2017 09:43:45 +0530
EHLO dignesh123
250-10.96.132.189m Hello [10.96.132.81]
250-AUTH=LOGIN
250-AUTH LOGIN
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250 OK
smtp DEBUG: Processing extension AUTH=LOGIN
smtp DEBUG: Processing extension AUTH LOGIN
smtp DEBUG: Processing extension TURN
smtp DEBUG: Processing extension SIZE
smtp DEBUG: Processing extension ETRN
smtp DEBUG: Processing extension PIPELINING
smtp DEBUG: Processing extension DSN
smtp DEBUG: Processing extension ENHANCEDSTATUSCODES
smtp DEBUG: Processing extension 8bitmime
smtp DEBUG: Processing extension BINARYMIME
smtp DEBUG: Processing extension CHUNKING
smtp DEBUG: Processing extension VRFY
smtp DEBUG: Processing extension OK
smtp DEBUG: Successful connection
MAIL FROM:  SIZE=461
530 5.7.3 Client was not authenticated
QUIT
221 2.0.0 10.96.132.189 Service closing transmission channel
Exception in thread "main"
org.apache.geronimo.javamail.transport.smtp.SMTPSendFailedException: 5.7.3
Client was not authenticated
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.
sendMessage(SMTPTransport.java:257)
at javax.mail.Transport.send(Transport.java:95)
at javax.mail.Transport.send(Transport.java:48)
at dignesh.test.TestEmail.main(TestEmail.java:72)




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

Re: JSTL

[Romain Manni-Bucau]

+1

side note: we should pby link this to the user thread, can try to find it
back later this week if needed


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-31 17:54 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Just to make sure I understand - (3) would be your preference, but if
> that's difficult you'd live with (1) if it came to it, with (2) being your
> least favorite.
>
> We should only need to pick one - I can confirm that option (1) on its own
> works, as does option (2) on its own. I'm definitely happy to have a crack
> at option (3) and present a PR for each and let the community decide which
> it likes the best.
>
> Thanks for your input, I appreciate it.
>
> Jon
>
> On Thu, Aug 31, 2017 at 4:42 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > yep, 3, 1, 2 for the complete order (a mix of compatibility and
> > influence/asf consistence).
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-08-31 16:53 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Uh, yeah, I think I misunderstood. I think we agree that the code I
> > > attached should work out of the box, requiring no changes to TomEE.
> That
> > > leaves us with a few options:
> > >
> > > 1. Use the taglibs-standard-jstlel jars as we are now, and add the
> > > dependency for Xalan -> trivial change, but adds 3MB to our binaries.
> > > 2. Switch to org.glassfish.web:javax.servlet.jsp.jstl which uses a
> > > CDDL/GPL
> > > + CP exception licence. Does not require Xalan -> easy change to make
> and
> > > appears to work (I believe the license is ok for us to use it). Not
> sure
> > if
> > > there are other restrictions or issues with us using that.
> > > 3. Patch the Tomcat taglibs libraries to use the XPath support built
> into
> > > the JVM as opposed to Xalan. I did have a look at this yesterday, and
> it
> > > didn't look like a straightforward change at the time. I'm happy to
> look
> > at
> > > it again though if we feel that's the way forward.
> > >
> > > I think you're stating a preference for (3) - is that correct?
> > >
> > > Cheers
> > >
> > > Jon
> > >
> > > On Thu, Aug 31, 2017 at 3:25 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hmm, shout if wrong but think you misunderstood the "optional" in my
> > > > sentence. I meant we patch trunk to remove the adherence to xalan.
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2017-08-31 15:41 GMT+02:00 Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com>
> > > > :
> > > >
> > > > > Thanks Romain. That is definitely the simplest path - xalan is
> > already
> > > > > marked as an optional dependency, so we wouldn't need to do
> anything.
> > > > From
> > > > > a compliance perspective, where would this leave us? Wouldn't we
> need
> > > > this
> > > > > to work out of the box without adding libraries to be compliant? If
> > it
> > > > > doesn't affect us in that respect, then I think we're probably good
> > to
> > > > go.
> > > > >
> > > > > Jon
> > > > >
> > > > > On Thu, A

Re: JSTL

[Romain Manni-Bucau]

Hi Jon

there is another thread on it (probably on user@)

I think we should just make xalan optional in the lib and upgrade.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-31 13:19 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Correction - that should be: "CDDL or GPL with classpath exception".
>
> On Thu, Aug 31, 2017 at 12:16 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Great question. CDDL _or_ GPL, by the look of it.
> > https://github.com/javaee/jstl-api/blob/master/LICENSE - same as JAXB I
> > believe.
> >
> > Jon
> >
> >
> >
> > On Thu, Aug 31, 2017 at 11:55 AM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> >> What is the licence for GlassFish one?
> >>
> >> Le 31 août 2017 12:38, "Jonathan Gallimore" <
> jonathan.gallim...@gmail.com
> >> >
> >> a écrit :
> >>
> >> > Hi
> >> >
> >> > On master we shifted from openejb-jstl to taglibs-standard-jstlel. I
> >> have
> >> > done the same on the 1.7.x branch, specifically to move on from the
> old
> >> > openejb-jstl (looking at
> >> > https://nvd.nist.gov/vuln/detail/CVE-2015-0254). The
> >> > taglibs-standard-jstlel
> >> > library does seem to depend on xalan, which we currently do not
> include
> >> in
> >> > TomEE.
> >> >
> >> > The impact is that some XML functions in JSP code does not work, for
> >> > example:
> >> >
> >> > <%@ taglib prefix="x" uri="http://java.sun.com/jstl/xml; %>
> >> >
> >> > 
> >> > 
> >> >>> > genre="Comedy" rating="7" year="2005" />
> >> >>> > genre="Action" rating="6" year="2004" />
> >> >>> > genre="Action" rating="6" year="2003" />
> >> >>> genre="Adventure"
> >> > rating="5" year="2002" />
> >> >>> > genre="Comedy" rating="8" year="2001" />
> >> >>> genre="Comedy"
> >> > rating="6" year="2001" />
> >> >>> genre="Comedy"
> >> > rating="7" year="2000" />
> >> > 
> >> > 
> >> >
> >> > Movie 1 Genre:  />
> >> >
> >> > fails with java.lang.NoClassDefFoundError: org/apache/xpath/XPath
> >> (this on
> >> > both 1.7.x and master)
> >> >
> >> > Including Xalan does fix this, but its a 3MB dependency.
> >> >
> >> > The alternative is to use org.glassfish.web:javax.servlet.jsp.jstl
> >> > instead,
> >> > which I have tested and seems to work. Anyone have any thoughts?
> >> >
> >> > Jon
> >> >
> >>
> >
> >
>

Re: geronimo-javamail_1.4_mail-1.9.0-alpha-2: sending email fails

[Romain Manni-Bucau]

just add in properties mail.debug=true

BTW, why not using tomee.xml to define this resource? We have some code
using this decriptor to handle the authentication a default resource
wouldn't have.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-29 13:38 GMT+02:00 Dignesh <dgo...@opentext.com>:

> Hi Romain,
> I am using IIS as my mail server.
> can you please let me know on what package you want debug trace to be
> enabled.
>
> Thank you,
> Dignesh,
>
>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/geronimo-javamail-1-4-mail-1-9-0-alpha-
> 2-sending-email-fails-tp4682494p4682497.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: geronimo-javamail_1.4_mail-1.9.0-alpha-2: sending email fails

[Romain Manni-Bucau]

Hi

what is your mail server?
can you activate the debug traces?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-29 12:02 GMT+02:00 Dignesh <dgo...@opentext.com>:

> TomEE 7.0.2 :-
>
>
> Sending email fails. javamail's Transport.send(...) function throws an
> exception. For me looks like some issue with
> "geronimo-javamail_1.4_mail-1.9.0-alpha-2.jar" jar.
>
> If I add different mail.jar in lib folder the same code works fine
>
> Attached the 2 jars and the sample code.
>
> Can anyone help me to figure out what is the issue
>
> Thank you,
> Dignesh
>
>
> /**
>  *
>  */
> package dignesh.test;
>
> import java.util.Date;
> import java.util.Properties;
>
> import javax.mail.Message;
> import javax.mail.Multipart;
> import javax.mail.PasswordAuthentication;
> import javax.mail.Session;
> import javax.mail.Transport;
> import javax.mail.internet.InternetAddress;
> import javax.mail.internet.MimeBodyPart;
> import javax.mail.internet.MimeMessage;
> import javax.mail.internet.MimeMultipart;
>
> /**
>  * @author dgoyal
>  *
>  */
> public class TestEmail
> {
>
>/**
> * @param args
> */
>public static void main(String[] args) throws Exception
>{
>
>   Properties p = System.getProperties();
>
>   // initialize mail properties
>   p.put("mail.smtp.host", "10.96.132.189"); // email server
>   p.put("mail.smtp.user", "smtpuser"); // sender's email address, used
> for
>// connecting to email server
>   p.put("mail.from", "dign...@test.com"); // sender's email address,
>  // displayed in the "from"
>  // field
>   p.put("mail.store.protocol", "pop3");
>   p.put("mail.transport.protocol", "smtp");
>   p.put("mail.smtp.port", 25);
>
>   Session session = null;
>
>   session = Session.getInstance(p, new javax.mail.Authenticator()
>   {
>  @Override
>  protected PasswordAuthentication getPasswordAuthentication()
>  {
> return new PasswordAuthentication("smtpuser",
> "smtppassword!");
>  }
>   });
>   session.getProperties().put("mail.smtp.auth", true);
>
>   MimeMessage msg = new MimeMessage(session);
>   msg.setFrom();
>   InternetAddress addressList[] = new InternetAddress[1];
>   addressList[0] = new InternetAddress("dign...@test.com");
>
>   msg.setRecipients(Message.RecipientType.TO, addressList);
>   msg.setSubject("Test", "UTF-8");
>
>   Multipart multiPart = new MimeMultipart();
>   MimeBodyPart bodyPart = new MimeBodyPart();
>   bodyPart.setText("Hello Test email", "UTF-8");
>   multiPart.addBodyPart(bodyPart);
>
>   msg.setContent(multiPart); // add the multipart to the message
>   msg.setSentDate(new Date()); // fill in "date sent"
>   Transport.send(msg); // off it goes...
>
>}
>
> }
> geronimo-javamail_1.jar
> <http://tomee-openejb.979440.n4.nabble.com/file/n4682494/
> geronimo-javamail_1.jar>
> javax.jar
> <http://tomee-openejb.979440.n4.nabble.com/file/n4682494/javax.jar>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/geronimo-javamail-1-4-mail-1-9-0-alpha-
> 2-sending-email-fails-tp4682494.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: TOMEE-2106: Tomee does not encode '%' in war filename

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-18 8:55 GMT+02:00 Kaloyan Spiridonov <k.i.spirido...@gmail.com>:

> Hello,
>
> What do you think about this bug: [TOMEE-2106]: Tomee does not encode '%'
> in war filename. ?
> The Tomcat supports deploying of war which contains special characters in
> its filename, why not TomEE to support it too ?
>
> Regards,
> Kaloyan
>

Re: [DISCUSS] Code donations: Sheldon and Chatterbox

[Romain Manni-Bucau]

Le 13 août 2017 21:25, "John D. Ament" <johndam...@apache.org> a écrit :

In all honesty, while the ASF as a whole doesn't have a true strategy, or
expect projects to work to benefit each other, I do think in this situation
it makes a lot of sense to think about the various communities at the ASF
and do some thinking around what makes the most sense for a user of Apache
products (independent of past, present, future employers).

There are some PMCs that exist to support the implementation of a Java EE
specification.  There are other PMCs that support Java EE but also come up
with very easy ways to make their product work independent of Java EE.  By
being independent of any specific application server, projects like
Johnzon, OpenWebBeans can go ahead and be leveraged in other products.
This gives those products broader reach by being fully independent.  By
putting Sheldon and Chatterbox directly into the TomEE PMC's hands, you are
closely tying the products together.

One other idea that I heard throw around was creating an EE commons type of
project.  It could handle these off to the side projects that are really
maintained by the ASF #usualSuspects and make it clear that they really
work across many different platforms, similar to the original premise
behind Apache DeltaSpike.  On the flip side, I'm not convinced that
Geronimo is that project either.


Hmm, if not then G should have moved to attic. It is here exactly for that
purpose.

Anyway back to the original topic: it sounds like faking tomee figures
...to fake them. Probably better to enter these projects by another way for
tomee and themselves like incubator, the EE umbrella project or other -
keeping them on github can also makes sense estimating their future
activity maybe, no?



John

On Sun, Aug 13, 2017 at 2:58 PM David Blevins <david.blev...@gmail.com>
wrote:

> We can keep any existing ssh code if we like.
>
> In terms of why TomEE, as mentioned here’s are some of the benefits:
>
>  - show the TomEE ecosystem is a bit bigger than just the server
>  - provide a clear pattern for “crazy new ideas” to start here that could
> potentially benefit TomEE or other EE related-projects
>  - more opportunities to earn commit
>  - give the community a boost
>
> We used to get a lot of committers in based on EJB improvements, however
> since that spec has slowed and is not moving forward, I think we need more
> opportunities for people to earn commit.
>
> In terms of G.  Obviously as co-founder of the project and someone who
> spent 9+ years on it full-time under 3 different employers, I have a
> different relationship to the name.  I think it’s great there’s new blood
> in G, including you, imagining a new future for it.  But my heart is
really
> in TomEE.  When I look at Geronimo I see my past, when I look at TomEE I
> see my future.
>
> Everyone is entitled to his or her own goals, hopes and dreams, I just
> want to be clear where my heart is at.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Aug 11, 2017, at 11:43 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
> >
> > Does it mean we drop the ssh module?
> >
> > Why ot going incubator to promote the portability of these projects?
> > (Whatever you do, if tomee subproject it is perceived as tomee bound).
> Are
> > they too small?
> >
> > Why not geronimo subprojects since it is the official umbrella project
> now
> > - vs tomee is not until we rediscuss it transprojects.
> >
> > Really sounds weird to me to try to push it in tomee when we agreed to
do
> > it in G weeks ago, what am I missing?
> >
> > Le 11 août 2017 22:58, "David Blevins" <david.blev...@gmail.com> a
> écrit :
> >
> >>> On Aug 11, 2017, at 3:20 AM, Mark Struberg <strub...@yahoo.de.INVALID>
> >> wrote:
> >>>
> >>> Reusable components make sense they are clearly distinctable. The part
> >> which contains that reusable components imo must get a different brand
> name
> >> than TomEE.
> >>
> >> Sheldon would stay named Sheldon.  Chatterbox would stay named
> >> Chatterbox.  They’d get their own JIRAs.  They’d just be hosted here on
> you
> >> could get to them via the tomee.apache.org website.
> >>
> >>> The problem here is: TomEE does a really bad job in pointing out these
> >> ties! If TomEE would kind of cumulate this progress and make it clear
> that
> >> this makes it into TomEE, then it would be much clearer that there is
no
> >> standstill but actually tons of activity.
> >>
> >> I think this is a great topic you should lead.
> >>
> >>
> >> -David
> >>
> >>
>
>

Re: [DISCUSS] Code donations: Sheldon and Chatterbox

[Romain Manni-Bucau]

Interesting reasoning. What about tackling new specs - like mvc - which
dont have yet a home at asf and would more inline with tomee and require
more activity than "done" projects?

Le 10 août 2017 22:44, "David Blevins"  a écrit :


> On Aug 10, 2017, at 1:12 AM, Jean-Louis Monteiro 
wrote:
>
> Does it mean we'll rename TomEE as a TLP to something else so TomEE can be
> a subproject and we will be creating more sub-projects for Sheldon or any
> other project?

I’d definitely want to keep TomEE as the TLP name.  My primary goal is to
grow TomEE the brand and community and TLP with things that might directly
or indirectly help TomEE the server.

At Apache it’s very common for TLPs to have subprojects and not be
renamed.  We can keep the TLP name as-is and foster crazy new ideas.  If
any of them becomes a massive effort in its own right, we spin it out.  APR
was originally an HTTPd subproject.  Ant was originally a Tomcat subproject.

Most subprojects don’t become that big.

We’ve actually had a couple subprojects, like the EJB 2.x to 3x Conversion
Eclipse Plugin Jonathan wrote.  Interestingly, it wasn’t actually working
on OpenEJB itself that got Jon commit, but this “crazy idea” subproject.
I’m not actually sure he had even one commit on OpenEJB trunk when we voted
him in.

Vishwa got voted in working on the build tools and twitter bot.  Smaller
projects seem to be a lot easier for people to digest.  In Jon’s case, the
subproject work encouraged him to dig into OpenEJB and the rest is history.

> I have seen a lot of discussions in different Apache projects regarding a
> common place for Java EE components (spec jars and common libraries). I
> know TomEE has been mentioned a couple of times, as well as other Apache
> projects.
> Is this a related discussion?
> Or should it be tackled at the same time?

I’d certainly welcome crazy new EE-related ideas and common libraries that
wanted to start here.  So in that sense, very related.

We’d want them to be in some way beneficial to the TomEE server ecosystem,
directly or indirectly.  They do not need to be TomEE-only components and
can definitely be reusable and have fun unique names.

In terms of at the same time, for me that’s a “no".  There’ve been
discussions in Geronimo specifically on what to do with that project.
Those discussions have been going on for 2 years.  We are not in a position
to tackle that here.  I certainly wouldn’t want us to hold our breath,
because I don’t think anything there will resolve soon and don’t want to
see is in the position of not moving forward because we are waiting on
another community.  I’d welcome the code and committers if they wanted to
come over.

We know we need to inject some blood into our community, so that’s the
primary goal.  If it happens to kill two birds with one stone, cool.  If
not, that’s also fine.

In terms of things we can do to make this community more vibrant, making it
easier for crazy new ideas to start here is a great step forward.  I think
we need a couple crazy new ideas to seed that, hence the idea to donate
Sheldon and Chatterbox.


-David

Re: [DISCUSS] Code donations: Sheldon and Chatterbox

[Romain Manni-Bucau]

Same thought, for asf it sounds like a G subproject and not sure tomee fits
but not strongly against neither.

Side note: we had a ssh module already which never got attraction - not a
need i guess - so not sure it would get better welcoming this time.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-10 10:12 GMT+02:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>:

> Does it mean we'll rename TomEE as a TLP to something else so TomEE can be
> a subproject and we will be creating more sub-projects for Sheldon or any
> other project?
>
> I have seen a lot of discussions in different Apache projects regarding a
> common place for Java EE components (spec jars and common libraries). I
> know TomEE has been mentioned a couple of times, as well as other Apache
> projects.
> Is this a related discussion?
> Or should it be tackled at the same time?
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Thu, Aug 10, 2017 at 5:00 AM, David Blevins <david.blev...@gmail.com>
> wrote:
>
> > > On Aug 9, 2017, at 7:27 PM, John D. Ament <johndam...@apache.org>
> wrote:
> > >
> > > 
> > > Don't forget to do IP clearance
> > > 
> >
> > Salute and Ack.  Went through that process with a half-dozen code bases
> in
> > the 2003-2009 range.  I was a pro then, not sure if my knowledge is
> dated.
> >
> > > I personally think these are awesome projects.  David's been passionate
> > > about this stuff for a long time, and I was really hopefully to get
> these
> > > MDB enhancements working on the JMS spec, never happened :-(
> >
> > I pushed hard to have them not axe JMS from Java 8.  Of course I’m
> > stubborn, so perhaps there is still another way.
> >
> > > It would be great to see these at Apache, and hopefully with a pretty
> > > robust test suite showing them working in multiple EE containers.
> >
> > Robust test suite would be awesome.  I know Sheldon currently supports
> > Wildfly and TomEE.  Jonathan Gallimore put quite a lot of work into it.
> > Testing wise, I think it was mostly manual.  So some increased tests
> would
> > be good.
> >
> > Feature wise, there are a handful of things I’d love to see added to
> > Sheldon:
> >
> >  - ability to use ssh keys instead of passwords
> >  - ability to execute ‘ssh localhost -p  ’ style
> > commands that ssh allows
> >  - ability to use @RolesAllowed on commands
> >
> > With those in there, you could do some extremely cool things.  Not that
> > Sheldon isn’t darn cool already :)
> >
> >
> > -David
> >
> >
>

Re: The road to TomEE 8

[Romain Manni-Bucau]

2017-08-09 13:15 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:

> The difference is in the marketing and how we can describe it.
>
> We can claim that TomEE 8.0.x is production ready, but we cannot claim
> that we implement EE 8 until we got all parts.
> And then when moving to 8.1 we can make rumble again.
>
> But true, apart from probably 1 lib there won't be much difference to the
> latest 8.0.x version - it's just the perception from a user perspective
> which makes a HUGE difference ;)
>
>
Maybe let's postpone this discussion until it becomes "possible" if you get
what I mean ;)


> LieGrue,
> strub
>
> > Am 09.08.2017 um 07:09 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> >
> > Well we can go with 8.0.x when finished since for users - and versioning
> -
> > it doesnt change much.
>
>

Re: The road to TomEE 8

[Romain Manni-Bucau]

Le 9 août 2017 01:17, "Mark Struberg" <strub...@yahoo.de.invalid> a écrit :

I'd not do a branch for 8.1

Just now do a tomee8 branch starting with 8.0.0-SNAPSHOT
And once we have some progress move it to master.

Then if we have all EE8 specs finished we propagate it to 8.1.0
Makes sense?


Well we can go with 8.0.x when finished since for users - and versioning -
it doesnt change much.

Anyway it can move to master directly if you branch 7.x before



LieGrue,
strub

> Am 08.08.2017 um 23:09 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> +1 and no need of 8.0/8.1 branch for now IMHO.
>
> Le 8 août 2017 22:21, "Jean-Louis Monteiro" <jlmonte...@tomitribe.com> a
> écrit :
>
>> Hi Mark,
>>
>> That sounds good.
>> +1
>>
>> Jean-Louis
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>> On Tue, Aug 8, 2017 at 9:20 PM, Mark Struberg <strub...@yahoo.de.invalid>
>> wrote:
>>
>>> Hi folks!
>>>
>>> I'd love to start the tomee8 branch.
>>> There are a lot of components which are ready to go.
>>>
>>> And I also had an idea about how we could very eagerly publish binaries
>> to
>>> play with.
>>>
>>> I imagine to have 2 goals:
>>>
>>> 1.) TomEE-8.0: this will be the 'development train'.
>>> It will contain JavaEE8 parts (mostly) and some JavaEE 7 parts still.
>>> We do not need to wait until we are fully EE8 compatible and certified,
>> we
>>> can just go on and publish this stuff as long as we CLEARLY state that
we
>>> are not yet fully EE8.
>>>
>>> 2.) TomEE-8.1: once we reach full EE8 compatibility we switch over to
>> 8.1.
>>>
>>> The main benefit of this approach is that we do not need to wait with
>>> doing a release until all the features are EE8 but we can eagerly push
>>> releases which are perfectly fine for people to use already.
>>>
>>>
>>> Wdyt?
>>>
>>> LieGrue,
>>> strub
>>

Re: The road to TomEE 8

[Romain Manni-Bucau]

+1 and no need of 8.0/8.1 branch for now IMHO.

Le 8 août 2017 22:21, "Jean-Louis Monteiro"  a
écrit :

> Hi Mark,
>
> That sounds good.
> +1
>
> Jean-Louis
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Tue, Aug 8, 2017 at 9:20 PM, Mark Struberg 
> wrote:
>
> > Hi folks!
> >
> > I'd love to start the tomee8 branch.
> > There are a lot of components which are ready to go.
> >
> > And I also had an idea about how we could very eagerly publish binaries
> to
> > play with.
> >
> > I imagine to have 2 goals:
> >
> > 1.) TomEE-8.0: this will be the 'development train'.
> > It will contain JavaEE8 parts (mostly) and some JavaEE 7 parts still.
> > We do not need to wait until we are fully EE8 compatible and certified,
> we
> > can just go on and publish this stuff as long as we CLEARLY state that we
> > are not yet fully EE8.
> >
> > 2.) TomEE-8.1: once we reach full EE8 compatibility we switch over to
> 8.1.
> >
> > The main benefit of this approach is that we do not need to wait with
> > doing a release until all the features are EE8 but we can eagerly push
> > releases which are perfectly fine for people to use already.
> >
> >
> > Wdyt?
> >
> > LieGrue,
> > strub
>

Re: Default resources for Java EE 7.

[Romain Manni-Bucau]

Hi Daniel

The side note here is: having them by default was intended cause it breaks
tomee deeply in term of resource matching and user existing config. Idea
was to set the flag if you want ee7 behavior to stay backward compat (and
this solution is fine for a EE container).




Le 6 août 2017 02:06, "Daniel Cunha"  a écrit :

> Hi folks,
>
> I started some works with concurrency API and got some troubles with
> default resources, let me know what do you think about my PRs:
>
> https://github.com/apache/tomee/pull/102
> https://github.com/apache/tomee/pull/103
>
>
> Best regard.
> --
> Daniel Cunha
> https://twitter.com/dvlc_
>

Re: Outdated/Junk PR

[Romain Manni-Bucau]

+1


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-08-02 14:54 GMT+02:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com>:

> Hi,
>
> I constantly get notifications about [1], which is now more than 1.5 years
> old. It looks like some mistake - i.e to merge the 1.7.x into master.,
> Github is regularly sending notifications to all watchers about it So what
> do you think about discarding & closing it ?
>
> [1] https://github.com/apache/tomee/pull/29
>
> Kind regards,
> Svetlin
>

Re: https://issues.apache.org/jira/browse/TOMEE-2100 - @Priority

[Romain Manni-Bucau]

Hi Jon

If we do it this way - jaxrs 2.1 - I d be to PR cxf instead of tomee. We
fork too much code to stay sane here.

What about just sorting by priority blindly? Cxf will handle the q and type
sorting anyway, no?

Le 26 juil. 2017 22:18, "Jonathan Gallimore" <jonathan.gallim...@gmail.com>
a écrit :

> Hi,
>
> I've had a go at this: https://github.com/apache/tomee/pull/96
>
> This creates a default comparator when no setting for
> cxf.jaxrs.provider-comparator is specified. This will order by priority
> first, but will still incorporate the default CXF sorting where priorities
> are the same for backwards compatibility.
>
> Michel's test case appears to work ok with this patch.
>
> Any feedback would be most welcome.
>
> Many thanks
>
> Jon
>
> On Tue, Jul 25, 2017 at 5:02 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > Yep - that's what I had in my mind. Makes sense if a comparator is
> > specified, we should use that instead of the @Priority ordering.
> >
> > Jon
> >
> > On Tue, Jul 25, 2017 at 4:59 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > > wrote:
> >
> >> +1
> >>
> >> What's do we want to do? Looks like a EE 8 feature we can eagerly
> support
> >> as a default comparator (if the comparator is set we must bypass it to
> >> respect the comparator IMHO)
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >> 2017-07-25 17:03 GMT+02:00 Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com>
> >> :
> >>
> >> > I'm happy to take a look at this one, unless someone else is already
> >> > working on it?
> >> >
> >> > Jon
> >> >
> >>
> >
> >
>

Re: Probleme with johnzon

[Romain Manni-Bucau]

2017-07-26 11:19 GMT+02:00 olivier_1 :

> Hi
> Thank you  for your reactivity
>
> i have already make it .
>

Not really. This specifies the endpoint types but jackson is still */*:

@Provider
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class MyjsonProvider extends JacksonJsonProvider {}


>
> @PUT
> @Consumes(MediaType.APPLICATION_JSON)
> @Produces(MediaType.APPLICATION_JSON)
> public Response putPerson(Person person) throws URISyntaxException{
> logger.info(person.toString());
> URI location = new
> URI(propertyConfiguration.getProperties().get("rootUrl")
> .toString()+iPersonService.save(person));
> logger.info(location.toString());
> return Response.created(location).build();
>
>
> }
>
> NB: in jboss and tomee 1.7.4 it work, but in tomee 7 it's not working
> Regards,
> Olivier.
>
>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/Probleme-with-johnzon-tp4682312p4682321.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: Probleme with johnzon

[Romain Manni-Bucau]

Hi

this is an old jackson bug now, story short jackson is defined as a
fallback provider (*/*) whereas johnzon is a json one. Just wrap jackson
override produces/consumes type to application/json in your app.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-25 17:02 GMT+02:00 olivier_1 <choukri.meda...@gmail.com>:

> I encounter a problem around Apache Johnzon
> in my application i use jackson-jaxrs-json-provider.
> server : tomee 7.
>
> when i try to convert the object to json i have exception :
>
> 25-Jul-2017 17:15:38.115 WARNING [http-nio-8080-exec-1]
> org.apache.cxf.phase.PhaseInterceptorChain.doDefaultLogging Interceptor
> for
> {http://webservices.pers.refer.icb.bnpparibas.com/}PersonWebService has
> thrown exception, unwinding now
>  org.apache.johnzon.mapper.MapperException: Using fallback converter, this
> only works in write mode but not in read. Please register a custom
> converter
> to do so.
> at
> org.apache.johnzon.mapper.MappingParserImpl$FallbackConverter.fromString(
> MappingParserImpl.java:715)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(
> ConverterAdapter.java:37)
> at
> org.apache.johnzon.mapper.internal.ConverterAdapter.to(
> ConverterAdapter.java:24)
> at
> org.apache.johnzon.mapper.MappingParserImpl.convertTo(
> MappingParserImpl.java:682)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toObject(
> MappingParserImpl.java:523)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(
> MappingParserImpl.java:634)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildObject(
> MappingParserImpl.java:318)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toObject(
> MappingParserImpl.java:468)
> at
> org.apache.johnzon.mapper.MappingParserImpl.mapCollection(
> MappingParserImpl.java:587)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildArray(
> MappingParserImpl.java:544)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toObject(
> MappingParserImpl.java:477)
> at
> org.apache.johnzon.mapper.MappingParserImpl.toValue(
> MappingParserImpl.java:634)
> at
> org.apache.johnzon.mapper.MappingParserImpl.buildObject(
> MappingParserImpl.java:318)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(
> MappingParserImpl.java:133)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(
> MappingParserImpl.java:125)
> at
> org.apache.johnzon.mapper.MappingParserImpl.readObject(
> MappingParserImpl.java:112)
> at org.apache.johnzon.mapper.Mapper.mapObject(Mapper.java:237)
> at org.apache.johnzon.mapper.Mapper.readObject(Mapper.java:192)
> at
> org.apache.johnzon.jaxrs.JohnzonMessageBodyReader.readFrom(
> JohnzonMessageBodyReader.java:76)
> at
> org.apache.johnzon.jaxrs.DelegateProvider.readFrom(
> DelegateProvider.java:51)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(
> JAXRSUtils.java:1366)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBody(
> JAXRSUtils.java:1317)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(
> JAXRSUtils.java:824)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(
> JAXRSUtils.java:788)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(
> JAXRSInInterceptor.java:212)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(
> JAXRSInInterceptor.java:77)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(
> ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
> AbstractHTTPDestination.java:252)
> at
> org.apache.openejb.server.cxf.rs.CxfRsHttpListener.doInvoke(
> CxfRsHttpListener.java:251)
> at
> org.apache.tomee.webservices.CXFJAXRSFilter.doFilter(
> CXFJAXRSFilter.java:94)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:166)
> at
>

Re: https://issues.apache.org/jira/browse/TOMEE-2100 - @Priority

[Romain Manni-Bucau]

+1

What's do we want to do? Looks like a EE 8 feature we can eagerly support
as a default comparator (if the comparator is set we must bypass it to
respect the comparator IMHO)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-25 17:03 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> I'm happy to take a look at this one, unless someone else is already
> working on it?
>
> Jon
>

Re: [jira] [Commented] (TOMEE-2102) IvmContext bind/unbind creates duplicate contexts

[Romain Manni-Bucau]

looks like the class is not packaged in an arquillian war so it is not
instantiable. is that an option?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-20 13:42 GMT+02:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com>:

> Hi,
>
> The IvmContext arquillian test passes against current master: [1]
> The CXF tests fail because of no such method errors:
> java.lang.NoSuchMethodException:
> org.apache.openejb.server.cxf.rs.AppPropertiesPropagationTest$
> Writer.()
> Maybe CXF was updated ?
>
> [1] https://gist.github.com/SvetlinZarev/90d7deb0326e7b670440f0a9a442af1d
>
> Kind regards,
> Svetlin
>
> 2017-07-20 14:02 GMT+03:00 Jonathan Gallimore <
> jonathan.gallim...@gmail.com>
> :
>
> > Happy to try it again, but here's the tests that were failing for me on
> > master:
> >
> > org.apache.openejb.arquillian.tests.naming.IvmContextTest.
> > testListContextTree
> > org.apache.openejb.arquillian.tests.naming.IvmContextTest.
> > testContextListBindings
> > org.apache.openejb.server.cxf.rs.CustomProviderTest.customProvider
> > org.apache.openejb.server.cxf.rs.CustomProviderTest.
> customSpecificProvider
> > org.apache.openejb.server.cxf.rs.CustomProviderWithConfigTest.config
> > org.apache.openejb.server.cxf.rs.DiscoverCustomProviderTest.
> customProvider
> >
> > I haven't as yet dug into the root cause of the test failures. Will
> likely
> > be this evening before I can do that.
> >
> > Jon
> >
> > On Thu, Jul 20, 2017 at 9:28 AM, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> > > Thanks Svetlin - I'll review later today. I'm currently getting some
> > > IvmContextTest test failures on master - I'll send over a list. Happy
> to
> > > help fix these.
> > >
> > > Jon
> > >
> > > On Thu, Jul 20, 2017 at 9:19 AM, ASF GitHub Bot (JIRA) <
> j...@apache.org>
> > > wrote:
> > >
> > >>
> > >> [ https://issues.apache.org/jira/browse/TOMEE-2102?page=com.
> > >> atlassian.jira.plugin.system.issuetabpanels:comment-tabpane
> > >> l=16094340#comment-16094340 ]
> > >>
> > >> ASF GitHub Bot commented on TOMEE-2102:
> > >> ---
> > >>
> > >> GitHub user SvetlinZarev opened a pull request:
> > >>
> > >> https://github.com/apache/tomee/pull/94
> > >>
> > >> TOMEE-2102: IvmContext bind/unbind creates duplicate contexts
> > >>
> > >>
> > >>
> > >> You can merge this pull request into a Git repository by running:
> > >>
> > >> $ git pull https://github.com/SvetlinZarev/tomee fixBindUndbind
> > >>
> > >> Alternatively you can review and apply these changes as the patch at:
> > >>
> > >> https://github.com/apache/tomee/pull/94.patch
> > >>
> > >> To close this pull request, make a commit to your master/trunk branch
> > >> with (at least) the following in the commit message:
> > >>
> > >> This closes #94
> > >>
> > >> 
> > >> commit 12bf481e9bdbaec232c655abb63e1fd496d98fdd
> > >> Author: Svetlin Zarev <svetlin.za...@sap.com>
> > >> Date:   2017-07-20T06:44:11Z
> > >>
> > >> Add tests that verify the behaviour of IvmContext bind/unbind
> > >>
> > >> 
> > >>
> > >>
> > >> > IvmContext bind/unbind creates duplicate contexts
> > >> > -
> > >> >
> > >> > Key: TOMEE-2102
> > >> > URL: https://issues.apache.org/
> jira/browse/TOMEE-2102
> > >> > Project: TomEE
> > >> >  Issue Type: Bug
> > >> >Reporter: Svetlin Zarev
> > >> >
> > >> > Imagine you have the flowing context "a/b/object". The context tree
> > can
> > >> be created in two ways:
> > >> > 1. Relative to the root or some
> > >> > {code}
> > >> > IvmContext root = IvmContext.createRootContext

Re: Work assignment protocol?

[Romain Manni-Bucau]

Hi Jon,

was writing the same kind of thing - for the same reason pby. Saw you were
assigned only in the "fixed" popup :s.

Since list is first for now (vs jira), what about fwding the jira saying
"i'm on it"?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-19 14:33 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Just a quick one - should we have some sort of work assignment protocol?
> For example, I saw a JIRA ticket come in, I assigned it to myself, asked
> for a bit more information. Whilst then reviewing something else, I then
> see that ticket is resolved, fixed etc.
>
> Whilst I'm not ungrateful for the fix, given that I had less than 40
> minutes to look at the ticket and test a fix, I do feel a little robbed of
> the opportunity to look at it myself.
>
> If I had assigned to myself and done nothing for 2 days, this doesn't seem
> unreasonable. Alternatively, a "Hey Jon, I know the answer to this off the
> top of my head, I'll take it" also doesn't seem unreasonable either.
>
> In order to build our skills and all grow, we all need a fair shot at
> fixing things - I appreciate that might feel like things go more slowly as
> we are at different levels, and some of us are not as fast as others. But
> its hard to boost your skills if you don't get to work on the bugs when
> they come in.
>
> I'd like to proposed that if a JIRA is assigned, and "Work Started", then
> its owned by whoever its assigned to. If there's then no activity for a
> couple of days then sending a note saying "Are you stuck?" / "Can I help?"
> / "Can I take this ticket?" is fair game.
>
> Thoughts?
>
> Jon
>

Re: [PR] TOMEE-2087 IvmContext.list() does not correctly list the context content

[Romain Manni-Bucau]

looks good to apply to me


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-14 12:55 GMT+02:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com>:

> Hi,
>
> Do you have any comments ? Do you thing that something is missing or maybe
> that something additional is needed ?
>
> Kind regards,
> Svetlin
>
> 2017-07-11 15:07 GMT+03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > 2017-07-11 12:38 GMT+02:00 Svetlin Zarev <svetlin.angelov.zarev@gmail.
> com
> > >:
> >
> > > I've added several JUnit test cases in openejb-core that should verify
> > > IvmContext.list() behaviour, yet I'll feel safer if we keep the
> > arquillian
> > > test as well.
> > >
> >
> > +1, both are needed
> >
> >
> > >
> > > 2017-07-11 10:10 GMT+03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > >
> > > > side note: embedded (not tomcat based) testing is needed to ensure we
> > > don't
> > > > break but doesn't fully test the ivmcontext code because the
> federation
> > > is
> > > > different so guess starting with tomcat is not that bad.
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2017-07-11 8:28 GMT+02:00 Svetlin Zarev <svetlin.angelov.zarev@gmail.
> > com
> > > >:
> > > >
> > > > > Hi David,
> > > > >
> > > > > Thank you for sparing some time to look into my PR !
> > > > >
> > > > > > I’m not sure I can see how the test actually works
> > > > >
> > > > > The issue is that IvmContext.list() returns objects that are not
> > really
> > > > > bound into the listed context. For instance if you run the MCVE
> > > attached
> > > > to
> > > > > the jira ticket you'll see that it returns [1]. There you can see
> > that
> > > > > TestEJB is bound in "java:" (and even appears several times!) or
> that
> > > > > "java:global" is bound in "java:module". But if you try to look up
> > > those
> > > > > entries, the lookup fails with a NameNotFoundException, because all
> > > these
> > > > > references are not really bound there. So the test recursively
> lists
> > > all
> > > > > contexts in the JNDI tree and tries to lookup up every name-class
> > pair
> > > > that
> > > > > is returned. If the lookup fails, it means that list() has returned
> > > > > something that is not really there. You can compare [1] and [2]
> > 9after
> > > > the
> > > > > fix) to see the difference in list()'s behaviour
> > > > >
> > > > > > Is there a test for listBindings?  It’s mentioned as also broken,
> > > but I
> > > > > didn’t see a test for it.
> > > > >
> > > > > IvmContext.listBindings() and IvmContext.list() use the very same
> > > > > IvmContext.MyNamingEnumeration abstract class and share the very
> same
> > > > logic
> > > > > to traverse the naming tree. I didn't write test for it because
> they
> > > > share
> > > > > the same code, but I can easily modify it to run aginst both
> methods.
> > > > >
> > > > > > What is the PrintWriter used for?  It seems it could be useful to
> > > > assert
> > > > > it prints what we expect.  Not sure if that is there and I am
> missing
> > > it.
> > > > >
> > > > > I thought it would be helpful to be able to see what went wrong if
> > the
> > > > test
> > > > > fails. The IvmContextTest class collects the output from the
> > servlet's
> 

Re: @PostConstruct and @PreDestrory

[Romain Manni-Bucau]

Hi Jon

Side note before digging: you can rewrite the test this way (i find it
easier to enter in but surely personal):
https://gist.github.com/rmannibucau/86152958d9c139a45d4d80adbcc2c653

Now about the issue: if i get it right issue is we lookup the instance and
therefore unwrap the holder with predestroy info. So fix is just about
reading the raw wrapper (we don't have references of references of
references with resource so it is safe) and just destroy the holder.

Personally I'm very tempted to go away from the JNDI tree for the storage
of these metadata and just put them in the AppContext (resources list?) to
avoid to mess up wrappings/unwrapping like we do today and have a straight
implmentation. Then the JNDI interaction is a plain unbind but the app
resource lifecycle management is not relying on jndi by itself (like EJBs).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-13 12:58 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Ooo, interesting. Thanks Svetlin! I'll add a test case for that as well and
> adjust.
>
> Cheers!
>
> Jon
>
> On Thu, Jul 13, 2017 at 11:54 AM, Svetlin Zarev <
> svetlin.angelov.za...@gmail.com> wrote:
>
> > Hi,
> >
> > I'm not sure what will happen if the IvmContext is in read-only mode
> (i.e.
> > openejb.forceReadOnlyAppNamingContext=true). You may-need to make the
> > context writable before unbinding.
> >
> > Svetlin
> >
> >
> > 2017-07-13 13:46 GMT+03:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Hey folks
> > >
> > > I noticed an issue when creating a resource inside an application:
> > >
> > > package org.superbiz;
> > >
> > >
> > > import javax.annotation.PostConstruct;
> > > import javax.annotation.PreDestroy;
> > > import java.util.logging.Logger;
> > >
> > > public class Startup {
> > >
> > > private final Logger log = Logger.getLogger(Startup.
> > class.getName());
> > >
> > > @PostConstruct
> > > public void start() {
> > > log.info("*** " + getClass().getName() + " started ***");
> > > }
> > >
> > > @PreDestroy
> > > public void stop() {
> > > log.info("*** " + getClass().getName() + " stopped ***");
> > > }
> > >
> > > }
> > >
> > > and using WEB-INF/resources.xml to create the resource:
> > >
> > > 
> > > 
> > > # any properties you need can go here
> > > 
> > > 
> > >
> > > It looks like my @PostConstruct is called ok, but my @PreDestroy is
> not.
> > I
> > > believe this works ok with resources defined in tomee.xml, but I'm
> happy
> > to
> > > check.
> > >
> > > I dug a bit deeper, and wrote a test. This appears to be an issue on
> both
> > > master and 1.7.x. I have created two PRs, and would appreciate any
> > > thoughts.
> > >
> > > https://github.com/apache/tomee/pull/91
> > > https://github.com/apache/tomee/pull/92
> > >
> > > Many thanks
> > >
> > > Jon
> > >
> >
>

Re: old openejb site is still top ranked in google!

[Romain Manni-Bucau]

Hi Mark,

it is already the same site but we can test if the host has openejb and if
so do the redirection probably
download section is also up to date, you probably just used a wrong link ->
http://openejb.apache.org/download-ng.html.
http://tomee.apache.org/downloads.html was kept as part of the "don't
remove the old site" but is outdated.

We have a pending task to add a banner on all old pages to show it is no
more maintained.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-13 11:05 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:

> Hi!
>
> I just wanted to show my colleague how to install TomEE locally.
> When searching for "tomee" the old openejb site still pops up on top
> http://openejb.apache.org/apache-tomee.html
>
> And this download section only has a 7.0.2 version and misses 7.0.3...
>
> We should shut down openejb.apache.org and replace it with a redirect to
> https://tomee.apache.org.
> Wdyt?
>
> LieGrue,
> strub
>
>

Re: Adds an option to ignore mdb.activation fields

[Romain Manni-Bucau]

SystemInstance.get().getComponent(ContainerSystem.class).getContainer(id)

Since AutoConfig should pass before it should be set and if not we should
just move the override dynamicdeployer at the right place to have it set
and still be read by its consumers. In any case, not splitting the override
logic is key for maintenance and ensure it is done in the right order
(which is something to ensure we test - override priorities)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-12 15:04 GMT+02:00 Otávio Gonçalves de Santana <
osant...@tomitribe.com>:

> String containerId = ejbDeployment.getContainerId();
>
> It returns a container id,
> How can I return the container from that?
>
> On Wed, Jul 12, 2017 at 9:40 AM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > org.apache.openejb.jee.oejb3.EjbDeployment#getContainerId should give
> you
> > the container
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-12 14:29 GMT+02:00 Otávio Gonçalves de Santana <
> > osant...@tomitribe.com>:
> >
> > > 1) Getter removed, thanks
> > > 2) I took a look at that. As far as I can see, we don't have the
> > container
> > > (or its ID) available at the time when ActivationConfigPropertyOverri
> de.
> > > Please let us know if we've missed something there.
> > >
> > > On Wed, Jul 12, 2017 at 9:17 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi Otavio,
> > > >
> > > > I have 2 notes on this:
> > > >
> > > > 1. the getProperties() is useless I think (IDE generated?)
> > > > 2. it would probably better fit ActivationConfigPropertyOverride to
> > > have a
> > > > right ordering of overrides, no?
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2017-07-12 13:42 GMT+02:00 Otávio Gonçalves de Santana <
> > > > osant...@tomitribe.com>:
> > > >
> > > > > I have created this resource to both master and backported.
> > > > >
> > > > >
> > > > >- https://github.com/apache/tomee/pull/90
> > > > >- https://github.com/apache/tomee/pull/89
> > > > >
> > > > >
> > > > > On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> > > > > jonathan.gallim...@gmail.com> wrote:
> > > > >
> > > > > > We have a +1 and a +0 for the backport. I'm pulling the latest
> code
> > > and
> > > > > > running the tests. If it looks ok, I'll merge it, while Otavio
> > works
> > > on
> > > > > the
> > > > > > container-based config in another patch. Please shout if you have
> > any
> > > > > > objections.
> > > > > >
> > > > > > Otavio, let us know if you need any help or guidance on the
> > container
> > > > > based
> > > > > > settings!
> > > > > >
> > > > > > Jon
> > > > > >
> > > > > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > > > > osant...@tomitribe.com> wrote:
> > > > > >
> > > > > > > The problem
> > > > > > >
> > > > > > > The configuration for MDB activation properties allow any
> > key/value
&

Re: Adds an option to ignore mdb.activation fields

[Romain Manni-Bucau]

org.apache.openejb.jee.oejb3.EjbDeployment#getContainerId should give you
the container


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-12 14:29 GMT+02:00 Otávio Gonçalves de Santana <
osant...@tomitribe.com>:

> 1) Getter removed, thanks
> 2) I took a look at that. As far as I can see, we don't have the container
> (or its ID) available at the time when ActivationConfigPropertyOverride.
> Please let us know if we've missed something there.
>
> On Wed, Jul 12, 2017 at 9:17 AM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > Hi Otavio,
> >
> > I have 2 notes on this:
> >
> > 1. the getProperties() is useless I think (IDE generated?)
> > 2. it would probably better fit ActivationConfigPropertyOverride to
> have a
> > right ordering of overrides, no?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-12 13:42 GMT+02:00 Otávio Gonçalves de Santana <
> > osant...@tomitribe.com>:
> >
> > > I have created this resource to both master and backported.
> > >
> > >
> > >- https://github.com/apache/tomee/pull/90
> > >- https://github.com/apache/tomee/pull/89
> > >
> > >
> > > On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > > > We have a +1 and a +0 for the backport. I'm pulling the latest code
> and
> > > > running the tests. If it looks ok, I'll merge it, while Otavio works
> on
> > > the
> > > > container-based config in another patch. Please shout if you have any
> > > > objections.
> > > >
> > > > Otavio, let us know if you need any help or guidance on the container
> > > based
> > > > settings!
> > > >
> > > > Jon
> > > >
> > > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > > osant...@tomitribe.com> wrote:
> > > >
> > > > > The problem
> > > > >
> > > > > The configuration for MDB activation properties allow any key/value
> > to
> > > be
> > > > > specified. At present on the 1.7.x branch, the server will fail to
> > > deploy
> > > > > the application if the activation property is not present on the
> > > > activation
> > > > > spec class.
> > > > >
> > > > > This becomes painful in a scenario where more than one JMS resource
> > > > > adapter/MDB container is used, and you wish to configure the
> > activation
> > > > > properties of multiple MDBs in one go using the `mdb.activation.`
> > > system
> > > > > property.. Right now,if an activation property is used that one
> > > provider
> > > > > uses but other one does, the server will throw an exception.
> > > > >
> > > > > For example, given these parameters,
> > > > >
> > > > >-
> > > > >
> > > > >   mdb.activation.ignore=foo
> > > > >-
> > > > >
> > > > >   mdb.activation.ignore2=bar
> > > > >
> > > > >
> > > > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation
> spec
> > > > > class, the following exception will be thrown.
> > > > >
> > > > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > > > Unable
> > > > > to create activation spec: No setter found for the activation spec
> > > > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > > > setter
> > > > > found for the activation sp

Re: Adds an option to ignore mdb.activation fields

[Romain Manni-Bucau]

Hi Otavio,

I have 2 notes on this:

1. the getProperties() is useless I think (IDE generated?)
2. it would probably better fit ActivationConfigPropertyOverride to have a
right ordering of overrides, no?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-12 13:42 GMT+02:00 Otávio Gonçalves de Santana <
osant...@tomitribe.com>:

> I have created this resource to both master and backported.
>
>
>- https://github.com/apache/tomee/pull/90
>- https://github.com/apache/tomee/pull/89
>
>
> On Mon, Jul 10, 2017 at 7:33 AM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > We have a +1 and a +0 for the backport. I'm pulling the latest code and
> > running the tests. If it looks ok, I'll merge it, while Otavio works on
> the
> > container-based config in another patch. Please shout if you have any
> > objections.
> >
> > Otavio, let us know if you need any help or guidance on the container
> based
> > settings!
> >
> > Jon
> >
> > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > osant...@tomitribe.com> wrote:
> >
> > > The problem
> > >
> > > The configuration for MDB activation properties allow any key/value to
> be
> > > specified. At present on the 1.7.x branch, the server will fail to
> deploy
> > > the application if the activation property is not present on the
> > activation
> > > spec class.
> > >
> > > This becomes painful in a scenario where more than one JMS resource
> > > adapter/MDB container is used, and you wish to configure the activation
> > > properties of multiple MDBs in one go using the `mdb.activation.`
> system
> > > property.. Right now,if an activation property is used that one
> provider
> > > uses but other one does, the server will throw an exception.
> > >
> > > For example, given these parameters,
> > >
> > >-
> > >
> > >   mdb.activation.ignore=foo
> > >-
> > >
> > >   mdb.activation.ignore2=bar
> > >
> > >
> > > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > > class, the following exception will be thrown.
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> > Unable
> > > to create activation spec: No setter found for the activation spec
> > > properties: [ignore, ignore2]: Unable to create activation spec: No
> > setter
> > > found for the activation spec properties: [ignore, ignore2]
> > >
> > >at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1430)
> > >
> > >at
> > > org.apache.openejb.assembler.classic.Assembler.
> > > createApplication(Assembler.java:796)
> > >
> > >... 19 more
> > >
> > > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > > activation
> > > spec: No setter found for the activation spec properties: [ignore,
> > ignore2]
> > >
> > >at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:292)
> > >
> > >at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > > MdbContainer.java:159)
> > >
> > >at
> > > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > > Assembler.java:1417)
> > >
> > >... 20 more
> > >
> > > Caused by: java.lang.IllegalArgumentException: No setter found for the
> > > activation spec properties: [ignore, ignore2]
> > >
> > >at
> > > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > > MdbContainer.java:262)
> > >
> > >... 22 more
> > >
> > >
> > > The solution
> > >
> > > The best solution to solve the communication among server is to put a
> new
> > > configuration property in TomEE. When this setting is enabled,
> overriding
> > > the FailOnUnknownActivationSpec attribute at
> > > org.apache.openejb.core.mdb.MdbContainer class., that will be disabled
> > by
> > > default to don't break the compatibility, when the setter does not
> exist
> > it
> > > put a log and then keep working.
> > >
> > > Basically, my proposal does a backport to 1.7 branch:
> > > https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> > > eded08aec0
> > >
> > > Path:
> > >
> > > https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
> > >
> >
>

Re: Site and "documentation" usage

[Romain Manni-Bucau]

just push it, regressions were fixed (thanks again Ivan) so risks are now
low enough IMHO


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-11 15:19 GMT+02:00 Andy Gumbrecht <agumbre...@tomitribe.com>:

> But if everyone is happy then I'd be happy for it to be pushed. Tested on
> my local box last night and it looks great.
>
> On 11 July 2017 at 15:18, Andy Gumbrecht <agumbre...@tomitribe.com> wrote:
>
> > I was going to put it up for a vote tonight.
> >
> > On 11 July 2017 at 14:40, Jonathan Gallimore <
> jonathan.gallim...@gmail.com
> > > wrote:
> >
> >> I'm happy to merge it if there are no objections.
> >>
> >> Jon
> >>
> >> On Tue, Jul 11, 2017 at 1:36 PM, Ivan Junckes Filho <
> >> ivanjunc...@gmail.com>
> >> wrote:
> >>
> >> > Do we have any objections to this change? If no, can somebody merge
> it?
> >> >
> >> > On Sat, Jul 8, 2017 at 5:19 PM, Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> > wrote:
> >> >
> >> > > +1
> >> > >
> >> > > Le 8 juil. 2017 19:53, "Ivan Junckes Filho" <ivanjunc...@gmail.com>
> a
> >> > > écrit :
> >> > >
> >> > > > Hello TomEE devs, I fixed the 404 issue.
> >> > > >
> >> > > > https://ivanjunckes.github.io/admin
> >> > > > https://ivanjunckes.github.io/developers
> >> > > > https://ivanjunckes.github.io/advanced
> >> > > >
> >> > > > How can we proceed from here? Can we get this change merged?
> >> > > >
> >> > > > On Thu, Jul 6, 2017 at 12:39 PM, Romain Manni-Bucau <
> >> > > rmannibu...@gmail.com
> >> > > > >
> >> > > > wrote:
> >> > > >
> >> > > > > Not a big fan of "list sites" cause basically you dont find
> >> anything
> >> > > (or
> >> > > > it
> >> > > > > is faster to find it in code). Arquillian one is way better IMO.
> >> > > > >
> >> > > > > Le 6 juil. 2017 17:15, "Andy Gumbrecht" <
> agumbre...@tomitribe.com>
> >> a
> >> > > > > écrit :
> >> > > > >
> >> > > > > > Just out of interest, what is everyone's favourite OSS
> website?
> >> I
> >> > > > really
> >> > > > > > like http://projects.spring.io/spring-boot/ and
> >> > https://fabric8.io/
> >> > > > > >
> >> > > > > > On 6 July 2017 at 15:58, Andy Gumbrecht <
> >> agumbre...@tomitribe.com>
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > > +1 to go to the user list and maybe get some feedback before
> >> > > pushing,
> >> > > > > but
> >> > > > > > > also..
> >> > > > > > >
> >> > > > > > > +1 to push it as is - Looks really good Ivan, so thank you
> >> very
> >> > > much
> >> > > > > for
> >> > > > > > > the hard work, and working together on the hosting for
> review
> >> > > issues.
> >> > > > > > Thank
> >> > > > > > > you Romain for getting the code set up on GitHub. That makes
> >> > > reviews
> >> > > > > much
> >> > > > > > > more transparent!
> >> > > > > > >
> >> > > > > > > +1 for continuing to improve the 404 issues over time.
> >> > > > > > >
> >> > > > > > > Andy.
> >> > > > > > >
> >> > > > > > > On 6 July 2017 at 14:46, Daniel Cunha <
> daniels...@apache.org>
> >> > > wrote:
> >> > > > > > >
> >> > > > > > >> +1 to post it user@ list.
> >> > > > > > >> The users are the real consumers of the website and their
> >> 

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

If some people want to create some console tuto I would recommand
https://asciinema.org/ rather than plain video, rendering is customizable
(colors, font etc) and it is lighter than videos. It is really great for
setup/config/build... samples. (tip: ensure your shell has colors, makes it
more readable).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-11 14:16 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Great idea. I was thinking the same thing. I quite fancy the idea of
> putting a few screencasts up on the site for various things - I personally
> quite like short videos over following text instructions. Personal
> preference of course.
>
> Jon
>
> On Tue, Jul 11, 2017 at 1:08 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > We can also "just" add a video to the website to have it permanent in
> case
> > part of the world misses the webinar ;)
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-11 13:42 GMT+02:00 Andy Gumbrecht <agumbre...@tomitribe.com>:
> >
> > > That's a really cool idea Ivan - How about proposing a 'Getting
> Started'
> > > webinar and inviting the user and dev list?
> > >
> > > Andy.
> > >
> > > On 11 July 2017 at 13:19, Ivan Junckes Filho <ivanjunc...@gmail.com>
> > > wrote:
> > >
> > > > Hi Elder, If you need a google hangout to get started on the website
> > let
> > > me
> > > > know.
> > > >
> > > > I have been touching it lately and will be happy to help.
> > > >
> > > >
> > > >
> > > > On Tue, Jul 11, 2017 at 3:30 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi Elder,
> > > > >
> > > > > site was not yet updated (any volonteer welcomed ;)) but you can do
> > it
> > > on
> > > > > github through a PR:
> > > > >
> > > > > 1. fork https://github.com/apache/tomee-site-generator
> > > > > 2. add a page in
> > > > > https://github.com/apache/tomee-site-generator/tree/
> > > > > master/src/main/jbake/content
> > > > > 3. add a link to this page
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > > rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE
> Factory
> > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > >
> > > > > 2017-07-11 1:07 GMT+02:00 Daniel Cunha <daniels...@apache.org>:
> > > > >
> > > > > > Hi Elder,
> > > > > >
> > > > > > Look the section Contribute the this site.
> > > > > > http://tomee.apache.org/community/index.html
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > Daniel Cunha
> > > > > > https://twitter.com/dvlc_
> > > > > >
> > > > > > On Jul 10, 2017 6:59 PM, "Elder Moraes" <elder.mor...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Hello David, Romain and others,
> > > > > >
> > > > > > I've just figured it out! Now I have a real static cluster, with
> > > > session
> > > > > > being shared between nodes and avoiding unexpected members to
> > joining
> > > > in.
> > > > > >
> > > > > > There are 3 

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

We can also "just" add a video to the website to have it permanent in case
part of the world misses the webinar ;)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-11 13:42 GMT+02:00 Andy Gumbrecht <agumbre...@tomitribe.com>:

> That's a really cool idea Ivan - How about proposing a 'Getting Started'
> webinar and inviting the user and dev list?
>
> Andy.
>
> On 11 July 2017 at 13:19, Ivan Junckes Filho <ivanjunc...@gmail.com>
> wrote:
>
> > Hi Elder, If you need a google hangout to get started on the website let
> me
> > know.
> >
> > I have been touching it lately and will be happy to help.
> >
> >
> >
> > On Tue, Jul 11, 2017 at 3:30 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > Hi Elder,
> > >
> > > site was not yet updated (any volonteer welcomed ;)) but you can do it
> on
> > > github through a PR:
> > >
> > > 1. fork https://github.com/apache/tomee-site-generator
> > > 2. add a page in
> > > https://github.com/apache/tomee-site-generator/tree/
> > > master/src/main/jbake/content
> > > 3. add a link to this page
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2017-07-11 1:07 GMT+02:00 Daniel Cunha <daniels...@apache.org>:
> > >
> > > > Hi Elder,
> > > >
> > > > Look the section Contribute the this site.
> > > > http://tomee.apache.org/community/index.html
> > > >
> > > > Thank you.
> > > >
> > > > Daniel Cunha
> > > > https://twitter.com/dvlc_
> > > >
> > > > On Jul 10, 2017 6:59 PM, "Elder Moraes" <elder.mor...@gmail.com>
> > wrote:
> > > >
> > > > Hello David, Romain and others,
> > > >
> > > > I've just figured it out! Now I have a real static cluster, with
> > session
> > > > being shared between nodes and avoiding unexpected members to joining
> > in.
> > > >
> > > > There are 3 key points:
> > > >
> > > >1. channelStartOptions="3" (to avoid using multicast);
> > > >2. Receiver and Member using the same port;
> > > >3. Turn one of the members into a LocalMember (instead of Member).
> > It
> > > >will work as the Replication Listener and Receiver Server.
> > > >
> > > > By doing this you'll be able to see, after all the nodes are up and
> > > > running, the Group Channel showing confirmation of each node added.
> And
> > > > once you try to add another with unexpected IP, it is solemnly
> > ignored...
> > > > ;-)
> > > >
> > > > How can I turn it into some documentation for Tomee? I have all the
> > > > details...
> > > >
> > > >
> > > >
> > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > Blog: http://eldermoraes.com
> > > >
> > > >
> > > >
> > > > 2017-07-10 14:40 GMT-03:00 Elder Moraes <elder.mor...@gmail.com>:
> > > >
> > > > > Hey David!
> > > > >
> > > > > I've sent to the Tomcat list, but still didn't get any reply.
> > > > >
> > > > > Anyway I'm still trying to figure it out by myself and will be a
> > > pleasure
> > > > > to contribute with some docs once I do it.
> > > > >
> > > > >
> > > > > Tks!
> > > > >
> > > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > > Blog: http://eldermoraes.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2017-07-09 2:50 GMT-03:00 David Blevin

Re: [PR] TOMEE-2087 IvmContext.list() does not correctly list the context content

[Romain Manni-Bucau]

2017-07-11 12:38 GMT+02:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com>:

> I've added several JUnit test cases in openejb-core that should verify
> IvmContext.list() behaviour, yet I'll feel safer if we keep the arquillian
> test as well.
>

+1, both are needed


>
> 2017-07-11 10:10 GMT+03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > side note: embedded (not tomcat based) testing is needed to ensure we
> don't
> > break but doesn't fully test the ivmcontext code because the federation
> is
> > different so guess starting with tomcat is not that bad.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-11 8:28 GMT+02:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com
> >:
> >
> > > Hi David,
> > >
> > > Thank you for sparing some time to look into my PR !
> > >
> > > > I’m not sure I can see how the test actually works
> > >
> > > The issue is that IvmContext.list() returns objects that are not really
> > > bound into the listed context. For instance if you run the MCVE
> attached
> > to
> > > the jira ticket you'll see that it returns [1]. There you can see that
> > > TestEJB is bound in "java:" (and even appears several times!) or that
> > > "java:global" is bound in "java:module". But if you try to look up
> those
> > > entries, the lookup fails with a NameNotFoundException, because all
> these
> > > references are not really bound there. So the test recursively lists
> all
> > > contexts in the JNDI tree and tries to lookup up every name-class pair
> > that
> > > is returned. If the lookup fails, it means that list() has returned
> > > something that is not really there. You can compare [1] and [2] 9after
> > the
> > > fix) to see the difference in list()'s behaviour
> > >
> > > > Is there a test for listBindings?  It’s mentioned as also broken,
> but I
> > > didn’t see a test for it.
> > >
> > > IvmContext.listBindings() and IvmContext.list() use the very same
> > > IvmContext.MyNamingEnumeration abstract class and share the very same
> > logic
> > > to traverse the naming tree. I didn't write test for it because they
> > share
> > > the same code, but I can easily modify it to run aginst both methods.
> > >
> > > > What is the PrintWriter used for?  It seems it could be useful to
> > assert
> > > it prints what we expect.  Not sure if that is there and I am missing
> it.
> > >
> > > I thought it would be helpful to be able to see what went wrong if the
> > test
> > > fails. The IvmContextTest class collects the output from the servlet's
> > > output stream (the print writer) and if the test fails it prints it in
> > the
> > > console.
> > >
> > > > There is an IvmContextTest, could we put the test there?
> > >
> > > That was my initial idea, but AppComposer's naming tree is very
> different
> > > that tomee's. For instance it does not have the "app", "global", etc
> top
> > > level contexts and my fix has special code for such top-level
> contexts. I
> > > also was not bale to bind any env-entries to my EJB (I'm not really
> > > familiar with how to write a proper appcomposer test, so I guess I
> didn't
> > > do something that I should have.). The env-entries are needed just to
> > > create a couple of branches to the tree in order to test if
> > > MyNamingEnumeration.isMyChild() works correctly
> > >
> > > > so we could potentially skip the plumbing of the test->servlet->ejb.
> > >
> > > I'll look into it. I also have a few ideas for additioanl tests.
> > >
> > > [1] https://gist.github.com/SvetlinZarev/
> 6b9377fe05b7887d681491c3e9e538
> > 21
> > > [2] https://gist.github.com/SvetlinZarev/
> db3b59404198cd494b45b23db7129e
> > dd
> > >
> > > Bets regards,
> > > Svetlin
> > >
> > > 2017-07-11 2:28 GMT+03:00 David Blevins <david.blev...@gmail.com>:
> > >
> > > > Hi Svetlin!
> > > >
> > > > This 

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

Hi Elder,

site was not yet updated (any volonteer welcomed ;)) but you can do it on
github through a PR:

1. fork https://github.com/apache/tomee-site-generator
2. add a page in
https://github.com/apache/tomee-site-generator/tree/master/src/main/jbake/content
3. add a link to this page


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-11 1:07 GMT+02:00 Daniel Cunha <daniels...@apache.org>:

> Hi Elder,
>
> Look the section Contribute the this site.
> http://tomee.apache.org/community/index.html
>
> Thank you.
>
> Daniel Cunha
> https://twitter.com/dvlc_
>
> On Jul 10, 2017 6:59 PM, "Elder Moraes" <elder.mor...@gmail.com> wrote:
>
> Hello David, Romain and others,
>
> I've just figured it out! Now I have a real static cluster, with session
> being shared between nodes and avoiding unexpected members to joining in.
>
> There are 3 key points:
>
>1. channelStartOptions="3" (to avoid using multicast);
>2. Receiver and Member using the same port;
>3. Turn one of the members into a LocalMember (instead of Member). It
>will work as the Replication Listener and Receiver Server.
>
> By doing this you'll be able to see, after all the nodes are up and
> running, the Group Channel showing confirmation of each node added. And
> once you try to add another with unexpected IP, it is solemnly ignored...
> ;-)
>
> How can I turn it into some documentation for Tomee? I have all the
> details...
>
>
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
>
> 2017-07-10 14:40 GMT-03:00 Elder Moraes <elder.mor...@gmail.com>:
>
> > Hey David!
> >
> > I've sent to the Tomcat list, but still didn't get any reply.
> >
> > Anyway I'm still trying to figure it out by myself and will be a pleasure
> > to contribute with some docs once I do it.
> >
> >
> > Tks!
> >
> > Twitter: @elderjava <https://twitter.com/elderjava>
> > Blog: http://eldermoraes.com
> >
> >
> >
> >
> > 2017-07-09 2:50 GMT-03:00 David Blevins <david.blev...@gmail.com>:
> >
> >>  Hi Elder! just checking to see if you got the help you were looking
> for.
> >>
> >>  When you get it figured out any new docs would be amazing.
> >>
> >> On Fri, Jul 7, 2017 at 9:57 AM Elder Moraes <elder.mor...@gmail.com>
> >> wrote:
> >>
> >> > Ok, will try them.
> >> >
> >> > Thanks!
> >> >
> >> >
> >> > Twitter: @elderjava <https://twitter.com/elderjava>
> >> > Blog: http://eldermoraes.com
> >> >
> >> >
> >> >
> >> > 2017-07-06 18:02 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >> >
> >> > > outch, no more, didnt resetup a cluster since 2 years. But if you
> >> push a
> >> > > tomee-maven-plugin sample it would be quick to help.
> >> > >
> >> > > Side note: Tomcat list can also be more relevant since they fully
> own
> >> > that
> >> > > part.
> >> > >
> >> > >
> >> > > Romain Manni-Bucau
> >> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >> > > rmannibucau> |
> >> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> >> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> >> > >
> >> > > 2017-07-06 22:52 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> >> > >
> >> > > > Do you have some working example? Don't need to be dockerized.
> >> > > >
> >> > > >
> >> > > > Twitter: @elderjava <https://twitter.com/elderjava>
> >> > > > Blog: http://eldermoraes.com
> >> > > >
> >> > > >
> >> > > > 2017-07-06 17:05 GMT-03:00 Romain Manni-Bucau <
> >> rmannibu...@gmail.com>:
> >> > > >
> >> > > > > yes should help, you can
>

Re: When building locally TomEE has tons of broken tests.

[Romain Manni-Bucau]

2017-07-10 8:53 GMT+02:00 Mark Struberg :

> IF we want to increase the community activity, then we first need to have
> a stable local build.
> One has to checkout, run mvn clean install and get a green build.
> Currently that's just not the case. It seems that the tests only run fine
> on the CI box. That's a showstopper for any community involvement.
>

linux boxes actually. We also have some timing related tests which can fail
on slow machines but increasing too much the timeout will just lead to
removing the test.

We sometimes got some proposal to have a fast default profile build but not
sure it helps since contributors would IMHO feel insulted by us faking them
a green build.

Wonder if we could propose a set of test by modification area, like "run
X1Test, X2Test, X3Test" if you modify injections, "X4Test" if you modify
the datasource pooling, etc...


> I've started tracking down those tests in error. I can test Linux and OSX
> in parallel
> Starting with https://issues.apache.org/jira/browse/TOMEE-2088
> LieGrue,strub
>

Re: Miss the contributing section on the new web site

[Romain Manni-Bucau]

For the color feel free to propose another set but for the community page
old site had everything generating several complaints it was hard to browse
and find either mailint list of code related information. This design fixed
it with the drawback of adding a level of navigation. A potential
enhancement is to add 1 line with a link to github, kind of "quick link",
in souce part and probably the dev list in support part.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-10 8:58 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:

> 'Community' is literally the LAST tab. And then it's a well hidden
> link.It's really hard to detect, "Nothing simpler, just go there." And
> 'there' is a link which is dark magenta instead of black. Mark the page and
> you don't even see what is a link and what not.Links imo should stand out
> much better.
> The old page had "do a $> git clone ..tomee.git" for getting the source
> code.Without having to navigate to 3 sub pages.
>
>
>
> On Monday, 10 July 2017, 08:50:57 CEST, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
> Hi Mark
>
> 2017-07-10 7:51 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:
>
> > Hi folks!
> > A bit of feedback for the new site.It looks really great but there are a
> > few minor glitches still:
> > * The most important information is missing: How to obtain the source
> > code!This information used to be here in the old site
> > http://tomee.apache.org/contribute.htmlThis whole page is missing,
> isn't?
> >
>
> This is not true, hit "community" (
> http://tomee.apache.org/community/index.html) then first link and here you
> are (http://tomee.apache.org/community/sources.html)
>
>
> > * Missing breadcrumbs.The main menu doesn't indicate in which section you
> > are. If you click on 'Admin' it doesn't get highlightes. Feels a bit
> > unnatural for a menu.
> >
>
> Ivan will drop it to only put "documentation" which seems to be better for
> almost everybody so no more breadcrumb needed.
>
>
> > * 'Security' points to an old-style page. Wonder why we still have both
> > css around?
> >
>
> We kept old page, security still needs to be migrated.
>
>
> >
> > I'm really not good at CSS and styling, so just pointing out.
> >
>
> There is no css to do since we have templates, just the content to move to
> .adoc and the links to updates.
>
>
> > LieGrue,strub
> >
>

Re: Miss the contributing section on the new web site

[Romain Manni-Bucau]

Hi Mark

2017-07-10 7:51 GMT+02:00 Mark Struberg :

> Hi folks!
> A bit of feedback for the new site.It looks really great but there are a
> few minor glitches still:
> * The most important information is missing: How to obtain the source
> code!This information used to be here in the old site
> http://tomee.apache.org/contribute.htmlThis whole page is missing, isn't?
>

This is not true, hit "community" (
http://tomee.apache.org/community/index.html) then first link and here you
are (http://tomee.apache.org/community/sources.html)


> * Missing breadcrumbs.The main menu doesn't indicate in which section you
> are. If you click on 'Admin' it doesn't get highlightes. Feels a bit
> unnatural for a menu.
>

Ivan will drop it to only put "documentation" which seems to be better for
almost everybody so no more breadcrumb needed.


> * 'Security' points to an old-style page. Wonder why we still have both
> css around?
>

We kept old page, security still needs to be migrated.


>
> I'm really not good at CSS and styling, so just pointing out.
>

There is no css to do since we have templates, just the content to move to
.adoc and the links to updates.


> LieGrue,strub
>

Re: Site and "documentation" usage

[Romain Manni-Bucau]

+1

Le 8 juil. 2017 19:53, "Ivan Junckes Filho" <ivanjunc...@gmail.com> a
écrit :

> Hello TomEE devs, I fixed the 404 issue.
>
> https://ivanjunckes.github.io/admin
> https://ivanjunckes.github.io/developers
> https://ivanjunckes.github.io/advanced
>
> How can we proceed from here? Can we get this change merged?
>
> On Thu, Jul 6, 2017 at 12:39 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > Not a big fan of "list sites" cause basically you dont find anything (or
> it
> > is faster to find it in code). Arquillian one is way better IMO.
> >
> > Le 6 juil. 2017 17:15, "Andy Gumbrecht" <agumbre...@tomitribe.com> a
> > écrit :
> >
> > > Just out of interest, what is everyone's favourite OSS website? I
> really
> > > like http://projects.spring.io/spring-boot/ and https://fabric8.io/
> > >
> > > On 6 July 2017 at 15:58, Andy Gumbrecht <agumbre...@tomitribe.com>
> > wrote:
> > >
> > > > +1 to go to the user list and maybe get some feedback before pushing,
> > but
> > > > also..
> > > >
> > > > +1 to push it as is - Looks really good Ivan, so thank you very much
> > for
> > > > the hard work, and working together on the hosting for review issues.
> > > Thank
> > > > you Romain for getting the code set up on GitHub. That makes reviews
> > much
> > > > more transparent!
> > > >
> > > > +1 for continuing to improve the 404 issues over time.
> > > >
> > > > Andy.
> > > >
> > > > On 6 July 2017 at 14:46, Daniel Cunha <daniels...@apache.org> wrote:
> > > >
> > > >> +1 to post it user@ list.
> > > >> The users are the real consumers of the website and their feedback
> is
> > > >> really important.
> > > >>
> > > >> On Thu, Jul 6, 2017 at 9:38 AM, Jonathan Gallimore <
> > > >> jonathan.gallim...@gmail.com> wrote:
> > > >>
> > > >> > Hi Ivan!
> > > >> >
> > > >> > Thanks for the links. My personal view - I prefer the
> documentation
> > > >> link,
> > > >> > but I do like the split of the documentation page into groups. The
> > > >> > advantage here as I see it is all the documentation is linked in
> one
> > > >> place
> > > >> > - no need to go into 'Developer' and realize its not there, and
> then
> > > >> check
> > > >> > 'Admin'.
> > > >> >
> > > >> > I also wonder if we should also post this to the users@ list to
> see
> > > if
> > > >> > there are any preferences there?
> > > >> >
> > > >> > I understand Romain's points about the 404 (see the PR comments)
> - a
> > > >> > potential compromise there is for the admin and developer links to
> > > >> forward
> > > >> > onto the documentation page with a note saying its moved and
> "please
> > > >> update
> > > >> > your bookmarks". We'll inevitably want to move content around
> and/or
> > > >> change
> > > >> > the structure over time. Some sort of graceful way of doing that
> > like
> > > I
> > > >> > described might be good pattern to follow.
> > > >> >
> > > >> > Thanks for taking the time to hack on this and present it to the
> > > >> community!
> > > >> >
> > > >> > Jon
> > > >> >
> > > >> > On Thu, Jul 6, 2017 at 1:30 PM, Ivan Junckes Filho <
> > > >> ivanjunc...@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > (Please disregard the previous email, pressed enter by mistake)
> > > >> > >
> > > >> > > Hi guys, thank you for the feedback on this. The intention of
> the
> > > >> > > "Documentation" was to let the user know exactly where what he
> is
> > > >> looking
> > > >> > > for is. The content inside is not perfect, but we are getting
> > > better.
> > > >> > >
> > > >> > > The links for the changes made are below, please give feedback
> on
> > > >> them.
> > > >> > >
> > > >> > &g

Re: [Discuss] Review-than-commit 3 month trial

[Romain Manni-Bucau]

@Andy: discussion is not if the process is easy or not but if it would be
beneficial to the project.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-07 16:40 GMT+02:00 Andy Gumbrecht <agumbre...@tomitribe.com>:

> If someone comes up 'after' the Consensus Approval (3+1) with a -1 then
> they must submit a counter PR, that must also pass the RTC.
>
> It's pretty straight forward.
>
> On 7 July 2017 at 16:36, Andy Gumbrecht <agumbre...@tomitribe.com> wrote:
>
> > ;-)
> >
> > On 7 July 2017 at 16:34, Andy Gumbrecht <agumbre...@tomitribe.com>
> wrote:
> >
> >> RTC is Consensus Approval and does not need 72h, just 3+1 in any amount
> >> of time.
> >>
> >> On 7 July 2017 at 16:33, Andy Gumbrecht <agumbre...@tomitribe.com>
> wrote:
> >>
> >>> Those quotes are from Apache.
> >>>
> >>> On 7 July 2017 at 16:30, Romain Manni-Bucau <rmannibu...@gmail.com>
> >>> wrote:
> >>>
> >>>> What Mark meant is if we go through a "vote" then we need to comply to
> >>>> ASF
> >>>> rules. Otherwise anything is up to the project and not a "vote".
> >>>> #semantic
> >>>> ;)
> >>>>
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >>>> <http://rmannibucau.wordpress.com> | Github <
> >>>> https://github.com/rmannibucau> |
> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> >>>> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>>>
> >>>> 2017-07-07 16:28 GMT+02:00 Andy Gumbrecht <agumbre...@tomitribe.com>:
> >>>>
> >>>> > A release is:
> >>>> >
> >>>> > Majority Approval
> >>>> > Refers to a vote (sense 1) which has completed with at least three
> >>>> binding
> >>>> > +1 votes and more +1 votes than -1 votes - You have to wait 72h.
> >>>> >
> >>>> > On 7 July 2017 at 16:25, Andy Gumbrecht <agumbre...@tomitribe.com>
> >>>> wrote:
> >>>> >
> >>>> > > This is not a vote for a release, if you get 3+1s within a minute
> >>>> then
> >>>> > you
> >>>> > > don't have to wait 72h. It is 'Consensus Approval'.
> >>>> > >
> >>>> > > Consensus Approval
> >>>> > > 'Consensus approval' refers to a vote (sense 1) which has
> *completed
> >>>> > *with
> >>>> > > at least three binding +1 votes and no vetos
> >>>> > >
> >>>> > > On 7 July 2017 at 16:19, Mark Struberg <strub...@yahoo.de.invalid
> >
> >>>> > wrote:
> >>>> > >
> >>>> > >> You know how voting works at the ASF? ;)
> >>>> > >>
> >>>> > >> Either have a VOTE - with all it's implciations - or not.
> >>>> > >>
> >>>> > >>
> >>>> > >> LieGrue,
> >>>> > >> strub
> >>>> > >>
> >>>> > >> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht <
> >>>> > agumbre...@tomitribe.com
> >>>> > >> >:
> >>>> > >> >
> >>>> > >> > There's no 72h waiting period? Just 3+1 to commit. I'd even be
> >>>> for a
> >>>> > >> 2+1.
> >>>> > >> >
> >>>> > >> > As soon as whatever is decided is counted then the commit
> >>>> occurs. That
> >>>> > >> > could be within a few minutes.
> >>>> > >> >
> >>>> > >> > Andy.
> >>>> > >> >
> >>>> > >> > On 7 July 2017 at 14:59, Mark Struberg
> <strub...@yahoo.de.invalid
> >>>> >
> >>>> > >> wrote:
> >>

Re: [Discuss] Review-than-commit 3 month trial

[Romain Manni-Bucau]

Not sure there will be a consensus so how do we close that thread?

>From what happent last weeks seems project is back on track so I'm tempted
to say we should keep it like that for now. Alternative is to do an ASF
vote to see if we go with RTC.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-07 16:19 GMT+02:00 Mark Struberg <strub...@yahoo.de.invalid>:

> You know how voting works at the ASF? ;)
>
> Either have a VOTE - with all it's implciations - or not.
>
>
> LieGrue,
> strub
>
> > Am 07.07.2017 um 15:41 schrieb Andy Gumbrecht <agumbre...@tomitribe.com
> >:
> >
> > There's no 72h waiting period? Just 3+1 to commit. I'd even be for a 2+1.
> >
> > As soon as whatever is decided is counted then the commit occurs. That
> > could be within a few minutes.
> >
> > Andy.
> >
> > On 7 July 2017 at 14:59, Mark Struberg <strub...@yahoo.de.invalid>
> wrote:
> >
> >> +1 well said, Jeff!
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 06.07.2017 um 18:37 schrieb Jeff Genender <jgenen...@apache.org>:
> >>>
> >>> Lurking on this, I have to underscore what Mark said.
> >>>
> >>> Andy, you are pretty correct on nearly every point that you made.  But
> >> the things stated are more of refining your current process rather than
> >> taking RTC for current committers.  You already had RTC with PRs from
> >> outsiders.  If that slipped in, it just means that a trusted committer
> >> didn’t do their job.  It happens.   Breaking a trunk build for a day (or
> >> even a week) is ok.  Thats why its trunk.  I cannot tell you how many
> times
> >> I have downloaded a project’s trunk and things weren’t quite right.
> >>>
> >>> Relative to what prompted this RTC discussion again, I think things got
> >> emotional and people slipped up afterwards.  The beauty of all this is
> all
> >> parties shook hands and made up.  Problem was more-or-less solved and
> the
> >> project was back on track.
> >>>
> >>> IMHO, taking on RTC is punitive.  It means that you need to reset the
> >> way you do things because you cannot do it yourselves.  Do you think you
> >> are at that point?  It didn’t look that way to me… but its certainly
> >> possible based on what is being done behind the scenes.
> >>>
> >>> Just some food for thought.
> >>>
> >>> Jeff
> >>>
> >>>
> >>>
> >>>> On Jul 5, 2017, at 7:49 PM, Andy Gumbrecht <agumbre...@tomitribe.com>
> >> wrote:
> >>>>
> >>>> The main issue here is that both new and existing developers on the
> >> project
> >>>> need breathing space in order to thrive and grow.
> >>>>
> >>>> The period between releases is for everyone and not just the few. It
> is
> >>>> only 99.99% OK for one or two individuals. Everyone else seems to be
> >>>> suffering behind closed doors or in silence, or fighting constant
> >> mobbing
> >>>> to the point where 'our' fun project has become too tedious for many
> >>>> people's free time.
> >>>>
> >>>> I'm not going to focus on the reasons behind the "Suffocating
> >> development
> >>>> environment" thread, only that it was the web 'staging' environment
> used
> >>>> for a review, but treated like it was North Korea production nuclear
> >> bomb
> >>>> code. It should have been handled better. We found a resolution the
> long
> >>>> way round (github web hosting).
> >>>>
> >>>> However, the situation has evolved where existing committers don't
> >> discuss,
> >>>> create or assign tickets because they are literally mobbed or hijacked
> >> by
> >>>> another committer within minutes.
> >>>> That is currently so predictable that it has become a kind of un-funny
> >> joke
> >>>> even outside of our community. Tickets are often created 'after' a
> >> commit
> >>>> with a closed status.
> >>>>
> >>>> What needs to change is:
> >&

Re: Example+request

[Romain Manni-Bucau]

Hi

did you have a look to
https://github.com/apache/tomee/tree/master/examples/rest-example? Except
the client part it matches it. Not sure what you mean by "client using
EJBContainer" since EJBContainer is a server technology so orthogonal to
the client needs.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-07 8:20 GMT+02:00 Ojha, Pradeep Kumar <pradeep.o...@atos.net>:

> Hi,
>
> I'm new to EJB. I'm looking for a simple EJB3 application with CRUD
> operations.
> The project should have Maven.
> The EJB component needs to be deployed on server (either OpenEJB or JBoss)
> and then accessed through client application or Junit with the help of
> EJBContainer.
>
> For Example: I have one Entity such as Employee or Student. One local
> Session Bean and its implementation.  The EJB need to be deployed in server
> and then need to access through client using EJBContainer.
>
>
> Thanks and regards,
> Pradeep Kumar Ojha
> pradeepkumaro...@live.com
>
>

Re: Adds an option to ignore mdb.activation fields

[Romain Manni-Bucau]

good catch for the typo,

-0 to backport it (really read it as "this flag shouldnt have existed
anyway" more than "don't backport it")


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-07 12:43 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> I think we also have a typo in "FailOnUnknownActivationSpec" where an 'n'
> is missing. I think we should correct that.
>
> https://github.com/apache/tomee/blob/master/container/
> openejb-core/src/main/resources/META-INF/org.apache.
> openejb/service-jar.xml#L494
>
> Jon
>
> On Fri, Jul 7, 2017 at 11:40 AM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > I'm thinking something along the lines of:
> >
> >   
> > ResourceAdapter MyResourceAdapter
> > ActivationSpecClass My.ActivationSpecImpl
> >
> >activation.property1 = value1
> >activation.property2 = value2
> >   
> >
> >   
> > ResourceAdapter MyOTHERResourceAdapter
> > ActivationSpecClass My.Other.ActivationSpecImpl
> >activation.property1 = othervalue1
> >activation.property2 = othervalue2
> >   
> >
> > So all the MDBs in container MDB1 would get the following on their
> > activation spec
> >property1 = value1
> >property2 = value2
> >
> > And all the MDBs in container MDB2 would get the following on their
> > activation spec
> >property1 = othervalue1
> >property2 = othervalue2
> >
> >
> > And then have the potential to override them with system.properties like
> > so:
> >MDB1.activation.property1 = othervalue1
> >MDB1.activation.property2 = othervalue2
> >MDB2.activation.property1 = othervalue1
> >MDB2.activation.property2 = othervalue2
> >
> > Maybe something is needed to call 'MDB1' out as a container as opposed to
> > a bean name. In terms of precedence, I'd expect properties on the
> container
> > to override any `mdb.activation` properties, and any properties specific
> to
> > a bean to override any container properties - so its Global
> > (mdb.activation) -> Container ([containerid].activation) -> Bean
> > ([BeanName].activation).
> >
> > I imagine it would essentially boil down to a new key at the point you
> > suggest, and expand on the test cases.
> >
> > I'm in favour of the backport irrespective of whether we choose to
> explore
> > my suggestion (or any other suggestion) though.
> >
> > Cheers
> >
> > Jon
> >
> > On Thu, Jul 6, 2017 at 10:09 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > > wrote:
> >
> >> 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <jgallim...@tomitribe.com
> >:
> >>
> >> > I'm +1 for back porting that patch, thanks Otavio.
> >> >
> >> > One thing I'd be interested in as an extra, is seeing if we can set
> >> > activation properties on a per-container basis too.
> >> >
> >>
> >> Mean like adding one new key in
> >> https://github.com/apache/tomee/blob/master/container/openej
> >> b-core/src/main/java/org/apache/openejb/config/Activati
> >> onConfigPropertyOverride.java#L94
> >> using .container.?
> >>
> >> +1 if ~so (just wanted to avoid a misunderstanding and get a completely
> >> new
> >> feature/code)
> >>
> >>
> >>
> >> Side note on the fail flag: this was a flag added to pass tck and was in
> >> "ignore" mode of the MDB (which is fine for this need) but not intended
> to
> >> be used or reliable for real applications where it would be saner to fix
> >> the broken configuration instead of bet on it working ignoring the work
> >> some people did configuring it. I'm not against backporting it but think
> >> it
> >> is important to remind that I think we don't want to promote that flag
> >> (shouldn't hit the doc for instance since it is an internal workaround
> >> IMHO).
> >>
> >>
> >> >
> >> > What do you think?
> >> >
> >> > Jon
> >> >
> >> > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> >> > osant...@tomitribe.com> wr

Re: Adds an option to ignore mdb.activation fields

[Romain Manni-Bucau]

sounds good this way for container activation props


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-07 12:40 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> I'm thinking something along the lines of:
>
>   
> ResourceAdapter MyResourceAdapter
> ActivationSpecClass My.ActivationSpecImpl
>
>activation.property1 = value1
>activation.property2 = value2
>   
>
>   
> ResourceAdapter MyOTHERResourceAdapter
> ActivationSpecClass My.Other.ActivationSpecImpl
>activation.property1 = othervalue1
>activation.property2 = othervalue2
>   
>
> So all the MDBs in container MDB1 would get the following on their
> activation spec
>property1 = value1
>property2 = value2
>
> And all the MDBs in container MDB2 would get the following on their
> activation spec
>property1 = othervalue1
>property2 = othervalue2
>
>
> And then have the potential to override them with system.properties like
> so:
>MDB1.activation.property1 = othervalue1
>MDB1.activation.property2 = othervalue2
>MDB2.activation.property1 = othervalue1
>MDB2.activation.property2 = othervalue2
>
> Maybe something is needed to call 'MDB1' out as a container as opposed to a
> bean name. In terms of precedence, I'd expect properties on the container
> to override any `mdb.activation` properties, and any properties specific to
> a bean to override any container properties - so its Global
> (mdb.activation) -> Container ([containerid].activation) -> Bean
> ([BeanName].activation).
>
> I imagine it would essentially boil down to a new key at the point you
> suggest, and expand on the test cases.
>
> I'm in favour of the backport irrespective of whether we choose to explore
> my suggestion (or any other suggestion) though.
>
> Cheers
>
> Jon
>
> On Thu, Jul 6, 2017 at 10:09 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > 2017-07-06 23:01 GMT+02:00 Jonathan Gallimore <jgallim...@tomitribe.com
> >:
> >
> > > I'm +1 for back porting that patch, thanks Otavio.
> > >
> > > One thing I'd be interested in as an extra, is seeing if we can set
> > > activation properties on a per-container basis too.
> > >
> >
> > Mean like adding one new key in
> > https://github.com/apache/tomee/blob/master/container/
> > openejb-core/src/main/java/org/apache/openejb/config/
> > ActivationConfigPropertyOverride.java#L94
> > using .container.?
> >
> > +1 if ~so (just wanted to avoid a misunderstanding and get a completely
> new
> > feature/code)
> >
> >
> >
> > Side note on the fail flag: this was a flag added to pass tck and was in
> > "ignore" mode of the MDB (which is fine for this need) but not intended
> to
> > be used or reliable for real applications where it would be saner to fix
> > the broken configuration instead of bet on it working ignoring the work
> > some people did configuring it. I'm not against backporting it but think
> it
> > is important to remind that I think we don't want to promote that flag
> > (shouldn't hit the doc for instance since it is an internal workaround
> > IMHO).
> >
> >
> > >
> > > What do you think?
> > >
> > > Jon
> > >
> > > On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> > > osant...@tomitribe.com> wrote:
> > >
> > > > The problem
> > > >
> > > > The configuration for MDB activation properties allow any key/value
> to
> > be
> > > > specified. At present on the 1.7.x branch, the server will fail to
> > deploy
> > > > the application if the activation property is not present on the
> > > activation
> > > > spec class.
> > > >
> > > > This becomes painful in a scenario where more than one JMS resource
> > > > adapter/MDB container is used, and you wish to configure the
> activation
> > > > properties of multiple MDBs in one go using the `mdb.activation.`
> > system
> > > > property.. Right now,if an activation property is used that one
> > provider
> > > > uses but other one does, the server will throw an exception.
> > > >
> > &

Re: Adds an option to ignore mdb.activation fields

[Romain Manni-Bucau]

2017-07-06 23:01 GMT+02:00 Jonathan Gallimore :

> I'm +1 for back porting that patch, thanks Otavio.
>
> One thing I'd be interested in as an extra, is seeing if we can set
> activation properties on a per-container basis too.
>

Mean like adding one new key in
https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/config/ActivationConfigPropertyOverride.java#L94
using .container.?

+1 if ~so (just wanted to avoid a misunderstanding and get a completely new
feature/code)



Side note on the fail flag: this was a flag added to pass tck and was in
"ignore" mode of the MDB (which is fine for this need) but not intended to
be used or reliable for real applications where it would be saner to fix
the broken configuration instead of bet on it working ignoring the work
some people did configuring it. I'm not against backporting it but think it
is important to remind that I think we don't want to promote that flag
(shouldn't hit the doc for instance since it is an internal workaround
IMHO).


>
> What do you think?
>
> Jon
>
> On Thu, Jul 6, 2017 at 9:44 PM, Otávio Gonçalves de Santana <
> osant...@tomitribe.com> wrote:
>
> > The problem
> >
> > The configuration for MDB activation properties allow any key/value to be
> > specified. At present on the 1.7.x branch, the server will fail to deploy
> > the application if the activation property is not present on the
> activation
> > spec class.
> >
> > This becomes painful in a scenario where more than one JMS resource
> > adapter/MDB container is used, and you wish to configure the activation
> > properties of multiple MDBs in one go using the `mdb.activation.` system
> > property.. Right now,if an activation property is used that one provider
> > uses but other one does, the server will throw an exception.
> >
> > For example, given these parameters,
> >
> >-
> >
> >   mdb.activation.ignore=foo
> >-
> >
> >   mdb.activation.ignore2=bar
> >
> >
> > if ‘ignore’ and ‘ignore2’ are not present on an MDB’s activation spec
> > class, the following exception will be thrown.
> >
> > Caused by: org.apache.openejb.OpenEJBException: Error deploying
> > 'Listener'.  Exception: class org.apache.openejb.OpenEJBException:
> Unable
> > to create activation spec: No setter found for the activation spec
> > properties: [ignore, ignore2]: Unable to create activation spec: No
> setter
> > found for the activation spec properties: [ignore, ignore2]
> >
> >at
> > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > Assembler.java:1430)
> >
> >at
> > org.apache.openejb.assembler.classic.Assembler.
> > createApplication(Assembler.java:796)
> >
> >... 19 more
> >
> > Caused by: org.apache.openejb.OpenEJBException: Unable to create
> > activation
> > spec: No setter found for the activation spec properties: [ignore,
> ignore2]
> >
> >at
> > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > MdbContainer.java:292)
> >
> >at org.apache.openejb.core.mdb.MdbContainer.deploy(
> > MdbContainer.java:159)
> >
> >at
> > org.apache.openejb.assembler.classic.Assembler.startEjbs(
> > Assembler.java:1417)
> >
> >... 20 more
> >
> > Caused by: java.lang.IllegalArgumentException: No setter found for the
> > activation spec properties: [ignore, ignore2]
> >
> >at
> > org.apache.openejb.core.mdb.MdbContainer.createActivationSpec(
> > MdbContainer.java:262)
> >
> >... 22 more
> >
> >
> > The solution
> >
> > The best solution to solve the communication among server is to put a new
> > configuration property in TomEE. When this setting is enabled, overriding
> > the FailOnUnknownActivationSpec attribute at
> > org.apache.openejb.core.mdb.MdbContainer class., that will be disabled
> by
> > default to don't break the compatibility, when the setter does not exist
> it
> > put a log and then keep working.
> >
> > Basically, my proposal does a backport to 1.7 branch:
> > https://github.com/apache/tomee/commit/6522f349d0c31d6ec82e66378e0e55
> > eded08aec0
> >
> > Path:
> >
> > https://patch-diff.githubusercontent.com/raw/apache/tomee/pull/86.diff
> >
>
>
>
> --
> Jonathan Gallimore
> http://twitter.com/jongallimore
> http://www.tomitribe.com
>

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

outch, no more, didnt resetup a cluster since 2 years. But if you push a
tomee-maven-plugin sample it would be quick to help.

Side note: Tomcat list can also be more relevant since they fully own that
part.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-06 22:52 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:

> Do you have some working example? Don't need to be dockerized.
>
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
> 2017-07-06 17:05 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > yes should help, you can
> > check org.apache.catalina.tribes.membership.McastServiceImpl#start,
> > org.apache.catalina.tribes.group.ChannelCoordinator#internalStart
> > and org.apache.catalina.tribes.group.ChannelCoordinator#sendMessage to
> see
> > it in action. It basically disable multicast services (threads) and
> switch
> > it to send messages
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-06 20:53 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> >
> > > The new logs are here:
> > >
> > > https://www.dropbox.com/s/1bdz8vf9pw0h42v/catalina.2017-07-06.log?dl=0
> > >
> > > Yes, it shows everything! ;-)
> > >
> > > The last four lines shows the unexpected member being added to the
> > cluster.
> > >
> > > Don't seems like is a Docker problem, as the new member is allowed by
> the
> > > cluster.
> > >
> > > The multicast setup that I've mentioned before has nothing to do?
> > >
> > >
> > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > Blog: http://eldermoraes.com
> > >
> > >
> > >
> > > 2017-07-06 15:42 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > >
> > > > What are the new logs? ;)
> > > >
> > > > Tomcat logs everything showing if connection works, if members are
> > > > accepted/connecting etc...
> > > >
> > > > From what i saw the docker setup is not matching the conf. Maybe
> start
> > by
> > > > making it running without docker before dockerizing it.
> > > >
> > > > Side note: maybe you want local member in your cluster (depends your
> > goal
> > > > but was often done IIRC).
> > > >
> > > > Le 6 juil. 2017 19:50, "Elder Moraes" <elder.mor...@gmail.com> a
> > écrit :
> > > >
> > > > > Thanks guys.
> > > > >
> > > > > I'm not using docker-compose.
> > > > >
> > > > > Actually I've just fixed that errors logged just by creating a
> > > > > docker-network for the cluster and defining a static IP for each
> > > member.
> > > > So
> > > > > the cluster is working well at this point.
> > > > >
> > > > > But it is still working as a dynamic one. I've found somewhere
> that I
> > > > > should use channelStartOptions="3" to disable multicast and avoid
> > > > > unexpected members. But once I do it, the session is not shared
> thru
> > > the
> > > > > cluster anymore.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > >
> > > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > > Blog: http://eldermoraes.com
> > > > >
> > > > >
> > > > > 2017-07-06 10:03 GMT-03:00 Thiago Veronezi <thi...@veronezi.org>:
> > > > >
> > > > > > If you are using docker-compose, check the depends_on option. It
> > will
> > > > > > guarantee you have your name available. It does not guarantee you
> > > have
> > > > > the
> > > > > > service fully up

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

yes should help, you can
check org.apache.catalina.tribes.membership.McastServiceImpl#start,
org.apache.catalina.tribes.group.ChannelCoordinator#internalStart
and org.apache.catalina.tribes.group.ChannelCoordinator#sendMessage to see
it in action. It basically disable multicast services (threads) and switch
it to send messages


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-06 20:53 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:

> The new logs are here:
>
> https://www.dropbox.com/s/1bdz8vf9pw0h42v/catalina.2017-07-06.log?dl=0
>
> Yes, it shows everything! ;-)
>
> The last four lines shows the unexpected member being added to the cluster.
>
> Don't seems like is a Docker problem, as the new member is allowed by the
> cluster.
>
> The multicast setup that I've mentioned before has nothing to do?
>
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
>
> 2017-07-06 15:42 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > What are the new logs? ;)
> >
> > Tomcat logs everything showing if connection works, if members are
> > accepted/connecting etc...
> >
> > From what i saw the docker setup is not matching the conf. Maybe start by
> > making it running without docker before dockerizing it.
> >
> > Side note: maybe you want local member in your cluster (depends your goal
> > but was often done IIRC).
> >
> > Le 6 juil. 2017 19:50, "Elder Moraes" <elder.mor...@gmail.com> a écrit :
> >
> > > Thanks guys.
> > >
> > > I'm not using docker-compose.
> > >
> > > Actually I've just fixed that errors logged just by creating a
> > > docker-network for the cluster and defining a static IP for each
> member.
> > So
> > > the cluster is working well at this point.
> > >
> > > But it is still working as a dynamic one. I've found somewhere that I
> > > should use channelStartOptions="3" to disable multicast and avoid
> > > unexpected members. But once I do it, the session is not shared thru
> the
> > > cluster anymore.
> > >
> > > Any thoughts?
> > >
> > >
> > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > Blog: http://eldermoraes.com
> > >
> > >
> > > 2017-07-06 10:03 GMT-03:00 Thiago Veronezi <thi...@veronezi.org>:
> > >
> > > > If you are using docker-compose, check the depends_on option. It will
> > > > guarantee you have your name available. It does not guarantee you
> have
> > > the
> > > > service fully up and running though. If you need that too, you will
> > need
> > > > the script to wait for the service behind that name to be ready.
> > > >
> > > > []s,
> > > > Thiago.
> > > >
> > > >
> > > > On 5 Jul 2017 6:16 pm, "Romain Manni-Bucau" <rmannibu...@gmail.com>
> > > wrote:
> > > >
> > > > > looks like docker dns is not working that well and registration
> > fails -
> > > > or
> > > > > the startup is not ordered properly but result lead to the same.
> > Often
> > > > saw
> > > > > docker-compose having a small bash loop to wait for the host/port
> > being
> > > > > accessible. Maybe that's what you need (yes it is ugly)
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > > rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE
> Factory
> > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > >
> > > > > 2017-07-06 0:13 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> > > > >
> > > > > > I've got the log and put here:
> > > > > >
> > > > > > https://www.dropbox.com/s/yxt3ym1ucv1hwb3/catalina.2017-
> > > 07-05.log?d

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

What are the new logs? ;)

Tomcat logs everything showing if connection works, if members are
accepted/connecting etc...

>From what i saw the docker setup is not matching the conf. Maybe start by
making it running without docker before dockerizing it.

Side note: maybe you want local member in your cluster (depends your goal
but was often done IIRC).

Le 6 juil. 2017 19:50, "Elder Moraes" <elder.mor...@gmail.com> a écrit :

> Thanks guys.
>
> I'm not using docker-compose.
>
> Actually I've just fixed that errors logged just by creating a
> docker-network for the cluster and defining a static IP for each member. So
> the cluster is working well at this point.
>
> But it is still working as a dynamic one. I've found somewhere that I
> should use channelStartOptions="3" to disable multicast and avoid
> unexpected members. But once I do it, the session is not shared thru the
> cluster anymore.
>
> Any thoughts?
>
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
> 2017-07-06 10:03 GMT-03:00 Thiago Veronezi <thi...@veronezi.org>:
>
> > If you are using docker-compose, check the depends_on option. It will
> > guarantee you have your name available. It does not guarantee you have
> the
> > service fully up and running though. If you need that too, you will need
> > the script to wait for the service behind that name to be ready.
> >
> > []s,
> > Thiago.
> >
> >
> > On 5 Jul 2017 6:16 pm, "Romain Manni-Bucau" <rmannibu...@gmail.com>
> wrote:
> >
> > > looks like docker dns is not working that well and registration fails -
> > or
> > > the startup is not ordered properly but result lead to the same. Often
> > saw
> > > docker-compose having a small bash loop to wait for the host/port being
> > > accessible. Maybe that's what you need (yes it is ugly)
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2017-07-06 0:13 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> > >
> > > > I've got the log and put here:
> > > >
> > > > https://www.dropbox.com/s/yxt3ym1ucv1hwb3/catalina.2017-
> 07-05.log?dl=0
> > > >
> > > >
> > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > Blog: http://eldermoraes.com
> > > >
> > > >
> > > >
> > > > 2017-07-05 18:56 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > > > interesting, would be great to have debug log of that clustering
> part
> > > > > (something like org.apache.catalina.tribes.level = FINE), think
> the
> > > > static
> > > > > members are actually excluded of the cluster reading this error
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > > rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE
> Factory
> > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > >
> > > > > 2017-07-05 23:53 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> > > > >
> > > > > > Hmm, why not the tcpfailuredetector as a root (/>) instead of
> > > wrapping
> > > > > the
> > > > > > static membership one?
> > > > > >
> > > > > > Done e got this error:
> > > > > >
> > > > > > 05-Jul-2017 21:51:32.845 WARNING
> > > > > > [GroupChannel-Heartbeat[Catalina-Channel]-1]
> > > > > > sun.reflect.NativeMethodAccessorImpl.invoke Unable to perform
> > > > heartbeat
> > > > > on
> > > > > > the TcpFailureDetector.
> > > > > >  java.lang.ArrayIndexOutOfBoundsException: 0
> > > > > > at

Re: Site and "documentation" usage

[Romain Manni-Bucau]

Not a big fan of "list sites" cause basically you dont find anything (or it
is faster to find it in code). Arquillian one is way better IMO.

Le 6 juil. 2017 17:15, "Andy Gumbrecht" <agumbre...@tomitribe.com> a écrit :

> Just out of interest, what is everyone's favourite OSS website? I really
> like http://projects.spring.io/spring-boot/ and https://fabric8.io/
>
> On 6 July 2017 at 15:58, Andy Gumbrecht <agumbre...@tomitribe.com> wrote:
>
> > +1 to go to the user list and maybe get some feedback before pushing, but
> > also..
> >
> > +1 to push it as is - Looks really good Ivan, so thank you very much for
> > the hard work, and working together on the hosting for review issues.
> Thank
> > you Romain for getting the code set up on GitHub. That makes reviews much
> > more transparent!
> >
> > +1 for continuing to improve the 404 issues over time.
> >
> > Andy.
> >
> > On 6 July 2017 at 14:46, Daniel Cunha <daniels...@apache.org> wrote:
> >
> >> +1 to post it user@ list.
> >> The users are the real consumers of the website and their feedback is
> >> really important.
> >>
> >> On Thu, Jul 6, 2017 at 9:38 AM, Jonathan Gallimore <
> >> jonathan.gallim...@gmail.com> wrote:
> >>
> >> > Hi Ivan!
> >> >
> >> > Thanks for the links. My personal view - I prefer the documentation
> >> link,
> >> > but I do like the split of the documentation page into groups. The
> >> > advantage here as I see it is all the documentation is linked in one
> >> place
> >> > - no need to go into 'Developer' and realize its not there, and then
> >> check
> >> > 'Admin'.
> >> >
> >> > I also wonder if we should also post this to the users@ list to see
> if
> >> > there are any preferences there?
> >> >
> >> > I understand Romain's points about the 404 (see the PR comments) - a
> >> > potential compromise there is for the admin and developer links to
> >> forward
> >> > onto the documentation page with a note saying its moved and "please
> >> update
> >> > your bookmarks". We'll inevitably want to move content around and/or
> >> change
> >> > the structure over time. Some sort of graceful way of doing that like
> I
> >> > described might be good pattern to follow.
> >> >
> >> > Thanks for taking the time to hack on this and present it to the
> >> community!
> >> >
> >> > Jon
> >> >
> >> > On Thu, Jul 6, 2017 at 1:30 PM, Ivan Junckes Filho <
> >> ivanjunc...@gmail.com>
> >> > wrote:
> >> >
> >> > > (Please disregard the previous email, pressed enter by mistake)
> >> > >
> >> > > Hi guys, thank you for the feedback on this. The intention of the
> >> > > "Documentation" was to let the user know exactly where what he is
> >> looking
> >> > > for is. The content inside is not perfect, but we are getting
> better.
> >> > >
> >> > > The links for the changes made are below, please give feedback on
> >> them.
> >> > >
> >> > > Pull Request:
> >> > > https://github.com/apache/tomee-site-generator/pull/1
> >> > >
> >> > > Website for review:
> >> > > https://ivanjunckes.github.io/
> >> > >
> >> > > Thank you.
> >> > >
> >> > >
> >> > > On Thu, Jul 6, 2017 at 9:27 AM, Ivan Junckes Filho <
> >> > ivanjunc...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Hi guys, thank you for the feedback on this. The intention of the
> >> > > > "Documentation" was to let the user know exactly where what he is
> >> > looking
> >> > > > for is. The content inside is not perfect, but we are getting
> >> better.
> >> > > >
> >> > > > Here are all the changes made
> >> > > >
> >> > > >
> >> > > > On Wed, Jul 5, 2017 at 7:51 PM, Romain Manni-Bucau <
> >> > > rmannibu...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > >> Ok, saw Andy did a similar comment on github so probably let's
> >> reverse
> >> > > the
> >> > > >> question.
> &

Re: Site and "documentation" usage

[Romain Manni-Bucau]

Yep, proposed it to ivan but think copy is a bit better cause the meta
usage ilplies latency on some browsers which is not that appreciated on a
phone or slow network.

But can be a cheap alternative if we dont want to invest in code.

Le 6 juil. 2017 16:19, "Daniel Cunha" <daniels...@apache.org> a écrit :

> for 404, could be this a solution:
> 
>
> Just an idea. :)
>
> On Thu, Jul 6, 2017 at 11:14 AM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > Ivan pushed a way to solve the 404, we just nees to extend it instead of
> > having it "inline". It is the copy trick for file-layout. We can use it
> for
> > any file.
> >
> > More generally i think not deleting is fine and we can add an adoc flag
> to
> > show a banner "not the current page".
> >
> > Le 6 juil. 2017 15:58, "Andy Gumbrecht" <agumbre...@tomitribe.com> a
> > écrit :
> >
> > > +1 to go to the user list and maybe get some feedback before pushing,
> but
> > > also..
> > >
> > > +1 to push it as is - Looks really good Ivan, so thank you very much
> for
> > > the hard work, and working together on the hosting for review issues.
> > Thank
> > > you Romain for getting the code set up on GitHub. That makes reviews
> much
> > > more transparent!
> > >
> > > +1 for continuing to improve the 404 issues over time.
> > >
> > > Andy.
> > >
> > > On 6 July 2017 at 14:46, Daniel Cunha <daniels...@apache.org> wrote:
> > >
> > > > +1 to post it user@ list.
> > > > The users are the real consumers of the website and their feedback is
> > > > really important.
> > > >
> > > > On Thu, Jul 6, 2017 at 9:38 AM, Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> wrote:
> > > >
> > > > > Hi Ivan!
> > > > >
> > > > > Thanks for the links. My personal view - I prefer the documentation
> > > link,
> > > > > but I do like the split of the documentation page into groups. The
> > > > > advantage here as I see it is all the documentation is linked in
> one
> > > > place
> > > > > - no need to go into 'Developer' and realize its not there, and
> then
> > > > check
> > > > > 'Admin'.
> > > > >
> > > > > I also wonder if we should also post this to the users@ list to
> see
> > if
> > > > > there are any preferences there?
> > > > >
> > > > > I understand Romain's points about the 404 (see the PR comments) -
> a
> > > > > potential compromise there is for the admin and developer links to
> > > > forward
> > > > > onto the documentation page with a note saying its moved and
> "please
> > > > update
> > > > > your bookmarks". We'll inevitably want to move content around
> and/or
> > > > change
> > > > > the structure over time. Some sort of graceful way of doing that
> > like I
> > > > > described might be good pattern to follow.
> > > > >
> > > > > Thanks for taking the time to hack on this and present it to the
> > > > community!
> > > > >
> > > > > Jon
> > > > >
> > > > > On Thu, Jul 6, 2017 at 1:30 PM, Ivan Junckes Filho <
> > > > ivanjunc...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > (Please disregard the previous email, pressed enter by mistake)
> > > > > >
> > > > > > Hi guys, thank you for the feedback on this. The intention of the
> > > > > > "Documentation" was to let the user know exactly where what he is
> > > > looking
> > > > > > for is. The content inside is not perfect, but we are getting
> > better.
> > > > > >
> > > > > > The links for the changes made are below, please give feedback on
> > > them.
> > > > > >
> > > > > > Pull Request:
> > > > > > https://github.com/apache/tomee-site-generator/pull/1
> > > > > >
> > > > > > Website for review:
> > > > > > https://ivanjunckes.github.io/
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > >
> > > > > > On Thu, Jul 6, 2017 at 9:27 AM, Ivan

Re: Site and "documentation" usage

[Romain Manni-Bucau]

Ok, saw Andy did a similar comment on github so probably let's reverse the
question.

Anyone feeling like me it is a passthrough? (if not under 1 day think we
can "close it" and just push it in prod)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-06 0:48 GMT+02:00 Thomas Whitmore <twhitm...@bravurasolutions.com>:

> For me the Documentation menu item is very good;  it shows at the top
> level that the TomEE project has documentation.
> Also like the content of the Documentation page, it hits 'How to
> Configure',  'IDEs' and 'Testing' upfront & early which should give a good
> impression on people considering uptake of the project -- as well as not
> looking so terribly empty.
>
> +1 on both fronts.
>
> Search can be an additional feature but for me getting the static text
> structure OK is paramount. I think Ivan has made very good improvement on
> that.
>
>
> -Original Message-
> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Sent: Thursday, 6 July 2017 9:09 AM
> To: dev@tomee.apache.org
> Subject: Re: Site and "documentation" usage
>
> very close http://people.apache.org/~rmannibucau/ivan/ can be used (think
> Ivan did some minor adjustments after but overall idea is here if I'm not
> mistaken)
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog <
> https://blog-rmannibucau.rhcloud.com> | Old Blog <
> http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <
> https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-05 23:03 GMT+02:00 Jonathan Gallimore <
> jonathan.gallim...@gmail.com>
> :
>
> > Ivan - did you have some luck getting that staged somewhere? I'd love
> > to take a look and give some feedback.
> >
> > Cheers
> >
> > Jon
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
>

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

interesting, would be great to have debug log of that clustering part
(something like org.apache.catalina.tribes.level = FINE), think the static
members are actually excluded of the cluster reading this error


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 23:53 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:

> Hmm, why not the tcpfailuredetector as a root (/>) instead of wrapping the
> static membership one?
>
> Done e got this error:
>
> 05-Jul-2017 21:51:32.845 WARNING
> [GroupChannel-Heartbeat[Catalina-Channel]-1]
> sun.reflect.NativeMethodAccessorImpl.invoke Unable to perform heartbeat on
> the TcpFailureDetector.
>  java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.catalina.tribes.membership.MemberImpl.
> hashCode(MemberImpl.java:570)
> at java.util.HashMap.hash(HashMap.java:338)
> at java.util.HashMap.containsKey(HashMap.java:595)
> at
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.
> performBasicCheck(TcpFailureDetector.java:258)
> at
> org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.
> checkMembers(TcpFailureDetector.java:225)
> at
> org.apache.catalina.tribes.group.interceptors.
> TcpFailureDetector.heartbeat(TcpFailureDetector.java:218)
> at
> org.apache.catalina.tribes.group.ChannelInterceptorBase.heartbeat(
> ChannelInterceptorBase.java:100)
> at
> org.apache.catalina.tribes.group.GroupChannel.heartbeat(
> GroupChannel.java:161)
> at
> org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(
> GroupChannel.java:719)
>
>
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
>
> 2017-07-05 18:47 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > Hmm, why not the tcpfailuredetector as a root (/>) instead of wrapping
> the
> > static membership one?
> >
> > Also did you manage to get debug log of tomcat cluster? it helps a lot in
> > general
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-05 23:43 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> >
> > > Did it. No errors found.
> > >
> > > If you want to have a look at the server.xml. Also I've undone the
> > changes
> > > I've made before.
> > >
> > > https://www.dropbox.com/s/p3iknyku2rb3f3w/server.xml?dl=0
> > >
> > >
> > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > Blog: http://eldermoraes.com
> > >
> > >
> > > 2017-07-05 17:08 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > >
> > > > Gmail formatting doesnt help much but think it can miss some closing
> > > tags.
> > > > Autoformat it in an ide, it should show it.
> > > >
> > > > Le 5 juil. 2017 21:28, "Elder Moraes" <elder.mor...@gmail.com> a
> > écrit :
> > > >
> > > > > Actually I can't... :-(
> > > > >
> > > > > But if you could point me where I should look, maybe I can figure
> it
> > > out.
> > > > >
> > > > > Is that code that I've sent here correct? No issue?
> > > > >
> > > > > Did I put the StaticMembershipInterceptor at right place?
> > > > >
> > > > >
> > > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > > Blog: http://eldermoraes.com
> > > > >
> > > > >
> > > > >
> > > > > 2017-07-05 16:21 GMT-03:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > > > >
> > > > > > Do you think you can do a setup without docker? Would be easier
> to
> > > > check
> > > > > > but sounds like a config issue.
> > > > > >
> > > > > > Le 5 juil. 2017 21:18, "Elder Moraes" <elder.mor...@gm

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

Hmm, why not the tcpfailuredetector as a root (/>) instead of wrapping the
static membership one?

Also did you manage to get debug log of tomcat cluster? it helps a lot in
general


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 23:43 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:

> Did it. No errors found.
>
> If you want to have a look at the server.xml. Also I've undone the changes
> I've made before.
>
> https://www.dropbox.com/s/p3iknyku2rb3f3w/server.xml?dl=0
>
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
> 2017-07-05 17:08 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > Gmail formatting doesnt help much but think it can miss some closing
> tags.
> > Autoformat it in an ide, it should show it.
> >
> > Le 5 juil. 2017 21:28, "Elder Moraes" <elder.mor...@gmail.com> a écrit :
> >
> > > Actually I can't... :-(
> > >
> > > But if you could point me where I should look, maybe I can figure it
> out.
> > >
> > > Is that code that I've sent here correct? No issue?
> > >
> > > Did I put the StaticMembershipInterceptor at right place?
> > >
> > >
> > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > Blog: http://eldermoraes.com
> > >
> > >
> > >
> > > 2017-07-05 16:21 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > >
> > > > Do you think you can do a setup without docker? Would be easier to
> > check
> > > > but sounds like a config issue.
> > > >
> > > > Le 5 juil. 2017 21:18, "Elder Moraes" <elder.mor...@gmail.com> a
> > écrit :
> > > >
> > > > > If you are talking about removing the McastService, I've already
> done
> > > and
> > > > > didn't work. The cluster still works as a dynamic one.
> > > > >
> > > > >
> > > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > > Blog: http://eldermoraes.com
> > > > >
> > > > >
> > > > > 2017-07-05 16:08 GMT-03:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > > > >
> > > > > > Think you ask to find node with this service so it behaves as
> > > > configured.
> > > > > > Remove it for static clusters.
> > > > > >
> > > > > > Le 5 juil. 2017 20:43, "Elder Moraes" <elder.mor...@gmail.com> a
> > > > écrit :
> > > > > >
> > > > > > Sorry, I don't get it...
> > > > > >
> > > > > >
> > > > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > > > Blog: http://eldermoraes.com
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2017-07-05 15:38 GMT-03:00 Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >:
> > > > > >
> > > > > > > (disclaimer: read quickly on phone so can be wrong)
> > > > > > >
> > > > > > > seems you use membership discovery, can't it be simply that?
> > > > > > >
> > > > > > > 2017-07-05 20:07 GMT+02:00 Elder Moraes <
> elder.mor...@gmail.com
> > >:
> > > > > > >
> > > > > > > > Sure! Here they are:
> > > > > > > >
> > > > > > > > Name: Catalina:type=Cluster,component=Member,name="tcp://{
> 172,
> > > 17,
> > > > > 0,
> > > > > > > > 3}:4000"
> > > > > > > > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > > > > > > > memberAliveTime: 59124
> > > > > > > > suspect: false
> > > > > > > > udpPort: -1
> > > > > > > > local: false
> > > > > > > > securePort: -1
> > > > > > > > hostname: {172, 17, 0, 3}
> > > > > > > > port: 4000
> > > > > > > > serviceStartTime: 0
> > &g

Re: Site and "documentation" usage

[Romain Manni-Bucau]

yep, the usage of adoc was kind of not random and to prepare an all in one
bundle we can easily add in the current build pipeline.

Thinking to my issue with that "doc" word I start to think we could compute
a small search engine (offline/client only) at build time and just have an
input box on the home page instread of the "writing text" to find a
particular page. Can merge both worlds and solve the navigation issue
making it "legacy" :)




Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 23:25 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Thanks for the link. I would like to specifically encourage Ivan as a new
> contributor to present his changes here, and receive feedback directly from
> the community rather than via a proxy. I think that will enable him to grow
> as a contributor, and hopefully some day, potential committer. I know he's
> not available right now, but hopefully he can do so soon.
>
> I'd also encourage a few days for folks to have a look at it and compare to
> the current site and think it over and comment here. I'd like to sleep on
> it at least, but at an initial glance, I quite like it.
>
> I see myself as a developer, so sometimes for a particular task I'm not
> sure if it falls under 'Admin' or 'Developer'. With this page, I can see it
> all at a glance. Also feels like it could make a nice table of contents for
> a book, which could be an idea if we also wanted to wrap this all up as a
> single PDF.
>
> Jon
>
> On Wed, Jul 5, 2017 at 10:09 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > very close http://people.apache.org/~rmannibucau/ivan/ can be used
> (think
> > Ivan did some minor adjustments after but overall idea is here if I'm not
> > mistaken)
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-05 23:03 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Ivan - did you have some luck getting that staged somewhere? I'd love
> to
> > > take a look and give some feedback.
> > >
> > > Cheers
> > >
> > > Jon
> > >
> > > On Wed, Jul 5, 2017 at 10:01 PM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi guys
> > > >
> > > > With Ivan's work I d like to get your feeling on "Documentation" as
> an
> > > > entry menu.
> > > >
> > > > Personally I feel it weird since almost all is supposed to be doc
> (like
> > > > having "Website") but wonder if it is a language/habit thing or if
> you
> > > > share it too.
> > > >
> > > > Any thoughts?
> > > >
> > >
> >
>

Re: Site and "documentation" usage

[Romain Manni-Bucau]

very close http://people.apache.org/~rmannibucau/ivan/ can be used (think
Ivan did some minor adjustments after but overall idea is here if I'm not
mistaken)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 23:03 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Ivan - did you have some luck getting that staged somewhere? I'd love to
> take a look and give some feedback.
>
> Cheers
>
> Jon
>
> On Wed, Jul 5, 2017 at 10:01 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > Hi guys
> >
> > With Ivan's work I d like to get your feeling on "Documentation" as an
> > entry menu.
> >
> > Personally I feel it weird since almost all is supposed to be doc (like
> > having "Website") but wonder if it is a language/habit thing or if you
> > share it too.
> >
> > Any thoughts?
> >
>

Site and "documentation" usage

[Romain Manni-Bucau]

Hi guys

With Ivan's work I d like to get your feeling on "Documentation" as an
entry menu.

Personally I feel it weird since almost all is supposed to be doc (like
having "Website") but wonder if it is a language/habit thing or if you
share it too.

Any thoughts?

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

Gmail formatting doesnt help much but think it can miss some closing tags.
Autoformat it in an ide, it should show it.

Le 5 juil. 2017 21:28, "Elder Moraes" <elder.mor...@gmail.com> a écrit :

> Actually I can't... :-(
>
> But if you could point me where I should look, maybe I can figure it out.
>
> Is that code that I've sent here correct? No issue?
>
> Did I put the StaticMembershipInterceptor at right place?
>
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
>
> 2017-07-05 16:21 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > Do you think you can do a setup without docker? Would be easier to check
> > but sounds like a config issue.
> >
> > Le 5 juil. 2017 21:18, "Elder Moraes" <elder.mor...@gmail.com> a écrit :
> >
> > > If you are talking about removing the McastService, I've already done
> and
> > > didn't work. The cluster still works as a dynamic one.
> > >
> > >
> > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > Blog: http://eldermoraes.com
> > >
> > >
> > > 2017-07-05 16:08 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > >
> > > > Think you ask to find node with this service so it behaves as
> > configured.
> > > > Remove it for static clusters.
> > > >
> > > > Le 5 juil. 2017 20:43, "Elder Moraes" <elder.mor...@gmail.com> a
> > écrit :
> > > >
> > > > Sorry, I don't get it...
> > > >
> > > >
> > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > Blog: http://eldermoraes.com
> > > >
> > > >
> > > >
> > > > 2017-07-05 15:38 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > > > (disclaimer: read quickly on phone so can be wrong)
> > > > >
> > > > > seems you use membership discovery, can't it be simply that?
> > > > >
> > > > > 2017-07-05 20:07 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> > > > >
> > > > > > Sure! Here they are:
> > > > > >
> > > > > > Name: Catalina:type=Cluster,component=Member,name="tcp://{172,
> 17,
> > > 0,
> > > > > > 3}:4000"
> > > > > > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > > > > > memberAliveTime: 59124
> > > > > > suspect: false
> > > > > > udpPort: -1
> > > > > > local: false
> > > > > > securePort: -1
> > > > > > hostname: {172, 17, 0, 3}
> > > > > > port: 4000
> > > > > > serviceStartTime: 0
> > > > > > ready: true
> > > > > > failing: false
> > > > > > name: tcp://{172, 17, 0, 3}:4000
> > > > > > msgCount: 0
> > > > > >
> > > > > > Name: Catalina:type=Cluster,component=Member,name="tcp://1
> > > > 72.17.0.4:4000
> > > > > "
> > > > > > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > > > > > memberAliveTime: 8094
> > > > > > suspect: false
> > > > > > udpPort: -1
> > > > > > local: true
> > > > > > securePort: -1
> > > > > > hostname: 172.17.0.4
> > > > > > port: 4000
> > > > > > serviceStartTime: 1499277570908
> > > > > > ready: true
> > > > > > failing: false
> > > > > > name: tcp://172.17.0.4:4000
> > > > > > msgCount: 108
> > > > > >
> > > > > > Name: Catalina:type=Cluster,component=Member,name="tcp://{172,
> 17,
> > > 0,
> > > > > > 5}:4000"
> > > > > > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > > > > > memberAliveTime: 52614
> > > > > > suspect: false
> > > > > > udpPort: -1
> > > > > > local: false
> > > > > > securePort: -1
> > > > > > hostname: {172, 17, 0, 5}
> > > > > > port: 4000
> > > > > > serviceStartTime: 0
> > > > > > ready: true
> > > > > > failing: false
> > > > > > name: tcp://{172, 17, 0, 5}:4000
> > > > &g

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

Do you think you can do a setup without docker? Would be easier to check
but sounds like a config issue.

Le 5 juil. 2017 21:18, "Elder Moraes" <elder.mor...@gmail.com> a écrit :

> If you are talking about removing the McastService, I've already done and
> didn't work. The cluster still works as a dynamic one.
>
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
> 2017-07-05 16:08 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > Think you ask to find node with this service so it behaves as configured.
> > Remove it for static clusters.
> >
> > Le 5 juil. 2017 20:43, "Elder Moraes" <elder.mor...@gmail.com> a écrit :
> >
> > Sorry, I don't get it...
> >
> >
> > Twitter: @elderjava <https://twitter.com/elderjava>
> > Blog: http://eldermoraes.com
> >
> >
> >
> > 2017-07-05 15:38 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > (disclaimer: read quickly on phone so can be wrong)
> > >
> > > seems you use membership discovery, can't it be simply that?
> > >
> > > 2017-07-05 20:07 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> > >
> > > > Sure! Here they are:
> > > >
> > > > Name: Catalina:type=Cluster,component=Member,name="tcp://{172, 17,
> 0,
> > > > 3}:4000"
> > > > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > > > memberAliveTime: 59124
> > > > suspect: false
> > > > udpPort: -1
> > > > local: false
> > > > securePort: -1
> > > > hostname: {172, 17, 0, 3}
> > > > port: 4000
> > > > serviceStartTime: 0
> > > > ready: true
> > > > failing: false
> > > > name: tcp://{172, 17, 0, 3}:4000
> > > > msgCount: 0
> > > >
> > > > Name: Catalina:type=Cluster,component=Member,name="tcp://1
> > 72.17.0.4:4000
> > > "
> > > > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > > > memberAliveTime: 8094
> > > > suspect: false
> > > > udpPort: -1
> > > > local: true
> > > > securePort: -1
> > > > hostname: 172.17.0.4
> > > > port: 4000
> > > > serviceStartTime: 1499277570908
> > > > ready: true
> > > > failing: false
> > > > name: tcp://172.17.0.4:4000
> > > > msgCount: 108
> > > >
> > > > Name: Catalina:type=Cluster,component=Member,name="tcp://{172, 17,
> 0,
> > > > 5}:4000"
> > > > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > > > memberAliveTime: 52614
> > > > suspect: false
> > > > udpPort: -1
> > > > local: false
> > > > securePort: -1
> > > > hostname: {172, 17, 0, 5}
> > > > port: 4000
> > > > serviceStartTime: 0
> > > > ready: true
> > > > failing: false
> > > > name: tcp://{172, 17, 0, 5}:4000
> > > > msgCount: 0
> > > >
> > > > Name: Catalina:type=Cluster
> > > > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > > > channelStartOptions: 15
> > > > stateName: STARTED
> > > > channelSendOptions: 8
> > > > domain: Catalina
> > > > clusterName: Catalina
> > > > heartbeatBackgroundEnabled: false
> > > > notifyLifecycleListenerOnFailure: false
> > > > objectName: Catalina:type=Cluster
> > > >
> > > > Name: Catalina:type=Cluster,component=Deployer
> > > > modelerType: org.apache.catalina.mbeans.ClassNameMBean
> > > > watchDir: /tmp/war-listen/
> > > > processDeployFrequency: 2
> > > > tempDir: /tmp/war-temp/
> > > > maxValidTime: 300
> > > > deployDir: /tmp/war-deploy/
> > > > watchEnabled: false
> > > >
> > > >
> > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > Blog: http://eldermoraes.com
> > > >
> > > >
> > > >
> > > > 2017-07-05 13:40 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > > > Hmm, can you have a look into JMX on some tomee instances to check
> > the
> > > > > tomcat cluster config please?
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > &

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

Think you ask to find node with this service so it behaves as configured.
Remove it for static clusters.

Le 5 juil. 2017 20:43, "Elder Moraes" <elder.mor...@gmail.com> a écrit :

Sorry, I don't get it...


Twitter: @elderjava <https://twitter.com/elderjava>
Blog: http://eldermoraes.com



2017-07-05 15:38 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> (disclaimer: read quickly on phone so can be wrong)
>
> seems you use membership discovery, can't it be simply that?
>
> 2017-07-05 20:07 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
>
> > Sure! Here they are:
> >
> > Name: Catalina:type=Cluster,component=Member,name="tcp://{172, 17, 0,
> > 3}:4000"
> > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > memberAliveTime: 59124
> > suspect: false
> > udpPort: -1
> > local: false
> > securePort: -1
> > hostname: {172, 17, 0, 3}
> > port: 4000
> > serviceStartTime: 0
> > ready: true
> > failing: false
> > name: tcp://{172, 17, 0, 3}:4000
> > msgCount: 0
> >
> > Name: Catalina:type=Cluster,component=Member,name="tcp://172.17.0.4:4000
> "
> > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > memberAliveTime: 8094
> > suspect: false
> > udpPort: -1
> > local: true
> > securePort: -1
> > hostname: 172.17.0.4
> > port: 4000
> > serviceStartTime: 1499277570908
> > ready: true
> > failing: false
> > name: tcp://172.17.0.4:4000
> > msgCount: 108
> >
> > Name: Catalina:type=Cluster,component=Member,name="tcp://{172, 17, 0,
> > 5}:4000"
> > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > memberAliveTime: 52614
> > suspect: false
> > udpPort: -1
> > local: false
> > securePort: -1
> > hostname: {172, 17, 0, 5}
> > port: 4000
> > serviceStartTime: 0
> > ready: true
> > failing: false
> > name: tcp://{172, 17, 0, 5}:4000
> > msgCount: 0
> >
> > Name: Catalina:type=Cluster
> > modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> > channelStartOptions: 15
> > stateName: STARTED
> > channelSendOptions: 8
> > domain: Catalina
> > clusterName: Catalina
> > heartbeatBackgroundEnabled: false
> > notifyLifecycleListenerOnFailure: false
> > objectName: Catalina:type=Cluster
> >
> > Name: Catalina:type=Cluster,component=Deployer
> > modelerType: org.apache.catalina.mbeans.ClassNameMBean
> > watchDir: /tmp/war-listen/
> > processDeployFrequency: 2
> > tempDir: /tmp/war-temp/
> > maxValidTime: 300
> > deployDir: /tmp/war-deploy/
> > watchEnabled: false
> >
> >
> > Twitter: @elderjava <https://twitter.com/elderjava>
> > Blog: http://eldermoraes.com
> >
> >
> >
> > 2017-07-05 13:40 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Hmm, can you have a look into JMX on some tomee instances to check the
> > > tomcat cluster config please?
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2017-07-05 18:34 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> > >
> > > > Hi Romain,
> > > >
> > > > Actually my problem is right the opposite (I forget to mention -
> > sorry!):
> > > > I'm trying to use a static discovery, but it is working as a dynamic
> > one.
> > > > In other words, when I run another container (say, host4) it joins
> into
> > > the
> > > > cluster.
> > > >
> > > >
> > > >
> > > > Cheers,
> > > >
> > > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > > Blog: http://eldermoraes.com
> > > >
> > > >
> > > >
> > > > 2017-07-05 12:38 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> > > >
> > > > > Hi Elder,
> > > > >
> > > > > are all the binding address (host)/ports opened between your
> > > containers?
> > > > > (can you telnet between them)
> > >

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

(disclaimer: read quickly on phone so can be wrong)

seems you use membership discovery, can't it be simply that?

2017-07-05 20:07 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:

> Sure! Here they are:
>
> Name: Catalina:type=Cluster,component=Member,name="tcp://{172, 17, 0,
> 3}:4000"
> modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> memberAliveTime: 59124
> suspect: false
> udpPort: -1
> local: false
> securePort: -1
> hostname: {172, 17, 0, 3}
> port: 4000
> serviceStartTime: 0
> ready: true
> failing: false
> name: tcp://{172, 17, 0, 3}:4000
> msgCount: 0
>
> Name: Catalina:type=Cluster,component=Member,name="tcp://172.17.0.4:4000"
> modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> memberAliveTime: 8094
> suspect: false
> udpPort: -1
> local: true
> securePort: -1
> hostname: 172.17.0.4
> port: 4000
> serviceStartTime: 1499277570908
> ready: true
> failing: false
> name: tcp://172.17.0.4:4000
> msgCount: 108
>
> Name: Catalina:type=Cluster,component=Member,name="tcp://{172, 17, 0,
> 5}:4000"
> modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> memberAliveTime: 52614
> suspect: false
> udpPort: -1
> local: false
> securePort: -1
> hostname: {172, 17, 0, 5}
> port: 4000
> serviceStartTime: 0
> ready: true
> failing: false
> name: tcp://{172, 17, 0, 5}:4000
> msgCount: 0
>
> Name: Catalina:type=Cluster
> modelerType: org.apache.tomcat.util.modeler.BaseModelMBean
> channelStartOptions: 15
> stateName: STARTED
> channelSendOptions: 8
> domain: Catalina
> clusterName: Catalina
> heartbeatBackgroundEnabled: false
> notifyLifecycleListenerOnFailure: false
> objectName: Catalina:type=Cluster
>
> Name: Catalina:type=Cluster,component=Deployer
> modelerType: org.apache.catalina.mbeans.ClassNameMBean
> watchDir: /tmp/war-listen/
> processDeployFrequency: 2
> tempDir: /tmp/war-temp/
> maxValidTime: 300
> deployDir: /tmp/war-deploy/
> watchEnabled: false
>
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
>
> 2017-07-05 13:40 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > Hmm, can you have a look into JMX on some tomee instances to check the
> > tomcat cluster config please?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-05 18:34 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> >
> > > Hi Romain,
> > >
> > > Actually my problem is right the opposite (I forget to mention -
> sorry!):
> > > I'm trying to use a static discovery, but it is working as a dynamic
> one.
> > > In other words, when I run another container (say, host4) it joins into
> > the
> > > cluster.
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Twitter: @elderjava <https://twitter.com/elderjava>
> > > Blog: http://eldermoraes.com
> > >
> > >
> > >
> > > 2017-07-05 12:38 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> > >
> > > > Hi Elder,
> > > >
> > > > are all the binding address (host)/ports opened between your
> > containers?
> > > > (can you telnet between them)
> > > > do you use docker-compose to create the cluster (it helps a bit)?
> > > > did you activate the debug log of tomcat clustering? it generally
> helps
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2017-07-05 17:30 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> > > >
> > > > > Hi everyone!
> > > > >
> > > > > Could you help me? I've been struggling to build a cluster using
> > Docker
> > > > and
&

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

Hmm, can you have a look into JMX on some tomee instances to check the
tomcat cluster config please?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 18:34 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:

> Hi Romain,
>
> Actually my problem is right the opposite (I forget to mention - sorry!):
> I'm trying to use a static discovery, but it is working as a dynamic one.
> In other words, when I run another container (say, host4) it joins into the
> cluster.
>
>
>
> Cheers,
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>
>
>
> 2017-07-05 12:38 GMT-03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > Hi Elder,
> >
> > are all the binding address (host)/ports opened between your containers?
> > (can you telnet between them)
> > do you use docker-compose to create the cluster (it helps a bit)?
> > did you activate the debug log of tomcat clustering? it generally helps
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-05 17:30 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:
> >
> > > Hi everyone!
> > >
> > > Could you help me? I've been struggling to build a cluster using Docker
> > and
> > > Tomee based on the static discovery membership.
> > >
> > > Docker image: tomee:8-jre-7.0.3-plume
> > >
> > > Please refer to the "Cluster" node described bellow. Could you point me
> > > what is wrong?
> > >
> > >  > >channelSendOptions="8">
> > >
> > >> >expireSessionsOnShutdown="false"
> > >notifyListenersOnReplication="true"/>
> > >
> > >   
> > >
> > >> > className="org.apache.catalina.tribes.membership.McastService"
> > >   address="228.0.0.4"
> > >   port="45564"
> > >   frequency="500"
> > >   dropTime="3000"/>
> > >> > className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> > > address="auto"
> > > port="4000"
> > > autoBind="100"
> > > selectorTimeout="5000"
> > > maxThreads="6"/>
> > >
> > >> > className="org.apache.catalina.tribes.transport.
> ReplicationTransmitter">
> > >  > > className="org.apache.catalina.tribes.transport.nio.
> > > PooledParallelSender"/>
> > >   
> > >
> > >> > className="org.apache.catalina.tribes.group.interceptors.
> > > TcpFailureDetector">
> > >
> > >  > > className="org.apache.catalina.tribes.group.interceptors.
> > > StaticMembershipInterceptor">
> > > > > className="org.apache.catalina.tribes.membership.StaticMember"
> > >   port="5678"
> > >   securePort="-1"
> > >   host="tomee-soujava1"
> > >   domain="staging-cluster"
> > >
> > > uniqueId="{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}"/>
> > >> > className="org.apache.catalina.tribes.membership.StaticMember"
> > >   port="5678"
> > >   securePort="-1"
> > >   host=&q

Re: Building a Static Discovery Cluster

[Romain Manni-Bucau]

Hi Elder,

are all the binding address (host)/ports opened between your containers?
(can you telnet between them)
do you use docker-compose to create the cluster (it helps a bit)?
did you activate the debug log of tomcat clustering? it generally helps


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 17:30 GMT+02:00 Elder Moraes <elder.mor...@gmail.com>:

> Hi everyone!
>
> Could you help me? I've been struggling to build a cluster using Docker and
> Tomee based on the static discovery membership.
>
> Docker image: tomee:8-jre-7.0.3-plume
>
> Please refer to the "Cluster" node described bellow. Could you point me
> what is wrong?
>
> channelSendOptions="8">
>
>   expireSessionsOnShutdown="false"
>notifyListenersOnReplication="true"/>
>
>   
>
>className="org.apache.catalina.tribes.membership.McastService"
>   address="228.0.0.4"
>   port="45564"
>   frequency="500"
>   dropTime="3000"/>
>className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> address="auto"
> port="4000"
> autoBind="100"
> selectorTimeout="5000"
> maxThreads="6"/>
>
>className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>  className="org.apache.catalina.tribes.transport.nio.
> PooledParallelSender"/>
>   
>
>className="org.apache.catalina.tribes.group.interceptors.
> TcpFailureDetector">
>
>  className="org.apache.catalina.tribes.group.interceptors.
> StaticMembershipInterceptor">
> className="org.apache.catalina.tribes.membership.StaticMember"
>   port="5678"
>   securePort="-1"
>   host="tomee-soujava1"
>   domain="staging-cluster"
>
> uniqueId="{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}"/>
>className="org.apache.catalina.tribes.membership.StaticMember"
>   port="5678"
>   securePort="-1"
>   host="tomee-soujava2"
>   domain="staging-cluster"
>
> uniqueId="{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2}"/>
>className="org.apache.catalina.tribes.membership.StaticMember"
>   port="5678"
>   securePort="-1"
>   host="tomee-soujava3"
>   domain="staging-cluster"
>
> uniqueId="{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3}"/>
>  
>
>   
>className="org.apache.catalina.tribes.group.interceptors.
> MessageDispatchInterceptor"/>
>
>   
>
> filter=""/>
>className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>
>tempDir="/tmp/war-temp/"
> deployDir="/tmp/war-deploy/"
> watchDir="/tmp/war-listen/"
> watchEnabled="false"/>
>
>className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> 
>
>
>
> Best regards,
>
> Elder
>
> Twitter: @elderjava <https://twitter.com/elderjava>
> Blog: http://eldermoraes.com
>

Re: [Discuss] Review-than-commit 3 month trial

[Romain Manni-Bucau]

Hmm, let put it in a raw way: can we skip the asf list on these
discussions? Literally means can be use the way everybody uses for RTC, ie
github PRs *only*. If not I don't see the point to use it since
contributors we got are mainly github/jira and I think it is natural as a
contributor to use these media instead of the list.

Can we somehow merge the github flow with the mailing in a smoother way
than the jira integration - and even make jira optional? If not I'm pretty
sure it doesn't need any more evaluation, if we can then it can be great to
benefit from github well known flow.

To rephrase it to maybe make it even more explicit: it is not about making
our - as committers - work easier but making contributions easier.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 13:23 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> As I see it, while the recent issue with the documentation was probably the
> trigger for discussing RTC on dev@, I think the general idea is actually
> to
> get more discussion going on around features and fixes, and to encourage
> more interaction in the review process. We are struggling as a community in
> that regard. The documentation issue might now be "fixed" by using personal
> html area usage, but I still think RTC is worthy of consideration. We are
> seeing some contributions come in from new contributors and we have an
> opportunity to nurture them through this discussion and review process.
>
> Incidentally, if we trialled RTC and saw improvements, I'd vote to keep it
> after 3 months and not "safely return back". If we don't see improvements,
> I'd be trying to think of some other ideas to try. I think we'd all be open
> to other suggestions as well, but I'm of the view that if we don't try
> something, then potentially nothing will change.
>
> Jon
>
> On Wed, Jul 5, 2017 at 9:25 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > 2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.
> > invalid>:
> >
> > > Romain>>>>@Gurkan: concretely nothing changed factually since we
> > discussed
> > > it and concluded we can't pay the overhead at the moment so why pushing
> > > it?I looked at the commit history from github (
> > https://github.com/apache/
> > > tomee/graphs/contributors). Only some couple of members provide
> > > contributions in last couple of years. We need a more stable/healthy
> > > community to increase the chance of long living the project. You are
> > wrong,
> > > the reason behind the such discussion is not related with prod, website
> > or
> > > project source code. We are looking for some alternative solution (at
> > least
> > > temporarily) because of the mentioned problems. I suspect that this
> type
> > of
> > > conflicts may occur in the future again. I am pushing this for the
> > success
> > > and future of Apache TomEE. I am not a PMC member or committer of TomEE
> > > project, but I just wanted to give my comments as ASF member.
> > >
> >
> > Don't think so Gurkan, the problem was really bound to end user direct
> > impact and we tackled it with the personal html area usage we need to
> > document now.
> >
> >
> > > Regards.Gurkan-
> > >
> > >
> > >
> > >
> > >
> > > On Wednesday, July 5, 2017, 10:13:22 AM GMT+3, Romain Manni-Bucau <
> > > rmannibu...@gmail.com> wrote:
> > >
> > > @Gurkan: concretely nothing changed factually since we discussed it and
> > > concluded we can't pay the overhead at the moment so why pushing it?
> > > Concretely the issue was very particular in term of process cause
> > affecting
> > > almost directly our "prod" versus our project source doesn't and we can
> > > therefore tolerate more latency. And side note (probably some wording
> > issue
> > > but just to make it obvious if not): if it is to go back to the normal
> > > process anyway after then we can gain these 3 months and already work
> as
> > we
> > > and we'll do ;).
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > <http:

Re: TOMEE-1974 - lost commits

[Romain Manni-Bucau]

2017-07-05 12:56 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> I'll recheck whether passing a specific basic authorization header works,
> if it does, I'll close the PR and follow up here. If it doesn't, I'll
> follow up with more specific details.
>
> The code change wasn't made for no reason though, which would suggest that
> it doesn't work in the desired way. There was discussion on it at the time
> and the change was committed. The revert was a "whoops, sorry my script
> messed up and that got reverted by accident when we tried to fix the
> damage", as opposed to based on the merit of the actual functionality
> itself. I'd be grateful if the community could consider re-applying this
> lost patch.
>

Yep, was really a oops - sorry again, was too enthusistic on my bash skills
- but the discussion was still going on IIRC.

Once enhancement which was made related to that feature was to strip the
value from the url when doing the request


>
> Many thanks
>
> Jon
>
> On Wed, Jul 5, 2017 at 11:49 AM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > Hi Jon,
> >
> > did you consider making it working without any code change? it does
> AFAIK.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-05 12:47 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Hi
> > >
> > > A few months back we introduced some functionality to allow the client
> to
> > > authenticate using a basic auth header.
> > > https://issues.apache.org/jira/browse/TOMEE-1974. This was merged, but
> > > subsequently lost when a script was accidentally executed against the
> > wrong
> > > branch, and a git reset --hard HEAD^X issued to revert the mistake -
> see
> > > this thread here:
> > > http://tomee-openejb.979440.n4.nabble.com/Commit-deletion-
> td4680672.html
> > .
> > >
> > > Given that this was previously merged, could we consider putting it
> > back? I
> > > have prepared a PR https://github.com/apache/tomee/pull/85, and will
> run
> > > the full test suite on it to ensure it a) still works, and b) the merge
> > > doesn't break anything.
> > >
> > > Thanks
> > >
> > > Jon
> > >
> >
>

Re: TOMEE-1974 - lost commits

[Romain Manni-Bucau]

Hi Jon,

did you consider making it working without any code change? it does AFAIK.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 12:47 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Hi
>
> A few months back we introduced some functionality to allow the client to
> authenticate using a basic auth header.
> https://issues.apache.org/jira/browse/TOMEE-1974. This was merged, but
> subsequently lost when a script was accidentally executed against the wrong
> branch, and a git reset --hard HEAD^X issued to revert the mistake - see
> this thread here:
> http://tomee-openejb.979440.n4.nabble.com/Commit-deletion-td4680672.html.
>
> Given that this was previously merged, could we consider putting it back? I
> have prepared a PR https://github.com/apache/tomee/pull/85, and will run
> the full test suite on it to ensure it a) still works, and b) the merge
> doesn't break anything.
>
> Thanks
>
> Jon
>

Re: [Discuss] Review-than-commit 3 month trial

[Romain Manni-Bucau]

2017-07-05 10:00 GMT+02:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.invalid>:

> Romain>>>>@Gurkan: concretely nothing changed factually since we discussed
> it and concluded we can't pay the overhead at the moment so why pushing
> it?I looked at the commit history from github (https://github.com/apache/
> tomee/graphs/contributors). Only some couple of members provide
> contributions in last couple of years. We need a more stable/healthy
> community to increase the chance of long living the project. You are wrong,
> the reason behind the such discussion is not related with prod, website or
> project source code. We are looking for some alternative solution (at least
> temporarily) because of the mentioned problems. I suspect that this type of
> conflicts may occur in the future again. I am pushing this for the success
> and future of Apache TomEE. I am not a PMC member or committer of TomEE
> project, but I just wanted to give my comments as ASF member.
>

Don't think so Gurkan, the problem was really bound to end user direct
impact and we tackled it with the personal html area usage we need to
document now.


> Regards.Gurkan-
>
>
>
>
>
> On Wednesday, July 5, 2017, 10:13:22 AM GMT+3, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
> @Gurkan: concretely nothing changed factually since we discussed it and
> concluded we can't pay the overhead at the moment so why pushing it?
> Concretely the issue was very particular in term of process cause affecting
> almost directly our "prod" versus our project source doesn't and we can
> therefore tolerate more latency. And side note (probably some wording issue
> but just to make it obvious if not): if it is to go back to the normal
> process anyway after then we can gain these 3 months and already work as we
> and we'll do ;).
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-05 7:28 GMT+02:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.
> invalid>:
>
> > Hi MarkThis is only for fixing the appeared (very important) problem in
> > the community. So, I don't see what will happen to the project in 3
> months
> > period with RTC process? So, at least 3 months, every commit will be
> > approved by the community via consensus. After that, we can safely return
> > back to the normal process.
> >
> > Thanks.Gurkan
> > On Wednesday, July 5, 2017, 1:15:31 AM GMT+3, Mark Struberg
> > <strub...@yahoo.de.INVALID> wrote:
> >
> > RTC in my experience _only_ works on release branches, but is a total
> > community killer on the mainstream branch (master, dev, whatever you call
> > it).
> >
> > We usually don't have so many concurrent commits on the same topic. There
> > was recently an exceptional case and it got resolved.
> > Thus -1
> >
> > Of course discussions might be done first. But not via PR but via mail.
> > Usually the devs have a good feeling about what is sensible and what not.
> > For some deep change one usually sends a patch first for review. That is
> > nothing we need to enforce - every good programmer will do just that!
> > Otoh there are 99.99% of stuff which you just get done and commit it. And
> > if there is something fishy, then it get's caught via the commit log
> mails
> > anyway.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 03.07.2017 um 10:05 schrieb Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>:
> > >
> > > On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <david.blev...@gmail.com
> >
> > > wrote:
> > >
> > >> There’s a discussion on the private list on this topic, but given the
> > >> recent thread I think it makes sense to move that here.
> > >>
> > >> The vote would be only on this question:
> > >>
> > >>  - Is RTC worth trying for 3 months? (+1,+/-0,-1)
> > >>
> > >> I’ve seen some voices in favor, but do not want to propose a vote
> > >> without a heads-up.  Specifically, even if many people like the idea
> > >> we should talk about how we want to do it.
> > >>
> > >> # Review-than-commit
> > >>
> > >> For those that do not know, Review-than-commit is essentially what
> > >> Github Pull Requests are.  Prior to gi

Re: [Discuss] Review-than-commit 3 month trial

[Romain Manni-Bucau]

@Gurkan: concretely nothing changed factually since we discussed it and
concluded we can't pay the overhead at the moment so why pushing it?
Concretely the issue was very particular in term of process cause affecting
almost directly our "prod" versus our project source doesn't and we can
therefore tolerate more latency. And side note (probably some wording issue
but just to make it obvious if not): if it is to go back to the normal
process anyway after then we can gain these 3 months and already work as we
and we'll do ;).


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-05 7:28 GMT+02:00 Gurkan Erdogdu <gurkanerdo...@yahoo.com.invalid>:

> Hi MarkThis is only for fixing the appeared (very important) problem in
> the community. So, I don't see what will happen to the project in 3 months
> period with RTC process? So, at least 3 months, every commit will be
> approved by the community via consensus. After that, we can safely return
> back to the normal process.
>
> Thanks.Gurkan
> On Wednesday, July 5, 2017, 1:15:31 AM GMT+3, Mark Struberg
> <strub...@yahoo.de.INVALID> wrote:
>
> RTC in my experience _only_ works on release branches, but is a total
> community killer on the mainstream branch (master, dev, whatever you call
> it).
>
> We usually don't have so many concurrent commits on the same topic. There
> was recently an exceptional case and it got resolved.
> Thus -1
>
> Of course discussions might be done first. But not via PR but via mail.
> Usually the devs have a good feeling about what is sensible and what not.
> For some deep change one usually sends a patch first for review. That is
> nothing we need to enforce - every good programmer will do just that!
> Otoh there are 99.99% of stuff which you just get done and commit it. And
> if there is something fishy, then it get's caught via the commit log mails
> anyway.
>
> LieGrue,
> strub
>
>
> > Am 03.07.2017 um 10:05 schrieb Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
> >
> > On Mon, Jul 3, 2017 at 2:04 AM, David Blevins <david.blev...@gmail.com>
> > wrote:
> >
> >> There’s a discussion on the private list on this topic, but given the
> >> recent thread I think it makes sense to move that here.
> >>
> >> The vote would be only on this question:
> >>
> >>  - Is RTC worth trying for 3 months? (+1,+/-0,-1)
> >>
> >> I’ve seen some voices in favor, but do not want to propose a vote
> >> without a heads-up.  Specifically, even if many people like the idea
> >> we should talk about how we want to do it.
> >>
> >> # Review-than-commit
> >>
> >> For those that do not know, Review-than-commit is essentially what
> >> Github Pull Requests are.  Prior to github, Apache describes them as:
> >>
> >> - Commit policy which requires that all changes receive consensus
> >>  approval in order to be committed.
> >>
> >> I think we’ve seen evidence that:
> >>
> >> - Slowing ourselves down can be a good thing.
> >>
> >> - Moving ahead after discussion is a good thing.  Discussion should
> >>  precede even the first commit.
> >>
> >> - More eyes and talk around commits can help documentation efforts.
> >>
> >> - As 3 +1s are required, a one-to-one conversation with no one else
> >>  included is naturally discouraged.
> >>
> >> # Trial basis
> >>
> >> My thought is to go RTC for 3 months as a trial.  After 3 months, no
> >> action means we revert back to our present CTR.  A new vote would be
> >> required to continue RTC in any form, as-was or modified.
> >>
> >
> > Unless its obviously unanimous that everyone dislikes RTC at the end of 3
> > months, I'd suggest we call a vote to decide how to proceed. Not quite
> sure
> > how that fits into +1/0/-1 however, so may be it should be a 3 month
> trial,
> > followed by 2 weeks for review and discussion (during which we'd still be
> > RTC) and then a vote?
> >
> >
> >>
> >> The trial-basis is to acknowledge that we are voting on a guess of
> >> potential benefits.  This allows us to "try before we buy" and the
> >> vote really comes down to if we want to try.  We need not make a
> >> decision based on other peopl

Re: Site NG on github

[Romain Manni-Bucau]

Oh

So it is not a tool but a process. I see. Sounds very tempting to be honest
bit also think we should wait "after summer" to not change all at once.

What do you think?

Le 5 juil. 2017 02:21, "John D. Ament" <johndam...@apache.org> a écrit :

> Romain,
>
> For the site generation, if you want to switch to gitwcsub (and dump the
> SVN repo) its simply a matter of having a job (buildbot or jenkins) that
> will build the commit and push the result to a special branch (most are
> using asf-site).  Since you're already using mvn to generate the site, I
> think all you'd have to do is specify the new repo + branch name.
>
> John
>
>
> On Tue, Jul 4, 2017 at 12:20 PM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > Ok submitted
> > https://git-wip-us.apache.org/repos/asf/tomee-tomee-site-generator.git,
> >
> > @John: do you have more details about gitwcsub, didnt find much except it
> > is the git replacement of svnpubsub? idea would be to sync a generated
> > folder with the remote "content" repo. Very worse case I can add it to
> our
> > generator with a java svn or git client, shouldnt take the night ;)
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-04 17:20 GMT+02:00 John D. Ament <johndam...@apache.org>:
> >
> > > Would be better to request a git repo via https://reporeq.apache.org/
> if
> > > you want a repository.  You may also want to consider using gitwcsub
> > > instead of svnpubsub for the actual generated site.
> > >
> > > John
> > >
> > > On Tue, Jul 4, 2017 at 9:15 AM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Ok, let say if there is no -1 tonight I'll update the ticket to ask
> it
> > -
> > > it
> > > > doesnt hurt worse case so dont think we need to wait much more, in
> > > > particular if we want to work on the website now. Let me know if it
> is
> > a
> > > > concern at any level.
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2017-07-04 15:04 GMT+02:00 Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com>
> > > > :
> > > >
> > > > > As in +1 for moving the project :-)
> > > > >
> > > > > On Tue, Jul 4, 2017 at 2:03 PM, Jonathan Gallimore <
> > > > > jonathan.gallim...@gmail.com> wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Tue, Jul 4, 2017 at 2:02 PM, Ivan Junckes Filho <
> > > > > ivanjunc...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> I think last time I checked github for the website was not up to
> > > date.
> > > > > >>
> > > > > >> On Tue, Jul 4, 2017 at 10:00 AM, Daniel Cunha <
> > > daniels...@apache.org>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Well, TomEE already moved to git, you don't need to use SVN.
> > > > > >> > PR integration already works fine, I saw that with last
> > > Jean-Louis's
> > > > > >> merge.
> > > > > >> >
> > > > > >> > But yes, will be awesome to have it, we can use it like a
> stage
> > > and
> > > > > the
> > > > > >> > process to deploy in prod will be identical.
> > > > > >> >
> > > > > >> > +1 for that.
> > > > > >> >
> > > > > >> > On Tue, Jul 4, 2017 at 9:56 AM, Ivan Junckes Filho <

Re: Site NG on github

[Romain Manni-Bucau]

should have all the needed content now,

mvn compile to generate the site
mvn pre-site to publish it on staging


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-04 19:30 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> *typo: https://git-wip-us.apache.org/repos/asf/tomee-site-generator.git
> is the right one
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-04 18:33 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
>> imported the generator in https://git-wip-us.apache.o
>> rg/repos/asf?p=tomee-tomee-site-generator.git, will push a warning in
>> the svn project for now and we can delete it later
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-07-04 18:20 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>>
>>> Ok submitted https://git-wip-us.apache.org/
>>> repos/asf/tomee-tomee-site-generator.git,
>>>
>>> @John: do you have more details about gitwcsub, didnt find much except
>>> it is the git replacement of svnpubsub? idea would be to sync a generated
>>> folder with the remote "content" repo. Very worse case I can add it to our
>>> generator with a java svn or git client, shouldnt take the night ;)
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> | LinkedIn
>>> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>
>>> 2017-07-04 17:20 GMT+02:00 John D. Ament <johndam...@apache.org>:
>>>
>>>> Would be better to request a git repo via https://reporeq.apache.org/
>>>> if
>>>> you want a repository.  You may also want to consider using gitwcsub
>>>> instead of svnpubsub for the actual generated site.
>>>>
>>>> John
>>>>
>>>> On Tue, Jul 4, 2017 at 9:15 AM Romain Manni-Bucau <
>>>> rmannibu...@gmail.com>
>>>> wrote:
>>>>
>>>> > Ok, let say if there is no -1 tonight I'll update the ticket to ask
>>>> it - it
>>>> > doesnt hurt worse case so dont think we need to wait much more, in
>>>> > particular if we want to work on the website now. Let me know if it
>>>> is a
>>>> > concern at any level.
>>>> >
>>>> >
>>>> > Romain Manni-Bucau
>>>> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>>> > <http://rmannibucau.wordpress.com> | Github <
>>>> > https://github.com/rmannibucau> |
>>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>>> > <https://javaeefactory-rmannibucau.rhcloud.com>
>>>> >
>>>> > 2017-07-04 15:04 GMT+02:00 Jonathan Gallimore <
>>>> > jonathan.gallim...@gmail.com>
>>>> > :
>>>> >
>>>> > > As in +1 for moving the project :-)
>>>> > >
>>>> > > On Tue, Jul 4, 2017 at 2:03 PM, Jonathan Gallimore <
>>>> > > jonathan.gallim...@gmail.com> wrote:
>>>> > >
>>>> > > > +1
>>>> > > >
>>>> > > > On Tue, Jul 4, 2017 at 2:02 PM, Ivan Junckes Filho <
>>>> > > ivanjunc...@gmail.com

Re: Site NG on github

[Romain Manni-Bucau]

*typo: https://git-wip-us.apache.org/repos/asf/tomee-site-generator.git is
the right one


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-04 18:33 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> imported the generator in https://git-wip-us.apache.
> org/repos/asf?p=tomee-tomee-site-generator.git, will push a warning in
> the svn project for now and we can delete it later
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-04 18:20 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
>> Ok submitted https://git-wip-us.apache.org/repos/asf/tomee-tomee-site-gen
>> erator.git,
>>
>> @John: do you have more details about gitwcsub, didnt find much except
>> it is the git replacement of svnpubsub? idea would be to sync a generated
>> folder with the remote "content" repo. Very worse case I can add it to our
>> generator with a java svn or git client, shouldnt take the night ;)
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-07-04 17:20 GMT+02:00 John D. Ament <johndam...@apache.org>:
>>
>>> Would be better to request a git repo via https://reporeq.apache.org/ if
>>> you want a repository.  You may also want to consider using gitwcsub
>>> instead of svnpubsub for the actual generated site.
>>>
>>> John
>>>
>>> On Tue, Jul 4, 2017 at 9:15 AM Romain Manni-Bucau <rmannibu...@gmail.com
>>> >
>>> wrote:
>>>
>>> > Ok, let say if there is no -1 tonight I'll update the ticket to ask it
>>> - it
>>> > doesnt hurt worse case so dont think we need to wait much more, in
>>> > particular if we want to work on the website now. Let me know if it is
>>> a
>>> > concern at any level.
>>> >
>>> >
>>> > Romain Manni-Bucau
>>> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>> > <http://rmannibucau.wordpress.com> | Github <
>>> > https://github.com/rmannibucau> |
>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>> > <https://javaeefactory-rmannibucau.rhcloud.com>
>>> >
>>> > 2017-07-04 15:04 GMT+02:00 Jonathan Gallimore <
>>> > jonathan.gallim...@gmail.com>
>>> > :
>>> >
>>> > > As in +1 for moving the project :-)
>>> > >
>>> > > On Tue, Jul 4, 2017 at 2:03 PM, Jonathan Gallimore <
>>> > > jonathan.gallim...@gmail.com> wrote:
>>> > >
>>> > > > +1
>>> > > >
>>> > > > On Tue, Jul 4, 2017 at 2:02 PM, Ivan Junckes Filho <
>>> > > ivanjunc...@gmail.com>
>>> > > > wrote:
>>> > > >
>>> > > >> I think last time I checked github for the website was not up to
>>> date.
>>> > > >>
>>> > > >> On Tue, Jul 4, 2017 at 10:00 AM, Daniel Cunha <
>>> daniels...@apache.org>
>>> > > >> wrote:
>>> > > >>
>>> > > >> > Well, TomEE already moved to git, you don't need to use SVN.
>>> > > >> > PR integration already works fine, I saw that with last
>>> Jean-Louis's
>>> > > >> merge.
>>> > > >> >
>>> > > >> > But yes, will be awesome to have it, we can use it like a stage
>>> and
>>> > > the
>>> > > >> > process to deploy in prod will be ident

Re: Site NG on github

[Romain Manni-Bucau]

imported the generator in
https://git-wip-us.apache.org/repos/asf?p=tomee-tomee-site-generator.git,
will push a warning in the svn project for now and we can delete it later


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-04 18:20 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> Ok submitted https://git-wip-us.apache.org/repos/asf/tomee-tomee-site-
> generator.git,
>
> @John: do you have more details about gitwcsub, didnt find much except it
> is the git replacement of svnpubsub? idea would be to sync a generated
> folder with the remote "content" repo. Very worse case I can add it to our
> generator with a java svn or git client, shouldnt take the night ;)
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-07-04 17:20 GMT+02:00 John D. Ament <johndam...@apache.org>:
>
>> Would be better to request a git repo via https://reporeq.apache.org/ if
>> you want a repository.  You may also want to consider using gitwcsub
>> instead of svnpubsub for the actual generated site.
>>
>> John
>>
>> On Tue, Jul 4, 2017 at 9:15 AM Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>>
>> > Ok, let say if there is no -1 tonight I'll update the ticket to ask it
>> - it
>> > doesnt hurt worse case so dont think we need to wait much more, in
>> > particular if we want to work on the website now. Let me know if it is a
>> > concern at any level.
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> > <http://rmannibucau.wordpress.com> | Github <
>> > https://github.com/rmannibucau> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> > <https://javaeefactory-rmannibucau.rhcloud.com>
>> >
>> > 2017-07-04 15:04 GMT+02:00 Jonathan Gallimore <
>> > jonathan.gallim...@gmail.com>
>> > :
>> >
>> > > As in +1 for moving the project :-)
>> > >
>> > > On Tue, Jul 4, 2017 at 2:03 PM, Jonathan Gallimore <
>> > > jonathan.gallim...@gmail.com> wrote:
>> > >
>> > > > +1
>> > > >
>> > > > On Tue, Jul 4, 2017 at 2:02 PM, Ivan Junckes Filho <
>> > > ivanjunc...@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> I think last time I checked github for the website was not up to
>> date.
>> > > >>
>> > > >> On Tue, Jul 4, 2017 at 10:00 AM, Daniel Cunha <
>> daniels...@apache.org>
>> > > >> wrote:
>> > > >>
>> > > >> > Well, TomEE already moved to git, you don't need to use SVN.
>> > > >> > PR integration already works fine, I saw that with last
>> Jean-Louis's
>> > > >> merge.
>> > > >> >
>> > > >> > But yes, will be awesome to have it, we can use it like a stage
>> and
>> > > the
>> > > >> > process to deploy in prod will be identical.
>> > > >> >
>> > > >> > +1 for that.
>> > > >> >
>> > > >> > On Tue, Jul 4, 2017 at 9:56 AM, Ivan Junckes Filho <
>> > > >> ivanjunc...@gmail.com>
>> > > >> > wrote:
>> > > >> >
>> > > >> > > This would be great, way better than doing svn patches.
>> > > >> > >
>> > > >> > > +1
>> > > >> > >
>> > > >> > > On Tue, Jul 4, 2017 at 9:54 AM, Romain Manni-Bucau <
>> > > >> > rmannibu...@gmail.com>
>> > > >> > > wrote:
>> > > >> > >
>> > > >> > > > Hi guys,
>> > > >>

Re: Site NG on github

[Romain Manni-Bucau]

Ok submitted
https://git-wip-us.apache.org/repos/asf/tomee-tomee-site-generator.git,

@John: do you have more details about gitwcsub, didnt find much except it
is the git replacement of svnpubsub? idea would be to sync a generated
folder with the remote "content" repo. Very worse case I can add it to our
generator with a java svn or git client, shouldnt take the night ;)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-04 17:20 GMT+02:00 John D. Ament <johndam...@apache.org>:

> Would be better to request a git repo via https://reporeq.apache.org/ if
> you want a repository.  You may also want to consider using gitwcsub
> instead of svnpubsub for the actual generated site.
>
> John
>
> On Tue, Jul 4, 2017 at 9:15 AM Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > Ok, let say if there is no -1 tonight I'll update the ticket to ask it -
> it
> > doesnt hurt worse case so dont think we need to wait much more, in
> > particular if we want to work on the website now. Let me know if it is a
> > concern at any level.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-04 15:04 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > As in +1 for moving the project :-)
> > >
> > > On Tue, Jul 4, 2017 at 2:03 PM, Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > > > +1
> > > >
> > > > On Tue, Jul 4, 2017 at 2:02 PM, Ivan Junckes Filho <
> > > ivanjunc...@gmail.com>
> > > > wrote:
> > > >
> > > >> I think last time I checked github for the website was not up to
> date.
> > > >>
> > > >> On Tue, Jul 4, 2017 at 10:00 AM, Daniel Cunha <
> daniels...@apache.org>
> > > >> wrote:
> > > >>
> > > >> > Well, TomEE already moved to git, you don't need to use SVN.
> > > >> > PR integration already works fine, I saw that with last
> Jean-Louis's
> > > >> merge.
> > > >> >
> > > >> > But yes, will be awesome to have it, we can use it like a stage
> and
> > > the
> > > >> > process to deploy in prod will be identical.
> > > >> >
> > > >> > +1 for that.
> > > >> >
> > > >> > On Tue, Jul 4, 2017 at 9:56 AM, Ivan Junckes Filho <
> > > >> ivanjunc...@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > This would be great, way better than doing svn patches.
> > > >> > >
> > > >> > > +1
> > > >> > >
> > > >> > > On Tue, Jul 4, 2017 at 9:54 AM, Romain Manni-Bucau <
> > > >> > rmannibu...@gmail.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Hi guys,
> > > >> > > >
> > > >> > > > I asked INFRA to proxy our new website project on github but
> it
> > > >> looks
> > > >> > > hard,
> > > >> > > > they propose us to move the project to another git repo.
> > > >> > > >
> > > >> > > > Anyone against it?
> > > >> > > >
> > > >> > > > For reference here is the ticket:
> > > >> > > > https://issues.apache.org/jira/browse/INFRA-14249
> > > >> > > >
> > > >> > > > Concretely we would get a git-asf/site-tomee-ng.git (or
> > > equivalent)
> > > >> and
> > > >> > > > have a github proxy.
> > > >> > > >
> > > >> > > > In term of deployment it would still be the same, ie we copy
> the
> > > >> output
> > > >> > > to
> > > >> > > > content/ of the cms subversion repo or we wire pubsub maven
> > > plugin.
> > > >> > > >
> > > >> > > > Romain Manni-Bucau
> > > >> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > >> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > >> > > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/
> > > >> > > > rmannibucau> |
> > > >> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE
> > > Factory
> > > >> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >> > > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Daniel Cunha
> > > >> > https://twitter.com/dvlc_
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: Site NG on github

[Romain Manni-Bucau]

Ok, let say if there is no -1 tonight I'll update the ticket to ask it - it
doesnt hurt worse case so dont think we need to wait much more, in
particular if we want to work on the website now. Let me know if it is a
concern at any level.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-04 15:04 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> As in +1 for moving the project :-)
>
> On Tue, Jul 4, 2017 at 2:03 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > +1
> >
> > On Tue, Jul 4, 2017 at 2:02 PM, Ivan Junckes Filho <
> ivanjunc...@gmail.com>
> > wrote:
> >
> >> I think last time I checked github for the website was not up to date.
> >>
> >> On Tue, Jul 4, 2017 at 10:00 AM, Daniel Cunha <daniels...@apache.org>
> >> wrote:
> >>
> >> > Well, TomEE already moved to git, you don't need to use SVN.
> >> > PR integration already works fine, I saw that with last Jean-Louis's
> >> merge.
> >> >
> >> > But yes, will be awesome to have it, we can use it like a stage and
> the
> >> > process to deploy in prod will be identical.
> >> >
> >> > +1 for that.
> >> >
> >> > On Tue, Jul 4, 2017 at 9:56 AM, Ivan Junckes Filho <
> >> ivanjunc...@gmail.com>
> >> > wrote:
> >> >
> >> > > This would be great, way better than doing svn patches.
> >> > >
> >> > > +1
> >> > >
> >> > > On Tue, Jul 4, 2017 at 9:54 AM, Romain Manni-Bucau <
> >> > rmannibu...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Hi guys,
> >> > > >
> >> > > > I asked INFRA to proxy our new website project on github but it
> >> looks
> >> > > hard,
> >> > > > they propose us to move the project to another git repo.
> >> > > >
> >> > > > Anyone against it?
> >> > > >
> >> > > > For reference here is the ticket:
> >> > > > https://issues.apache.org/jira/browse/INFRA-14249
> >> > > >
> >> > > > Concretely we would get a git-asf/site-tomee-ng.git (or
> equivalent)
> >> and
> >> > > > have a github proxy.
> >> > > >
> >> > > > In term of deployment it would still be the same, ie we copy the
> >> output
> >> > > to
> >> > > > content/ of the cms subversion repo or we wire pubsub maven
> plugin.
> >> > > >
> >> > > > Romain Manni-Bucau
> >> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >> > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >> > > > rmannibucau> |
> >> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE
> Factory
> >> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Daniel Cunha
> >> > https://twitter.com/dvlc_
> >> >
> >>
> >
> >
>

Site NG on github

[Romain Manni-Bucau]

Hi guys,

I asked INFRA to proxy our new website project on github but it looks hard,
they propose us to move the project to another git repo.

Anyone against it?

For reference here is the ticket:
https://issues.apache.org/jira/browse/INFRA-14249

Concretely we would get a git-asf/site-tomee-ng.git (or equivalent) and
have a github proxy.

In term of deployment it would still be the same, ie we copy the output to
content/ of the cms subversion repo or we wire pubsub maven plugin.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

Re: MDB JMX Control

[Romain Manni-Bucau]

will open a new thread about the github integration of the site "Site NG on
github"


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-04 14:51 GMT+02:00 Daniel Cunha <daniels...@apache.org>:

> Which will be awesome if we discuss that here.
> So, others contributors can put their point of view as well.
>
> If we have a Pull Request for that, we can open a discussion on it. With
> patch file, this is more complicated for some others see the changes. IMHO.
> (talking about website/documentation)
>
> On Tue, Jul 4, 2017 at 9:38 AM, Ivan Junckes Filho <ivanjunc...@gmail.com>
> wrote:
>
> > Btw, Andy is working with me to put it live so everyone can review. Let's
> > do this before applying it.
> >
> > On Tue, Jul 4, 2017 at 9:25 AM, Ivan Junckes Filho <
> ivanjunc...@gmail.com>
> > wrote:
> >
> > > I would love that Romain :)
> > >
> > > On Tue, Jul 4, 2017 at 9:00 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> @Ivan: if Andy is ok and if it helps for you I think he can apply your
> > >> last
> > >> patch which looks good and we can make it live to iterate from it from
> > now
> > >> on.
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > >> <http://rmannibucau.wordpress.com> | Github <
> > >> https://github.com/rmannibucau> |
> > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > >> <https://javaeefactory-rmannibucau.rhcloud.com>
> > >>
> > >> 2017-07-04 13:57 GMT+02:00 Ivan Junckes Filho <ivanjunc...@gmail.com
> >:
> > >>
> > >> > Hello Jon, I would love to help with the documentation for this new
> > >> > feature. I have the website setup in my local so it is not hard to
> > write
> > >> > it.
> > >> >
> > >> > I will just need some time as too many things are going on at the
> > >> moment.
> > >> >
> > >> > Ivan
> > >> >
> > >> > On Tue, Jul 4, 2017 at 8:46 AM, Jonathan Gallimore <
> > >> > jonathan.gallim...@gmail.com> wrote:
> > >> >
> > >> > > This has been open for a while. I will push the docs for it, but
> in
> > >> the
> > >> > > meantime, please let me know if there are any blockers to merge.
> > I'll
> > >> > merge
> > >> > > it in the next day or so unless there is specific blocking
> feedback.
> > >> > >
> > >> > > Many thanks.
> > >> > >
> > >> > > Jon
> > >> > >
> > >> > > On Mon, Jul 3, 2017 at 2:48 PM, Jonathan Gallimore <
> > >> > > jonathan.gallim...@gmail.com> wrote:
> > >> > >
> > >> > > > Thanks for the feedback Jonathan! Let me see if I can make some
> > >> > > > improvements there. Point taken on the example - it shouldn't be
> > an
> > >> > issue
> > >> > > > to add something like that. I can do that, or if someone out
> there
> > >> is
> > >> > > > interested in contributing, let me know and I'll hook you up so
> > you
> > >> can
> > >> > > add
> > >> > > > it.
> > >> > > >
> > >> > > > I'd love to hear from a few more people. I'm conscious that MDBs
> > and
> > >> > > > connectors might not be a very much understood part of Java EE.
> So
> > >> even
> > >> > > if
> > >> > > > you have no idea what this thread is about, or you're curious
> > about
> > >> how
> > >> > > to
> > >> > > > do certain things with JMS with TomEE, like switch JMS provider,
> > or
> > >> add
> > >> > > > other connectors, or even build your own connector, please do
> ask
> > a
> > >> > > > question either here or on a new thread if that's more suitable
> > and
> > >> > I'll
> > >> > > > try and answer questions and crank out some documentation for
> > >> review.
> > >> > > >
> > >> > > > Jon
> > >> > > >
> > >> > > > On Thu, Jun 29, 2017 at 10:31 PM, exabrial12 <
> exabr...@gmail.com>
> > >> > wrote:
> > >> > > >
> > >> > > >> +1 Looks good to me.
> > >> > > >>
> > >> > > >> As always, docs speak a million words. Something like
> > >> > > >> http://tomee.apache.org/examples-trunk/simple-mdb/README.html
> > >> would
> > >> > be
> > >> > > >> helpful!
> > >> > > >>
> > >> > > >> The most important part is to always document your decision
> > >> process,
> > >> > > >> through
> > >> > > >> logging, comments, or docs. The vast majority of the time, it's
> > not
> > >> > > >> obvious
> > >> > > >> through one's source code.
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> > > >> --
> > >> > > >> View this message in context: http://tomee-openejb.979440.n4
> > >> > > >> .nabble.com/MDB-JMX-Control-tp4681962p4681994.html
> > >> > > >> Sent from the TomEE Dev mailing list archive at Nabble.com.
> > >> > > >>
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
>
>
> --
> Daniel Cunha
> https://twitter.com/dvlc_
>

Re: AutoConfig - IllegalArgumentException: Comparison method violates its general contract!

[Romain Manni-Bucau]

+1, the indexOf was supposed to be done on getResourceIds(appResources,
type, required) not the copy (which is sorted)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-04 9:38 GMT+02:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com>:

> Hi,
>
> I found a nasty bug in AutoConfig:2077. The comparator does not work
> correctly with java 8.
> In older java versions (older than 8), Collections.sort() always creates an
> array from the list content, while starting with java 8 -> it delegates to
> the sort() method implemented in the concrete list implementation.  The
> implementation of ArrayList, works directly on the inner array, which
> violates the assumption of the current comparator that the arraylist'
> sbacking array is not modified in real time.
>
> I'll create a jira bug shortly and attach a reproducible test case.
>
> Kind regards,
> Svetlin
>

Re: Building Github PR with Buildbot

[Romain Manni-Bucau]

yes, mentionned in another thread that PR usage need to probably move to
jenkins of travis to have that. In any case (if we want to maintain
buildbot too) we need to ask infra since they are the ones owning that part
until we use travis.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-03 15:32 GMT+02:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>:

> Is anyone aware of the apache configuration to get buildbot to build our
> Github PRs?
>
> Not sure it's working or even configured at the moment.
> I've see this https://github.com/Kami/node-buildbot-github
> and a couple of other Apache blog postes.
>
> Would be very helpful.
>
> JLouis
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

Re: 7.0.4 release plans

[Romain Manni-Bucau]

Yes, will be released soon normally

Le 3 juil. 2017 14:35, "Svetlin Zarev" <svetlin.angelov.za...@gmail.com> a
écrit :

> I think there is one more dependency that needs to be checked -
> OpenWebBeans is with a snapshot version, which makes the build not
> reproducible.
>
> 2017-07-03 15:11 GMT+03:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > Hi Svetlin,
> >
> > as soon as this cglib issue is fixed/merged and we reviewed the
> dependency
> > stack (no other "leak") we can release IMO. Build was fixed last week so
> we
> > are all good.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-07-03 14:09 GMT+02:00 Svetlin Zarev <svetlin.angelov.zarev@gmail.
> com
> > >:
> >
> > > Hi,
> > >
> > > Are there any plans for releasing 7.0.4 ? It has quite a lot of
> important
> > > fixes and it would be great to have them GA. Also tomcat in 7.0.3 is
> > quite
> > > old (8.5.11) and there have been several security fixes in tomcat since
> > > then [1][2].
> > >
> > >
> > > [1] https://tomcat.apache.org/security-8.html#Fixed_in_
> > > Apache_Tomcat_8.5.13
> > > [2] https://tomcat.apache.org/security-8.html#Fixed_in_
> > > Apache_Tomcat_8.5.15
> > >
> > > Kind regards,
> > > Svetlin
> > >
> >
>

Re: 7.0.4 release plans

[Romain Manni-Bucau]

Hi Svetlin,

as soon as this cglib issue is fixed/merged and we reviewed the dependency
stack (no other "leak") we can release IMO. Build was fixed last week so we
are all good.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-03 14:09 GMT+02:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com>:

> Hi,
>
> Are there any plans for releasing 7.0.4 ? It has quite a lot of important
> fixes and it would be great to have them GA. Also tomcat in 7.0.3 is quite
> old (8.5.11) and there have been several security fixes in tomcat since
> then [1][2].
>
>
> [1] https://tomcat.apache.org/security-8.html#Fixed_in_
> Apache_Tomcat_8.5.13
> [2] https://tomcat.apache.org/security-8.html#Fixed_in_
> Apache_Tomcat_8.5.15
>
> Kind regards,
> Svetlin
>

Re: Removing ANT from the packaged tomee distributions

[Romain Manni-Bucau]

+1 to merge the PR short term to avoid this dep issue (originally issue
came from the JVM support of the default old cglib transitive dep of rmock)

long term +1 to drop mock usage on
https://github.com/apache/tomee/blob/8fc8d8011c5155e7f47ebc162cb88124bf4ca06e/server/openejb-ejbd/src/test/java/org/apache/openejb/server/ejbd/BasicClusterableRequestHandlerTest.java
- i don't see what mocks brings except potentially a false positive test


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-03 14:01 GMT+02:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com>:

> Thanks!
>
> Some additional info:
> * cglib and its dependencies(ant, asm) were added to openejb-ejbd and hence
> into tomee
> * openejb-ejbd does not have imports to cglib classes
> * without csglib a single test fail because of ClassNotFound in RMock
>
> So as Romain suggested it seems to be a missed "test" scope.
> Here is the PR: https://github.com/apache/tomee/pull/82
>
> Bets regards,
> Svetlin
>
>
>
> 2017-07-03 14:09 GMT+03:00 Jean-Louis Monteiro <jlmonte...@tomitribe.com>:
>
> > If not needed I'm totally ok.
> > Can you submit a PR?
> > I'dbe happy to merge it for you
> >
> >
> > Le 3 juil. 2017 11:45, "Svetlin Zarev" <svetlin.angelov.za...@gmail.com>
> a
> > écrit :
> >
> > > Hi everyone!
> > >
> > > Recently CGLIB was added as a dependency to TomEE (commit id:
> 703e9770),
> > > and in turn it brought Apache Ant as "compile" dependency. Yet it's not
> > > used by cglib at runtime, so it shouldn't really be packaged in the
> final
> > > assembly.
> > >
> > > What do you think about excluding it from the packaged TomEE
> > distributions
> > > ?
> > >
> > > Kind regards,
> > > Svetlin
> > >
> >
>

Re: Removing ANT from the packaged tomee distributions

[Romain Manni-Bucau]

Hi Svetlin,

would need to check the dependency tree but cglib can miss a
test. We shouldnt have cglib at runtime at all


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-03 11:44 GMT+02:00 Svetlin Zarev <svetlin.angelov.za...@gmail.com>:

> Hi everyone!
>
> Recently CGLIB was added as a dependency to TomEE (commit id: 703e9770),
> and in turn it brought Apache Ant as "compile" dependency. Yet it's not
> used by cglib at runtime, so it shouldn't really be packaged in the final
> assembly.
>
> What do you think about excluding it from the packaged TomEE distributions
> ?
>
> Kind regards,
> Svetlin
>

Re: [Discuss] Review-than-commit 3 month trial

[Romain Manni-Bucau]

I'm +1 to enhance our github support, it is really a favorable contribution
solution but for the process itself I don't see what changed so I'm still
-1 for the reasons mentionned when we discussed it.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-07-03 3:04 GMT+02:00 David Blevins <david.blev...@gmail.com>:

> There’s a discussion on the private list on this topic, but given the
> recent thread I think it makes sense to move that here.
>
> The vote would be only on this question:
>
>   - Is RTC worth trying for 3 months? (+1,+/-0,-1)
>
> I’ve seen some voices in favor, but do not want to propose a vote
> without a heads-up.  Specifically, even if many people like the idea
> we should talk about how we want to do it.
>
> # Review-than-commit
>
> For those that do not know, Review-than-commit is essentially what
> Github Pull Requests are.  Prior to github, Apache describes them as:
>
>  - Commit policy which requires that all changes receive consensus
>approval in order to be committed.
>
> I think we’ve seen evidence that:
>
>  - Slowing ourselves down can be a good thing.
>
>  - Moving ahead after discussion is a good thing.  Discussion should
>precede even the first commit.
>
>  - More eyes and talk around commits can help documentation efforts.
>
>  - As 3 +1s are required, a one-to-one conversation with no one else
>included is naturally discouraged.
>
> # Trial basis
>
> My thought is to go RTC for 3 months as a trial.  After 3 months, no
> action means we revert back to our present CTR.  A new vote would be
> required to continue RTC in any form, as-was or modified.
>
> The trial-basis is to acknowledge that we are voting on a guess of
> potential benefits.  This allows us to "try before we buy" and the
> vote really comes down to if we want to try.  We need not make a
> decision based on other people's experience and have a means to gain
> our own experience with a built-in escape clause that triggers lazily.
>
> RTC may sound like a good idea, but our implemention of it may be bad
> in practise.  It may sound like a bad idea, but we may discover
> positives we hadn't anticipated.  We don't currently know.
>
> # How would we do it?
>
> Some things that would be good to discuss:
>
>   - How could we use github pull requests?  Other communities do use
> them and I suspect there are options we have not explored.
>
>   - Should all reviews be on the dev list? With Github PRs comments
> and JIRA comments, there needs to be a source of truth.
>
>   - Should we fully document the process before we try so we can get
> the most value from a 3 month trial?
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

Re: Learning from this week

[Romain Manni-Bucau]

We already got this discussion on the thread you mentionned David and think
we ended up by recognizing some errors but only good wills from all parties.

We also got from that some process enhancements I think we would need to
write down when any of us would have time.

So not sure we need another thread about it. Let's get back on actual work
and try to lock the process yo avoid these ambiguities again.

Le 1 juil. 2017 23:52, "David Blevins" <david.blev...@gmail.com> a écrit :

> I think it would be fair to give Andy and Romain the first responses.
>
>  - Andy, do you see anything you may have said or did in your exchange
> with Romain that you feel is not the Apache way?
>
>  - Romain, do you see anything you may have said or did in your exchange
> with Andy that you feel is not the Apache way?
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Jul 1, 2017, at 1:53 PM, David Blevins <david.blev...@gmail.com>
> wrote:
> >
> > I’ve gone through the commit@ and dev@ archives to piece together
> exactly what happened on the 27th.
> >
> > This type of conflict is disappointing and not the Apache Way.  We need
> to shine a spotlight on and learn from these types of exchanges.
> >
> > We have some homework to do.  Everyone read this exchange in detail and
> with an analytical mind:
> >
> > - Look for and label the mistakes made
> > - Focus on the behavior and not the people
> > - Sleep on it, review your list, then post
> > - Do not +1 people’s lists, post your own
> >
> > We will then have an open discussion on what is wrong with this
> exchange.  To my analysis I see 7 distinct issues in the exchange.
> >
> >
> >Jun 27, 21:34
> >AG> svn commit: r1800091
> >
> >Jun 27, 21:41
> >RM> svn commit: r1800092 (revert)
> >
> >Jun 27, 21:41
> >[dev@ list] (Fwd: svn commit: r1800091)
> >RM> Please don't publish this, it breaks existing links which is
> >pby sthg we don't want to do now. Pinged Ivan about it
> >
> >Jun 27, 21:51
> >AG> svn commit: r1800093
> >
> >Jun 27, 21:56
> >RM> svn commit: r1800094 (revert)
> >
> >Jun 27, 22:56
> >[dev@ list] (Re: TomEE Documentation)
> >RM> PS - cause it appeared unobvious on jira: we should try to
> >keep current bookmarks as much as possible cause users already
> >complained we changed them and it is now "done" (= we dont get
> >complains anymore or very rarely) so i don't feel comfortable
> >breaking it again
> >
> >Jun 27, 22:12
> >[Commented] (TOMEE-2078)
> >AG> Romain Manni-Bucau did you seriously just overwrite my commit?
> >
> >Jun 27, 22:13
> >[Commented] (TOMEE-2078)
> >RM> yep, sent a mail on the list explaining why we can't accept
> >this patch as that when you committed (forwarding the commit mail
> >to dev@) + second commit pushed build temp files (target/) which
> >shouldnt be.
> >
> >Jun 27, 22:17
> >AG> svn commit: r1800095
> >
> >Jun 27, 22:18
> >[Commented] (TOMEE-2078)
> >AG> You are simply unbelievable.
> >
> >Jun 27, 22:19
> >[Commented] (TOMEE-2078)
> >AG> This ticket is in progress, and I was working on it. How dare
> >you!
> >
> >Jun 27, 22:20
> >[Commented] (TOMEE-2078)
> >AG> What do you think the staging is for?
> >
> >Jun 27, 22:20
> >[Commented] (TOMEE-2078)
> >RM> ...did you notice you broke bookmarks and messed up the repo?
> >dont think it is being unbelievable to fix it. Also pushing a
> >patch without reviewing it is not good too.
> >
> >Jun 27, 22:21
> >[Commented] (TOMEE-2078)
> >AG> On what planet is this acceptable?
> >
> >Jun 27, 22:21
> >[Commented] (TOMEE-2078)
> >AG> You are arrogant beyond belief!
> >
> >Jun 27, 22:22
> >[Commented] (TOMEE-2078)
> >RM> probably the same planet where ignoring a list dicussion which
> >is not finished (website structure) is acceptable :D
> >
> >Jun 27, 22:22
> >RM> svn commit: r1800097 (revert)
> >
> >Jun 27, 22:27
> >[Commented] (TOMEE-2078)
> >AG> No Romain. This ticket was flagged, and with your usual
> >arrogance you just trash other peoples work. I was in the process
> >of reviewing it. Pushing to stage is perfectly valid. This is
> >simply not acceptable.
> >
> >Jun 27, 22:27
> >[Commented] (TOMEE-2078)
> >AG> I will be escalating this incident.
> >
> >Jun 27, 22:29
> >[Commented] (TOMEE-2078)
> >AG> Thanks Ivan - This is a nice improvement
> >
> > This went on for a while and then spilled over to this thread:
> >
> >"Suffocating development environment"
> >https://lists.apache.org/thread.html/1306bfc0bb78ef47517db6e3866bb7
> 50a72458796f9895545dc39cd6@%3Cdev.tomee.apache.org%3E
> >
> >
> >
> > --
> > David Blevins
> > http://twitter.com/dblevins
> > http://www.tomitribe.com
> >
>
>

Re: [DISCUSS] 1.x EOL

[Romain Manni-Bucau]

As mentionned tomcat 8.0 EOL has been announced, here is the interesting
part of it:

"
The Apache Tomcat team announces that support for Apache Tomcat 8.0.x
will end on 30 June 2018.

This means that after 30 June 2018:
- releases from the 8.0.x branch are highly unlikely
- bugs affecting only the 8.0.x branch will not be addressed
- security vulnerability reports will not be checked against the 8.0.x
  branch

Three months later (i.e. after 30 September 2017)
- the 8.0.x download links will be removed
- the latest 8.0.x release will be removed from the mirror system
- the 8.0.x branch in svn will move from /tomcat/tc8.0.x to
  /tomcat/archive/tc8.0.x
- the links to the 8.0.x documentation will be removed from
  tomcat.apache.org
"

We are already on 8.5 so not directly impacted for 7.x but think we can
take it as a good example for 1.x.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-19 16:14 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

>
>
> 2017-06-19 16:04 GMT+02:00 Jonathan Gallimore <
> jonathan.gallim...@gmail.com>:
>
>> Firstly, I note the page Romain started - thank you for listening to my
>> feedback. I'd be happy to test instructions and contribute to that page. I
>> suspect some DBCP(2) settings are different so we should call those out.
>> I'll also try and help build it out into a step by step guide.
>>
>
> Hmm, database pool can need there own thread but current doc basically
> says "read the pool doc" cause each time we copied it, we ended up messing
> more than solving in term of user experience so I'm not sure we should do
> this exercise. That said +1 to add a point saying it should be validated.
> Tomcat pool being the default we shouldn't be too much affected in "prod".
>
>
>>
>> Secondly, I have been thinking about the EOL. I personally really dislike
>> the term 'End of life' for an Open Source project / branch. The branch
>> will
>> ultimately live on while there are committers / contributors whether
>> individual or organizations that are prepared to provide patches. The
>> OpenEJB Eclipse Plugin could be thought of as "End Of Life", but if
>> someone
>> showed up on the mailing list wanting to use it with the latest version of
>> Eclipse, and it didn't work (which I expect is the case), or found a bug,
>> truthfully, I would be simply delighted to update it - so in that regard
>> it
>> isn't EOL.
>>
>
> Agree but think not using EOL would be misleading. What we want is to:
>
> 1. show 1.x is not more active
> 2. 1.x is no more maintained (and once again this is not linked to our
> only will in term of OS ecosystem)
> 3. you should migrate to 7
>
> I'm fine detailling it in the announce but not sure if using a more
> accurate term (EOS - end of support ?) wouldn't be more misleading :s
>
>
>>
>> Similarly, if someone / an organization wanted to contribute and maintain
>> 1.7.x, then there shouldn't really be any blocker to them doing so, and
>> therefore it also wouldn't be EOL.
>>
>
> Well the OS side is a blocker. This means 1.x needs to live with a tons of
> fork which should be ack by tomee project before being an option.
>
>
>>
>> I do, however, appreciate that there is a desire for people to migrate to
>> the latest version, as there is more activity there in terms of later
>> specs
>> and new functionality, and I also appreciate the issue where dependencies
>> 1.7.x uses may not be updated any more.
>>
>> I'd like to make the suggestion that we give an honest statement about
>> each
>> version available, in order to help facilitate decision making. As to what
>> "honest statement" means... well I think we'd need to discuss and agree
>> the
>> specific statements. Off the top of my head, it could be something like:
>>
>> Pre-1.7.x: No longer being updated within the community.
>> 1.7.x: Stable, certified, supports Java EE 6 Web Profile. Receives
>> security
>> fixes, occasional feature updates and backports, and bug fixes. Last
>> commit: -MM-dd, last release: -MM-dd. N.B. some dependencies (e.g.
>> ) no longer receive updates. Consider upgrading to 7.0, see the
>> migration guide here: http://tomee.apache.org/
>> 7.x: Stable, GA, supports Java EE 7 Web Profile. Actively developed,
>> receives secur

Re: Backport of TOMEE-1908

[Romain Manni-Bucau]

unsafe is fine (and you don't really have the choice actually)

Wonder if we should add a flag support in the resource adapter
definition/properties to force the use of java proxies (= prevent
subclassing)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-29 1:03 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>:

> Thanks for that. It'll probably come as no surprise to you that the
> resource adapter I am looking at does not have a no-arg constructor for its
> ManagedConnection object (JmsSession). I have attempted to make this work,
> but would appreciate another pair of eyes. I'm specifically curious as to
> whether there is a "better" way. I'm not mad keen on using Unsafe, but will
> note that all our no-interface proxy code uses it, so if we wanted to
> eliminate it, we'd need to work in that area too. I also had a go at
> extending the test to cover this, and would appreciate any thoughts there
> too.
>
> Here's my attempt:
> https://github.com/apache/tomee/pull/80/commits/
> 4e69b3fe8d640445cf90a9a94d8c132e52535939
>
> Thanks
>
> Jon
>
> On Wed, Jun 28, 2017 at 11:02 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> wrote:
>
> > +1, think hazelcast was doing it too at some point (never got why it was
> > often done with a spec making interfaces the first citizen ;))
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-06-29 0:00 GMT+02:00 Jonathan Gallimore <
> jonathan.gallim...@gmail.com
> > >:
> >
> > > Hi
> > >
> > > Does anyone have any objections to this change being backported to
> > > tomee-1.7.x:
> > > https://github.com/apache/tomee/commit/64ca1f3e9f7965d35e7a70a06ae604
> > > 41d026c9a1
> > > ?
> > >
> > > I'm specifically looking to use this resource adapter:
> > > https://github.com/jms-ra/generic-jms-ra/tree/1.x with 1.7.x which
> > > requires
> > > this change as it tries to cast a ManagedConnection object back to the
> > > actual class.
> > >
> > > My specific backport with merge issues and J7 -> J6 issues resolved is
> > here
> > > for review: https://github.com/apache/tomee/pull/80
> > >
> > > The original patch and issue details are here:
> > > https://issues.apache.org/jira/browse/TOMEE-1908
> > >
> > > Thanks,
> > >
> > > Jon
> > >
> >
>

Re: Backport of TOMEE-1908

[Romain Manni-Bucau]

+1, think hazelcast was doing it too at some point (never got why it was
often done with a spec making interfaces the first citizen ;))


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-29 0:00 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>:

> Hi
>
> Does anyone have any objections to this change being backported to
> tomee-1.7.x:
> https://github.com/apache/tomee/commit/64ca1f3e9f7965d35e7a70a06ae604
> 41d026c9a1
> ?
>
> I'm specifically looking to use this resource adapter:
> https://github.com/jms-ra/generic-jms-ra/tree/1.x with 1.7.x which
> requires
> this change as it tries to cast a ManagedConnection object back to the
> actual class.
>
> My specific backport with merge issues and J7 -> J6 issues resolved is here
> for review: https://github.com/apache/tomee/pull/80
>
> The original patch and issue details are here:
> https://issues.apache.org/jira/browse/TOMEE-1908
>
> Thanks,
>
> Jon
>

Re: Suffocating development environment

[Romain Manni-Bucau]

2017-06-28 19:46 GMT+02:00 exabrial12 :

> As one of the people that had a commit reverted, then history hard pushed,
> I
> think it should be a policy that NO git push --hard should ever occur.
> There
> was/is absolutely no justification for such childish behavior.
>

To be more accurate it was on svn and it was a merge so history was not
lost and revert was visible and not hidden.


>
> +1 for Andy speaking up in a polite manner and
> +1 for JG's examples and
> +1 for a keeping the old (non-angular) website around until a new one is
> actually ready and a vote can be called
>
>
Agree..there was one and we agreed to promote the experimental ng website
as the main site. We also kept the old one to not do a big bang (we only
lost the home page link which is using .old IIRC).

Side detail note again to be accurate: this is not an angular website.


>
>
>
>
> --
> View this message in context: http://tomee-openejb.979440.
> n4.nabble.com/Suffocating-development-environment-tp4681969p4681985.html
> Sent from the TomEE Dev mailing list archive at Nabble.com.
>

Re: MDB JMX Control

[Romain Manni-Bucau]

Did you get a "personal" notification somehow? based on your github
account. Wonder what would be the experience of a not asf person (without a
jira account or without subscription to the list).

Once this question is solved I guess you feel coming the "should we
duplicate on github+list the comments?".


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-28 18:07 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> I just saw you comments - thanks! Much appreciated. And yes, looks like
> they came through as comments on the JIRA. That said, I appreciate the
> follow up on this thread, as I'd like to keep the discussion here (I'm
> happy to pick up comments on the PR and bring them back here for full
> visibility).
>
> Jon
>
> On Wed, Jun 28, 2017 at 5:05 PM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > @Jon: commented 2 small things on the PR. More than the fixes itself
> which
> > shouldnt be too hard I'm interested to learn the flow we have when
> > commenting on github. Know jira should have a comment so a mail too but
> on
> > the "submitter" point of view how does it look like?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-06-28 18:02 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Further to this, I have created 2 PRs for further review:
> > >
> > > https://github.com/apache/tomee/pull/78 - 1.7.x
> > > https://github.com/apache/tomee/pull/79 - master
> > >
> > > This hopefully addresses the classloader feedback and also the logging
> > > feedback.
> > >
> > > Any other feedback is gratefully received, and encouraged, from
> > committers,
> > > users and anyone else who might be interested.
> > >
> > > More importantly, if there is something that I can provide that makes
> > > review easier, please do let me know. I'm also happy to explain things
> > > further if anyone is lost.
> > >
> > > Thanks!
> > >
> > > Jon
> > >
> > >
> > > On Wed, Jun 28, 2017 at 1:58 PM, Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > > > A big thank you for your comments Romain and Jonathan. Just working
> on
> > > > incorporating those now. I'll push a PR, so its a little easier to
> > > review.
> > > >
> > > > Jonathan - I note your comments about the control flow - is there
> > > > something I can do help make the review of this easier? I could do a
> > > little
> > > > screencast, or some documentation write up, (or both!) if that would
> be
> > > > helpful?
> > > >
> > > > Thanks!
> > > >
> > > > Jon
> > > >
> > > > On Mon, Jun 26, 2017 at 8:48 PM, exabrial12 <exabr...@gmail.com>
> > wrote:
> > > >
> > > >> I appreciate the logging lines in the patch that allow the user some
> > > >> feedback
> > > >> as to what happens with the controls. I was trying to think of a few
> > > more
> > > >> that might be useful, but the control flow is a bit complicated to
> > > >> understand.
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> View this message in context: http://tomee-openejb.979440.n4
> > > >> .nabble.com/MDB-JMX-Control-tp4681962p4681966.html
> > > >> Sent from the TomEE Dev mailing list archive at Nabble.com.
> > > >>
> > > >
> > > >
> > >
> >
>

Re: MDB JMX Control

[Romain Manni-Bucau]

@Jon: commented 2 small things on the PR. More than the fixes itself which
shouldnt be too hard I'm interested to learn the flow we have when
commenting on github. Know jira should have a comment so a mail too but on
the "submitter" point of view how does it look like?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-28 18:02 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> Further to this, I have created 2 PRs for further review:
>
> https://github.com/apache/tomee/pull/78 - 1.7.x
> https://github.com/apache/tomee/pull/79 - master
>
> This hopefully addresses the classloader feedback and also the logging
> feedback.
>
> Any other feedback is gratefully received, and encouraged, from committers,
> users and anyone else who might be interested.
>
> More importantly, if there is something that I can provide that makes
> review easier, please do let me know. I'm also happy to explain things
> further if anyone is lost.
>
> Thanks!
>
> Jon
>
>
> On Wed, Jun 28, 2017 at 1:58 PM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
> > A big thank you for your comments Romain and Jonathan. Just working on
> > incorporating those now. I'll push a PR, so its a little easier to
> review.
> >
> > Jonathan - I note your comments about the control flow - is there
> > something I can do help make the review of this easier? I could do a
> little
> > screencast, or some documentation write up, (or both!) if that would be
> > helpful?
> >
> > Thanks!
> >
> > Jon
> >
> > On Mon, Jun 26, 2017 at 8:48 PM, exabrial12 <exabr...@gmail.com> wrote:
> >
> >> I appreciate the logging lines in the patch that allow the user some
> >> feedback
> >> as to what happens with the controls. I was trying to think of a few
> more
> >> that might be useful, but the control flow is a bit complicated to
> >> understand.
> >>
> >>
> >>
> >> --
> >> View this message in context: http://tomee-openejb.979440.n4
> >> .nabble.com/MDB-JMX-Control-tp4681962p4681966.html
> >> Sent from the TomEE Dev mailing list archive at Nabble.com.
> >>
> >
> >
>

Re: Suffocating development environment

[Romain Manni-Bucau]

2017-06-28 14:17 GMT+02:00 Andy Gumbrecht <agumbre...@tomitribe.com>:

> The subject of this thread is intended to cover the multiple incidents of
> the past and address the increasing number of current and future concerns
> coming from multiple contributors, that will remain anonymous for obvious
> reasons. I am just being the voice with broad shoulders here.
>
> In this instance there were basically two simple human errors that
> should/would have been resolved in an orderly manner. They only serve as
> the example of how the current climate is, and why we should consider
> changing it for the benefit of the community. The thread topic should still
> be the focus.
>
> 1. The project was checked in missing the target svn ignore and it was
> never subsequently fixed, so the add pulled in target. This was only
> noticed during a commit in action. On attempting to rectify this simple
> mistake less than one minute later someone had already took it upon
> themselves to trash all commits rather than allow the problem to be
> resolved in an orderly fashion either through the ticket in progress or
> email - this came after the effect, i.e too late. Obviously this action led
> to multiple conflicts. Making it virtually impossible to recover.
>
> 2. The deployment to staging has often been used to provide access for
> review purposes in the past, but as Romain rightly points out there are
> risks involved in doing that, and a better way is to use the personal http
> spaces at Apache. The risks were still trivial and could be reverted in a
> matter of minutes if the staging were to be inadvertently published, but
> still agree that the personal space is the right place. That still does not
> warrant trashing someone else's work, ever. The problem should have been
> addressed appropriately. Acting in any other way is always going to inflame
> a situation, every time, without fail. Who likes having their evenings work
> deleted? Having it corrected is generally welcome I would guess.
>
> Both actions and the ensuing assertion in comments that the effort was only
> made in determent to the project, or only for the benefit of a third party
> company, is derogatory and inflammatory. Especially from whence it came and
> the potential conflict of interests involved already. This will again
> always result in a defensive response when it is simply not true. It will
> never result in a submissive response.
>
> Either way, the introduction of a 2 or 3 plus one workflow will completely
> mitigate any future issues like this. No one makes a commit with the
> intention of breaking something. Commits are made every day across the
> world that *do* break something. Everyone needs to understand that, and
> respond appropriately. Especially on an global  OSS project where people
> are dedicating their free time. TomEE is *not* a nuclear bomb that cannot
> be touched for fear of it exploding between stable releases. Version
> control is our saving grace. Community contributors need breathing space to
> grow into the project. Everyone makes mistakes. Mistakes should not be a
> means used to alienate new contributions, only as a tool to guide real
> people with real feelings in the right direction.
>
> To finish off. If work by contributors spans several days, or even weeks,
> then so be it. TomEE is not a full time project for many contributors. Most
> here have a life outside of the box and can only dedicate a limited amount
> of time. This means that it is simply not feasible to expect feature
> complete patches or commits. Incremental work must even be encouraged, as
> every step counts. The impatient must learn to become patient, and not
> trash incremental contributions.
>

This is true and what we agreed on for master sources but think we should
put the limit in term of direct end user impact. The website being directly
exposed it is easy to break them for 10H or more and a quick revert, even
if technically true, is not guaranteed at all. This is also why pubsub
plugin is not automatically wired to the generator. If we agree to use the
personal html area we solve that part - and probably need to create a
committer page on the website btw.

About target I guess Mark is our expert and can fix it very quick?


>
> Andy.
>
> On 28 June 2017 at 12:35, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Wow.
> > >
> > > Well, thanks for writing the email, and starting the discussion. From
> > where
> > > I'm sitting, it looks like there are a few issues. I'll work in
> > reverse-ish
> > > order (in terms of your post).
> > >
>

Re: Suffocating development environment

[Romain Manni-Bucau]

2017-06-28 13:19 GMT+02:00 Jonathan Gallimore <jonathan.gallim...@gmail.com>
:

> On Wed, Jun 28, 2017 at 11:35 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> wrote:
>
> > 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore <
> > jonathan.gallim...@gmail.com>
> > :
> >
> > > Wow.
> > >
> > > Well, thanks for writing the email, and starting the discussion. From
> > where
> > > I'm sitting, it looks like there are a few issues. I'll work in
> > reverse-ish
> > > order (in terms of your post).
> > >
> > > -- Reverting commits.
> > >
> > > I've seen the reverts - I also note that other than on a JIRA ticket,
> > there
> > > was zero conversation on the dev@ list. This isn't the first time that
> > > this
> > > has happened, and in my opinion, is fundamentally wrong. If there is a
> > > genuine need to revert something, you need to post to the dev@ list,
> > call
> > > out the commit, and say why it needs reverting. The person proposing
> the
> > > revert should be prepared to have a should we "roll-back or
> fail-forward"
> > > conversation in the community, and not simply take it upon themselves
> to
> > > make that choice. Folks might be wondering why we need to do this (I
> > think
> > > there is a perception that their mail might not be read, so why bother
> > > posting) - reasons are simple:
> > >
> > > * Encourage discussion and contribution - discuss the specific issues.
> > What
> > > stopped working? Does the committer know what they broke, or what the
> > > reason for proposing a roll-back is
> > > * Co-ordinate - if something breaks in a commit, deciding who's going
> to
> > > help fix what might be better than rolling back
> > > * Educate - is there a process where something in staging becomes live
> > > automatically? Is that what we tried to avoid this time? Is there a
> > better
> > > way to build the site and stage it for peer review?
> > >
> >
> > FYI
> > http://tomee-openejb.979440.n4.nabble.com/Fwd-svn-commit-r18
> > 00091-in-tomee-site-trunk-content-content-admin-content-admi
> > n-cluster-content-admi-td4681967.html
> > was intented to host that discussion (and not pollute jira)
> >
> > Note that it is what happent most of the time, not sure why these dev
> mails
> > are missed.
> >
>
> That's now been pointed out to me twice since I posted this. Actually saw
> and read that post before posting. If you think that constitutes a clear
> discussion, and justifies your actions - sorry, but I'm afraid I could not
> disagree more:
>
> * You replied to commit. Yes that hits the dev@ list, but was the shortest
> possible thing you could have done, and in reality had almost no
> visibility. However, you didn't change the title, so at a glance, its hard
> to distinguish from the commit messages themselves. To answer your question
> - this is most probably why they are missed. Do you really think "Fwd: svn
> commit: r1800091 - in /tomee/site/trunk: content/ content/admin/
> content/admin/cluster/ content/admin/configuration/ content/advanced/
> content/advanced/applicationcomposer/ content/advanced/client/
> content/advanced/jms/ content/advanced/shading/ co..." is a good subject?
> How about "Please don't push these website changes to production". Or
> "[DISCUSS] [REVERT] breaking website change"?
>

Fair enough, noted!


>
> * Your single line message "Please don't publish this, it breaks existing
> links which is pby sthg we don't want to do now. Pinged Ivan about it",
> tells us very little. You make no mention that you intend to revert it, and
> very minimal information on what the issue is. How are we supposed to
> discuss it if we don't know what the issue is? Side note - I don't know how
> well people with less English knowledge get on with the abbreviation of
> "probably something". This is just a suggestion, but I'd avoid the
> abbreviation of those words on your already very short message.
>

Yep, at that time there was an implicit assumption based on the dev thread
which was the patch would be discussed before being applied. Guess I was in
this mind when forwarded the mail/


>
> * You "pinged" Ivan - privately, I assume. I have no visibility of that.
> Why not just post it on dev@ and have the discussion in the open. Maybe
> we'll all learn and improve and collaborate as a result. Maybe we'll appear
> as a more welcoming community. The private conversation is exactly what we
> should 

Re: Suffocating development environment

[Romain Manni-Bucau]

2017-06-28 11:39 GMT+02:00 Jonathan Gallimore 
:

> Wow.
>
> Well, thanks for writing the email, and starting the discussion. From where
> I'm sitting, it looks like there are a few issues. I'll work in reverse-ish
> order (in terms of your post).
>
> -- Reverting commits.
>
> I've seen the reverts - I also note that other than on a JIRA ticket, there
> was zero conversation on the dev@ list. This isn't the first time that
> this
> has happened, and in my opinion, is fundamentally wrong. If there is a
> genuine need to revert something, you need to post to the dev@ list, call
> out the commit, and say why it needs reverting. The person proposing the
> revert should be prepared to have a should we "roll-back or fail-forward"
> conversation in the community, and not simply take it upon themselves to
> make that choice. Folks might be wondering why we need to do this (I think
> there is a perception that their mail might not be read, so why bother
> posting) - reasons are simple:
>
> * Encourage discussion and contribution - discuss the specific issues. What
> stopped working? Does the committer know what they broke, or what the
> reason for proposing a roll-back is
> * Co-ordinate - if something breaks in a commit, deciding who's going to
> help fix what might be better than rolling back
> * Educate - is there a process where something in staging becomes live
> automatically? Is that what we tried to avoid this time? Is there a better
> way to build the site and stage it for peer review?
>

FYI
http://tomee-openejb.979440.n4.nabble.com/Fwd-svn-commit-r1800091-in-tomee-site-trunk-content-content-admin-content-admin-cluster-content-admi-td4681967.html
was intented to host that discussion (and not pollute jira)

Note that it is what happent most of the time, not sure why these dev mails
are missed.


>
> All of the above potential (and that's just off the top of my head, I'm
> sure there is more) was lost by the 'silent revert'. The view the committer
> / contributor has becomes "my stuff was rejected without comment and
> without discussion, why should I bother?" and the damage to community
> starts / continues. In my opinion, simply reverting commits without
> appropriate discussion on dev@ needs to stop, right now. We need to
> nurture
> contributions, not simply reject them.
>
> I saw one point about breaking the build, and the build not being fixed
> quickly enough. Again, I think that needs to be called out and discussed
> how to fix (rollback or fail-forward), as opposed to commits being rejected
> or reverted without discussion. It also needs to be understood and accepted
> that we will need to have that sort of conversation each time it happens.
> Even if a change breaks something, I don't think anyone should have "carte
> blanche" to revert commits without discussion on dev@.
>
> -- Making changes.
>
> So let's talk about the elephant that isn't in the room. Simply put, there
> isn't enough discussion on dev@ and there is virtually no peer review at
> all. Andy, I wasn't aware that you'd be pushing stuff to staging, and so
> those commits, from where I was sitting, came out of the blue. I will note
> that there was some discussion around TomEE documentation, which is great,
> but the commits I saw were so big that I couldn't get a diff of them. I
> will go through and review, but that is going to take some time. At the
> moment, I don't know what the changes were so I can't really comment on the
> specifics. There was no invitation to review or discuss. There was no
> discussion around the process of building a local copy of the website and
> maybe staging it somewhere else to facilitate that review. The
> documentation on contributing to the website and review changes is, I
> suspect, somewhat lacking.
>

raw doc to do an update/submit a patch is
http://svn.apache.org/repos/asf/tomee/site/trunk/generators/site-tomee-ng/README.adoc

then it is just a matter of synching target/site-tomee-ng* with content/ of
the site (pubsub). We can surely setup pubsub mvn plugin to make it
smoother if needed.


>
> You mention that you were mentoring a contributor - you don't mention who,
> but I'm assuming its Ivan Junckes for a bunch of reasons, but mostly
> because of his conversations on the TomEE documentation thread. Please
> correct me if I'm wrong. Anyway, whoever it is, we'd love to see more
> contributions from you. I understand that this negative experience might
> leave a bad taste, but it would be great if you bear with us and please
> carry on - I am very hopeful that we can improve, and in turn, enable you
> to contribute more and help the community grow. We would appreciate your
> feedback to help us do so.
>
> While I saw some patches attached to the JIRA, I think a better process
> would have been to have contributor talk about their patch on dev@, how to
> build it and review,  and what what the changes are. It seems like we're
> relying on JIRA heavily, almost as a 

Re: Suffocating development environment

[Romain Manni-Bucau]

2017-06-28 2:14 GMT+02:00 Andy Gumbrecht :

> I'm writing this on the public dev list as there seems to be inaction on
> the private list regarding the preservation and nurturing of contributions
> to the TomEE project. I hope this serves as an entry into a public
> discussion on how to improve or resolve the situation.
>
> This evening (and late into the night) I was working in my free time
> together with another contributor in an effort to improve the currently
> very poor TomEE website. This work was offsite, and being pushed to staging
> for peer review.
>

We need to be more carefulness with that process because it doesn't work
Andy. We don't have a staging repo so it means if you push to staging and
somebody else push a change intended to the prod site (let say David fixes
a typo or adds an awesome doc on ejbd client for instance) then the staged
changes which are not yet desired would go live.

I don't know if we can get a staging repo linked to the staging site and
but it can be a way to enable what you desired yesterday.

Side note: the evolution of th website makes it trivial to run it locally
for any java/maven user so the staging is less useful IMHO which mitigates
this issue (whereas before the perl/python/bash env was a pain to run with
the right versions etc).

Last point which is nice not applying just to go in staging is to preserve
some history in our SCM otherwise we at least need to tak through the
commit message the commit as ignorable.

Side note: also please make sure to not commit target/ which is a temporary
folder, ensure it is in your svn ignore or we can add it remotely if needed.


>
> It became apparent that another committer deemed it in some way acceptable
> to trash this effort 'during' this work without any collaboration simply
> because they disagree with some of the changes, even when those changes had
> not been finalised. The existence and state of the JIRA ticket was
> completely disregarded by this committer.
>

To make it clear the "other" was me.

However contrarly to what you think it was not a random and happy action.
The risk to trash the prod website was too high and the discussion about
the patch was in progress (days ago on the list and probably concurrently
on the jira).


>
> This is not the first time that a committer has performed such arrogant and
> destructive actions on other peoples contributions to the project. Such
> actions are always extremely disrespectful at a personal level. This is of
> course reflected by the state of the community that currently feels void of
> any participation specifically due to this kind of mobbing. It has become
> virtually impossible for contributors to perform any work on the project
> without almost instant negative, rather than positive or nurturing, input
> at every level (even documentation). I know of several potential
> contributors who have avoided the project due to this currently very
> predictable attitude. It has in fact almost become a joke within other
> communities.
>


Well I'm not sure what you are thinking about but each time I did I sent a
mail or made the commit message obvious about why the change was done.
If you silently disagree you agree



>
> Maybe speaking for others, it is no secret that some committers do not get
> along with others due to these reasons. However, I do value the immense
> contribution by every committer to the TomEE project and understand each
> individuals value and rights to and on the project. This does not mean that
> one individual is the owner of this project (we all are) and has the right
> to overwrite or trash other peoples work in progress, no one should ever
> have that sole right. Well actually we all do, and this seems to be the
> fundamental problem.
>

Once again this is not what happens Andy. Most of the time it imples fixes
or preventing regressions like when some committer upgrades dependencies
versions and breaks TCK...


>
> We desperately need to instigate some measures to prevent the further
> demise of the TomEE community by individuals that seem intent on breaking
> it for reasons that go beyond me (well actually they don't, but that's
> another story). I believe that there was a past discussion on introducing a
> 2 or 3 plus one workflow into the the project, whereby all commits must
> undergo a peer review. This may somewhat stifle rapid development, but on
> the other hand it would ensure that commits are stable and not open to
> trashing by others.
>

I don't think it is related. Main issue is the lack of action when the
build breaks. We maybe don't have the same time notion here but days (to
not say more) without any try to fix the build looks not acceptable to me.


>
> Given that the current JIRA practice is now to commit before creating the
> actual issue (which has been encouraged by the overly aggressive
> environment), the peer review system would also return that process back to
> a normal and acceptable 

Re: TomEE Documentation

[Romain Manni-Bucau]

PS - cause it appeared unobvious on jira: we should try to keep current
bookmarks as much as possible cause users already complained we changed
them and it is now "done" (= we dont get complains anymore or very rarely)
so i don't feel comfortable breaking it again


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-06-26 12:48 GMT+02:00 Ivan Junckes Filho <ivanjunc...@gmail.com>:

> Thanks Romain will work on this.
>
> On Mon, Jun 26, 2017 at 7:45 AM, Romain Manni-Bucau <rmannibu...@gmail.com
> >
> wrote:
>
> > 2017-06-26 12:43 GMT+02:00 Ivan Junckes Filho <ivanjunc...@gmail.com>:
> >
> > > Hi guys, if you agree with Thomas menu I can try to work on the change
> > and
> > > make the "sub-menus" like sections in the page so sub-menus wouldn't be
> > > necessary.
> > >
> > > What do you think Romain?
> > >
> >
> > sub menus are needed to ensure the navigation is smooth and not enforced
> > some pages (reduce the number of *clicks* ;) - hover is fine).
> >
> > +1 to modify the menu while it works on desktop and mobile.
> >
> >
> > >
> > >
> > >
> > > On Mon, Jun 26, 2017 at 7:42 AM, Ivan Junckes Filho <
> > ivanjunc...@gmail.com
> > > >
> > > wrote:
> > >
> > > >
> > > >
> > > > On Mon, Jun 26, 2017 at 2:16 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > > wrote:
> > > >
> > > >> Hmm, interesting. Reworking the website I ensured to avoid JavaEE
> (BTW
> > > JEE
> > > >> doesnt exist anymore ;)) cause it is not important at tomee level. I
> > > mean
> > > >> if tomee covers JavaEE then it reduces mathematically tomee specific
> > > >> features space which is what users search coming on tomee website in
> > > >> general.
> > > >>
> > > >> The classloader point is funny but part of the most hit issue so
> don't
> > > >> know
> > > >> if hiding it a bit would be beneficial. The website has been thought
> > as
> > > an
> > > >> enabler/reference and less like a book with a progression ('getting
> > > >> started"s probably) which is more or less what you propose. Wonder
> if
> > we
> > > >> can merge both somehow, probably with the new menu item.
> > > >>
> > > >> I like your menu but it can need a submenu on doc - not sure how
> > mobile
> > > >> handling would be but doable.
> > > >>
> > > >> Maybe we should drop the blog, we never used it accurately.
> > > >>
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > >> <http://rmannibucau.wordpress.com> | Github <
> > > >> https://github.com/rmannibucau> |
> > > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > > >> <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >>
> > > >> 2017-06-26 0:40 GMT+02:00 Thomas Whitmore
> <twhitmore@bravurasolutions.
> > > com
> > > >> >:
> > > >>
> > > >> > Hi Ivan, Romain,
> > > >> >
> > > >> > I probably support having a 'Documentation' item in the top menu.
> > At
> > > >> the
> > > >> > moment there are all the subtopics, but nothing at the top-level
> > says
> > > >> > Documentation!  At a brief glance this is likely to give the
> > > impression
> > > >> > that there isn't documentation, or that it's hard to find.
> > > >> >
> > > >> > From an external perspective 'Documentation', 'Getting Started'
> and
> > > >> > possibly 'Examples' are good top-level headings.
> > > >> >
> > > >> > I would suggest something like:
> > > >> > - Documentation
> > > >> > - Getting Starting
> > > >> > - Examples
> > &