[GitHub] activemq-artemis pull request #813: More use of try-with-resources

[scop]

GitHub user scop opened a pull request:

https://github.com/apache/activemq-artemis/pull/813

More use of try-with-resources



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scop/activemq-artemis try-with-resources

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/813.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 #813


commit a3f398de4df42aa733696443e810a3c1767f6c1a
Author: Ville Skyttä 
Date:   2016-09-30T06:31:38Z

More use of try-with-resources




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #812: Spelling fixes

[scop]

GitHub user scop opened a pull request:

https://github.com/apache/activemq-artemis/pull/812

Spelling fixes



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scop/activemq-artemis spelling

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/812.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 #812


commit 431e8e3fa358591fd31ccbe3665fa9681e088167
Author: Ville Skyttä 
Date:   2016-09-30T06:23:17Z

Spelling fixes




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: ActiveMQ-Trunk-Deploy #1696

[Apache Jenkins Server]

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on jenkins-test-486 (Ubuntu ubuntu jenkins-cloud-8GB 
jenkins-cloud-4GB cloud-slave) in workspace 

java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1191)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1267)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1741)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1191)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1267)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1741)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1191)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1267)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1741)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)

Re: [DISCUSS] Artemis coding style part 2

[Clebert Suconic]

I will try to get the change before noon EST

On Thursday, September 29, 2016, John D. Ament 
wrote:

> Which timezone?  Do you eat lunch at noon or 1 pm?
>
> John
>
> On Thu, Sep 29, 2016 at 9:39 PM Clebert Suconic  >
> wrote:
>
> > I'm almost done.  Will send a PR tomorrow morning us time.
> >
> > It would help if you guys could avoid merging or committing on master
> until
> > tomorrow lunch time (us time)
> >
> > On Thursday, September 29, 2016, Clebert Suconic <
> > clebert.suco...@gmail.com >
> > wrote:
> >
> > > Yep.. I will make the change.
> > >
> > >
> > > there is no reason it wasn't done before other than.. .oops ;)
> > >
> > > On Thu, Sep 29, 2016 at 5:00 PM, Bennet Schulz  
> > > > wrote:
> > > > I personally prefer the 2nd one, but in my opinion it’s not that
> > > important. Take whatever you want as long as the the whole product
> stays
> > as
> > > good as it already is ;-)
> > > >
> > > >
> > > >> Am 29.09.2016 um 20:41 schrieb Christopher Shannon <
> > > christopher.l.shan...@gmail.com  >:
> > > >>
> > > >> Hey Everyone,
> > > >>
> > > >> Last year we had a discussion on the coding style for Artemis and a
> > > change
> > > >> was made to the opening curly brace.  However, I've been in the code
> > > quite
> > > >> a bit the past couple weeks doing testing (I am starting to look at
> > what
> > > >> needs to be done to help move missing features from 5.x) and I've
> > > noticed a
> > > >> couple of things that still don't match up with the 5.x style.
> > > >>
> > > >> In general I think think we should try and get the style closer to
> 5.x
> > > >> because it will make going back and forth between to two code bases
> > > easier.
> > > >>  The main thing I noticed is the while the opening brace was moved
> the
> > > >> closing curly brace is still on its own line which doesn't match the
> > > style
> > > >> of 5.x. This makes it a bit annoying when working in one project and
> > > then
> > > >> doing work in a different project as suddenly you have to remember
> > where
> > > >> the curly brace is supposed to go.
> > > >>
> > > >> For example:
> > > >>
> > > >> Current format:
> > > >>try {
> > > >>//do something
> > > >> }
> > > >> catch (Exception cause) {
> > > >>
> > > >>  }
> > > >>
> > > >> Proposed format, notice that the catch(Exception) part is on the
> same
> > > line
> > > >> as the closing brace
> > > >>try {
> > > >>//do something
> > > >> } catch (Exception cause) {
> > > >>
> > > >> }
> > > >>
> > > >> Thoughts? My preference would be to adopt entire google style guide
> > but
> > > I
> > > >> think at the least should fix the closing curly brace so it matches
> up
> > > with
> > > >> 5.x.
> > > >
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> > >
> >
> >
> > --
> > Clebert Suconic
> >
>


-- 
Clebert Suconic

Any Interest in this PR?

[Quinn Stevenson]

I’ve had this PR open for a while now, but I haven’t heard anything back.

If the community isn’t interested in this PR, please let me know so I can close 
it.

> On Sep 16, 2016, at 3:09 PM, hqstevenson  wrote:
> 
> GitHub user hqstevenson opened a pull request:
> 
>https://github.com/apache/activemq/pull/198
> 
>AMQ-6428 - Add methods to EmbeddedActiveMQBroker an ActiveMQ client JUnit 
> Rules
> 
> 
> 
> You can merge this pull request into a Git repository by running:
> 
>$ git pull https://github.com/hqstevenson/activemq AMQ-6428
> 
> Alternatively you can review and apply these changes as the patch at:
> 
>https://github.com/apache/activemq/pull/198.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 #198
> 
> 
> commit 343e3738b5cffdd6b95cfa257134108105f714c7
> Author: Quinn Stevenson 
> Date:   2016-09-16T20:59:13Z
> 
>Added methods to EmbeddedActiveMQBroker to send messages, as well as JUnit 
> Rules for ActiveMQ clients
> 
> commit f7b5b901004b90975cb82390684e89df57eaced4
> Author: Quinn Stevenson 
> Date:   2016-09-16T20:59:47Z
> 
>Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/activemq 
> into AMQ-6428
> 
> commit 7be356017eecf37fa9c4884906e4eda06d8a6f19
> Author: Quinn Stevenson 
> Date:   2016-09-16T21:07:13Z
> 
>Added license header to files
> 
> 
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---

Re: [DISCUSS] Removing the Web Console

[John D. Ament]

Just wondering - considering where a number of committers work.  Why not
leverage hawt.io as a new console?

John

On Thu, Sep 29, 2016 at 7:45 PM Jim Gomes  wrote:

> Thanks for getting the discussion going again.  You bring up some
> interesting points.  As stale as the console may be, I still find it
> incredibly useful, and would hope that it will remain until a replacement
> option is available.  I have found moving to Apache Artemis to feel like
> I'm moving backwards because there is no admin console for it.
>
> For those that may view it as a security risk, it is a simple matter to
> disable it.  If it were to be replaced, what would be some potential
> replacements? Could the most vulnerable parts of it be removed while still
> remaining useful?  I mostly use it for knowing what clients are connected,
> how many messages have been sent to destinations, and things like that. I
> can't see how those limited functions would be difficult to keep, nor how
> they could be a security issue.
>
> On Wed, Sep 28, 2016 at 8:18 AM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > First, I know this topic was brought up back in January 2014 and there
> were
> > a lot of discussions about what to do about it  and ultimately nothing
> > happened.  However, it has been nearly 3 years since the last time this
> > subject was brought up and absolutely nothing has changed so I think it
> is
> > time to bring it up again and see what people's current opinions are.
> >
> > The Web Console is extremely out of date and since the last discussions
> on
> > the subject is still completely un-maintained.  It is buggy and has had
> > many security vulnerabilities that keep popping up including several that
> > have been reported over the past year.  In the past 3 years no one has
> > shown any interest in contributing fixes to the console to maintain it.
> > Essentially no work has gone into the console except for security fixes.
> >
> > Also, I know there was talk about moving it into a sub project however I
> > don't think that really solves anything.  The code would just be moved
> to a
> > new location and still be un-maintained and full of potential security
> > vulnerabilities.
> >
> > So my preference would be just to EOL the console and remove it form
> future
> > versions. However, if there are people who really still want to keep it
> > then at the very least I think it should go into a sub project along with
> > some sort of warning that says it is deprecated and to use at your own
> > risk, etc.
> >
> > Thoughts?
> >
>

Re: [DISCUSS] Artemis coding style part 2

[John D. Ament]

Which timezone?  Do you eat lunch at noon or 1 pm?

John

On Thu, Sep 29, 2016 at 9:39 PM Clebert Suconic 
wrote:

> I'm almost done.  Will send a PR tomorrow morning us time.
>
> It would help if you guys could avoid merging or committing on master until
> tomorrow lunch time (us time)
>
> On Thursday, September 29, 2016, Clebert Suconic <
> clebert.suco...@gmail.com>
> wrote:
>
> > Yep.. I will make the change.
> >
> >
> > there is no reason it wasn't done before other than.. .oops ;)
> >
> > On Thu, Sep 29, 2016 at 5:00 PM, Bennet Schulz  > > wrote:
> > > I personally prefer the 2nd one, but in my opinion it’s not that
> > important. Take whatever you want as long as the the whole product stays
> as
> > good as it already is ;-)
> > >
> > >
> > >> Am 29.09.2016 um 20:41 schrieb Christopher Shannon <
> > christopher.l.shan...@gmail.com >:
> > >>
> > >> Hey Everyone,
> > >>
> > >> Last year we had a discussion on the coding style for Artemis and a
> > change
> > >> was made to the opening curly brace.  However, I've been in the code
> > quite
> > >> a bit the past couple weeks doing testing (I am starting to look at
> what
> > >> needs to be done to help move missing features from 5.x) and I've
> > noticed a
> > >> couple of things that still don't match up with the 5.x style.
> > >>
> > >> In general I think think we should try and get the style closer to 5.x
> > >> because it will make going back and forth between to two code bases
> > easier.
> > >>  The main thing I noticed is the while the opening brace was moved the
> > >> closing curly brace is still on its own line which doesn't match the
> > style
> > >> of 5.x. This makes it a bit annoying when working in one project and
> > then
> > >> doing work in a different project as suddenly you have to remember
> where
> > >> the curly brace is supposed to go.
> > >>
> > >> For example:
> > >>
> > >> Current format:
> > >>try {
> > >>//do something
> > >> }
> > >> catch (Exception cause) {
> > >>
> > >>  }
> > >>
> > >> Proposed format, notice that the catch(Exception) part is on the same
> > line
> > >> as the closing brace
> > >>try {
> > >>//do something
> > >> } catch (Exception cause) {
> > >>
> > >> }
> > >>
> > >> Thoughts? My preference would be to adopt entire google style guide
> but
> > I
> > >> think at the least should fix the closing curly brace so it matches up
> > with
> > >> 5.x.
> > >
> >
> >
> >
> > --
> > Clebert Suconic
> >
>
>
> --
> Clebert Suconic
>

Re: [DISCUSS] Artemis coding style part 2

[Clebert Suconic]

I'm almost done.  Will send a PR tomorrow morning us time.

It would help if you guys could avoid merging or committing on master until
tomorrow lunch time (us time)

On Thursday, September 29, 2016, Clebert Suconic 
wrote:

> Yep.. I will make the change.
>
>
> there is no reason it wasn't done before other than.. .oops ;)
>
> On Thu, Sep 29, 2016 at 5:00 PM, Bennet Schulz  > wrote:
> > I personally prefer the 2nd one, but in my opinion it’s not that
> important. Take whatever you want as long as the the whole product stays as
> good as it already is ;-)
> >
> >
> >> Am 29.09.2016 um 20:41 schrieb Christopher Shannon <
> christopher.l.shan...@gmail.com >:
> >>
> >> Hey Everyone,
> >>
> >> Last year we had a discussion on the coding style for Artemis and a
> change
> >> was made to the opening curly brace.  However, I've been in the code
> quite
> >> a bit the past couple weeks doing testing (I am starting to look at what
> >> needs to be done to help move missing features from 5.x) and I've
> noticed a
> >> couple of things that still don't match up with the 5.x style.
> >>
> >> In general I think think we should try and get the style closer to 5.x
> >> because it will make going back and forth between to two code bases
> easier.
> >>  The main thing I noticed is the while the opening brace was moved the
> >> closing curly brace is still on its own line which doesn't match the
> style
> >> of 5.x. This makes it a bit annoying when working in one project and
> then
> >> doing work in a different project as suddenly you have to remember where
> >> the curly brace is supposed to go.
> >>
> >> For example:
> >>
> >> Current format:
> >>try {
> >>//do something
> >> }
> >> catch (Exception cause) {
> >>
> >>  }
> >>
> >> Proposed format, notice that the catch(Exception) part is on the same
> line
> >> as the closing brace
> >>try {
> >>//do something
> >> } catch (Exception cause) {
> >>
> >> }
> >>
> >> Thoughts? My preference would be to adopt entire google style guide but
> I
> >> think at the least should fix the closing curly brace so it matches up
> with
> >> 5.x.
> >
>
>
>
> --
> Clebert Suconic
>


-- 
Clebert Suconic

Re: [DISCUSS] Removing the Web Console

[Clebert Suconic]

> For those that may view it as a security risk, it is a simple matter to 
> disable it

I'm not sure I agree with this..
from my experience most users will just ignore or not read the docs at all..

 the most exploited security breaches I know happened around
documented recommendations. (Like removing the user admin/admin from
your whatever configuration for example). It's a dumb example but I
hope it stress what I mean.

the ones usually bad intentioned (or ill intentioned if you are
British)  will actually read the manual. just what I have seen as a
common pattern.

[GitHub] activemq-artemis pull request #810: ARTEMIS-758 - List/Object message sent b...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/810


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #810: ARTEMIS-758 - List/Object message sent by OpenW...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/810
  
I will merge this now as I will change checkstyle


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Removing the Web Console

[Jim Gomes]

Thanks for getting the discussion going again.  You bring up some
interesting points.  As stale as the console may be, I still find it
incredibly useful, and would hope that it will remain until a replacement
option is available.  I have found moving to Apache Artemis to feel like
I'm moving backwards because there is no admin console for it.

For those that may view it as a security risk, it is a simple matter to
disable it.  If it were to be replaced, what would be some potential
replacements? Could the most vulnerable parts of it be removed while still
remaining useful?  I mostly use it for knowing what clients are connected,
how many messages have been sent to destinations, and things like that. I
can't see how those limited functions would be difficult to keep, nor how
they could be a security issue.

On Wed, Sep 28, 2016 at 8:18 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> First, I know this topic was brought up back in January 2014 and there were
> a lot of discussions about what to do about it  and ultimately nothing
> happened.  However, it has been nearly 3 years since the last time this
> subject was brought up and absolutely nothing has changed so I think it is
> time to bring it up again and see what people's current opinions are.
>
> The Web Console is extremely out of date and since the last discussions on
> the subject is still completely un-maintained.  It is buggy and has had
> many security vulnerabilities that keep popping up including several that
> have been reported over the past year.  In the past 3 years no one has
> shown any interest in contributing fixes to the console to maintain it.
> Essentially no work has gone into the console except for security fixes.
>
> Also, I know there was talk about moving it into a sub project however I
> don't think that really solves anything.  The code would just be moved to a
> new location and still be un-maintained and full of potential security
> vulnerabilities.
>
> So my preference would be just to EOL the console and remove it form future
> versions. However, if there are people who really still want to keep it
> then at the very least I think it should go into a sub project along with
> some sort of warning that says it is deprecated and to use at your own
> risk, etc.
>
> Thoughts?
>

Re: [DISCUSS] Artemis coding style part 2

[Clebert Suconic]

Yep.. I will make the change.


there is no reason it wasn't done before other than.. .oops ;)

On Thu, Sep 29, 2016 at 5:00 PM, Bennet Schulz  wrote:
> I personally prefer the 2nd one, but in my opinion it’s not that important. 
> Take whatever you want as long as the the whole product stays as good as it 
> already is ;-)
>
>
>> Am 29.09.2016 um 20:41 schrieb Christopher Shannon 
>> :
>>
>> Hey Everyone,
>>
>> Last year we had a discussion on the coding style for Artemis and a change
>> was made to the opening curly brace.  However, I've been in the code quite
>> a bit the past couple weeks doing testing (I am starting to look at what
>> needs to be done to help move missing features from 5.x) and I've noticed a
>> couple of things that still don't match up with the 5.x style.
>>
>> In general I think think we should try and get the style closer to 5.x
>> because it will make going back and forth between to two code bases easier.
>>  The main thing I noticed is the while the opening brace was moved the
>> closing curly brace is still on its own line which doesn't match the style
>> of 5.x. This makes it a bit annoying when working in one project and then
>> doing work in a different project as suddenly you have to remember where
>> the curly brace is supposed to go.
>>
>> For example:
>>
>> Current format:
>>try {
>>//do something
>> }
>> catch (Exception cause) {
>>
>>  }
>>
>> Proposed format, notice that the catch(Exception) part is on the same line
>> as the closing brace
>>try {
>>//do something
>> } catch (Exception cause) {
>>
>> }
>>
>> Thoughts? My preference would be to adopt entire google style guide but I
>> think at the least should fix the closing curly brace so it matches up with
>> 5.x.
>



-- 
Clebert Suconic

Re: [DISCUSS] Artemis coding style part 2

[Bennet Schulz]

I personally prefer the 2nd one, but in my opinion it’s not that important. 
Take whatever you want as long as the the whole product stays as good as it 
already is ;-)


> Am 29.09.2016 um 20:41 schrieb Christopher Shannon 
> :
> 
> Hey Everyone,
> 
> Last year we had a discussion on the coding style for Artemis and a change
> was made to the opening curly brace.  However, I've been in the code quite
> a bit the past couple weeks doing testing (I am starting to look at what
> needs to be done to help move missing features from 5.x) and I've noticed a
> couple of things that still don't match up with the 5.x style.
> 
> In general I think think we should try and get the style closer to 5.x
> because it will make going back and forth between to two code bases easier.
>  The main thing I noticed is the while the opening brace was moved the
> closing curly brace is still on its own line which doesn't match the style
> of 5.x. This makes it a bit annoying when working in one project and then
> doing work in a different project as suddenly you have to remember where
> the curly brace is supposed to go.
> 
> For example:
> 
> Current format:
>try {
>//do something
> }
> catch (Exception cause) {
> 
>  }
> 
> Proposed format, notice that the catch(Exception) part is on the same line
> as the closing brace
>try {
>//do something
> } catch (Exception cause) {
> 
> }
> 
> Thoughts? My preference would be to adopt entire google style guide but I
> think at the least should fix the closing curly brace so it matches up with
> 5.x.

Re: [DISCUSS] Artemis coding style part 2

[Timothy Bish]

On 09/29/2016 04:32 PM, Clebert Suconic wrote:

Anyone working on it already?


If not I will do it. (just avoiding duplicating effort)


I'd say go for it, you know the build structure on Artemis better than 
the rest of us so probably more likely to spot any trouble




On Thu, Sep 29, 2016 at 3:37 PM, Timothy Bish  wrote:

On 09/29/2016 03:27 PM, Clebert Suconic wrote:

I tried using that checkstye directly and didn't work right away. it
probably needs update versions or something else.


+1 to just use the google checks... just needs to be worked out.


although I would add:







Those look good, they are actually part of the official Google style guide
requirements if you read the doc




And  the sevntu checkstyle I contributed to sevntu:




 
 




On Thu, Sep 29, 2016 at 3:13 PM, Timothy Bish  wrote:

On 09/29/2016 03:01 PM, Clebert Suconic wrote:

I don't know about other, but to me this is trivial change to me and I
don't mind anyways.  All I really mind is to have a checkstyle in
place, whatever that is :)

What would need to be changed on the checkstyle rules? did you check?


  From the old thread we lazily decided that we should adopt the Google
style
guide which is quite close to the 5.x code as it stands now.  I didn't
look
close enough on the original commit to notice that this was not exactly
what
was done but having been in the code over the past few days it has become
apparent it didn't go as far as I thought it was going to.  It is a bit
irritating trying to bring over code from 5.x as the formatting never
quite
matches and breaks the checkstyle rules.

The Google style formatting rules are here:
https://github.com/google/styleguide all in nice little files that can be
imported into the IDE of your choice.

For checkstyle configuration to use the Google style that is covered in
the
CheckStyle project here:

https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml

Previous thread on this is here for reference:
http://mail-archives.apache.org/mod_mbox/activemq-dev/201508.mbox/browser



On Thu, Sep 29, 2016 at 2:41 PM, Christopher Shannon
 wrote:

Hey Everyone,

Last year we had a discussion on the coding style for Artemis and a
change
was made to the opening curly brace.  However, I've been in the code
quite
a bit the past couple weeks doing testing (I am starting to look at
what
needs to be done to help move missing features from 5.x) and I've
noticed
a
couple of things that still don't match up with the 5.x style.

In general I think think we should try and get the style closer to 5.x
because it will make going back and forth between to two code bases
easier.
 The main thing I noticed is the while the opening brace was moved
the
closing curly brace is still on its own line which doesn't match the
style
of 5.x. This makes it a bit annoying when working in one project and
then
doing work in a different project as suddenly you have to remember
where
the curly brace is supposed to go.

For example:

Current format:
   try {
   //do something
}
catch (Exception cause) {

 }

Proposed format, notice that the catch(Exception) part is on the same
line
as the closing brace
   try {
   //do something
} catch (Exception cause) {

}

Thoughts? My preference would be to adopt entire google style guide but
I
think at the least should fix the closing curly brace so it matches up
with
5.x.




--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/





--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/







--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Artemis coding style part 2

[Clebert Suconic]

Anyone working on it already?


If not I will do it. (just avoiding duplicating effort)

On Thu, Sep 29, 2016 at 3:37 PM, Timothy Bish  wrote:
> On 09/29/2016 03:27 PM, Clebert Suconic wrote:
>>
>> I tried using that checkstye directly and didn't work right away. it
>> probably needs update versions or something else.
>>
>>
>> +1 to just use the google checks... just needs to be worked out.
>>
>>
>> although I would add:
>>
>> 
>> 
>> 
>> 
>
>
> Those look good, they are actually part of the official Google style guide
> requirements if you read the doc
>
>
>>
>>
>> And  the sevntu checkstyle I contributed to sevntu:
>>
>> 
>> 
>> 
>> 
>> 
>> 
>>
>>
>>
>> On Thu, Sep 29, 2016 at 3:13 PM, Timothy Bish  wrote:
>>>
>>> On 09/29/2016 03:01 PM, Clebert Suconic wrote:

 I don't know about other, but to me this is trivial change to me and I
 don't mind anyways.  All I really mind is to have a checkstyle in
 place, whatever that is :)

 What would need to be changed on the checkstyle rules? did you check?
>>>
>>>
>>>  From the old thread we lazily decided that we should adopt the Google
>>> style
>>> guide which is quite close to the 5.x code as it stands now.  I didn't
>>> look
>>> close enough on the original commit to notice that this was not exactly
>>> what
>>> was done but having been in the code over the past few days it has become
>>> apparent it didn't go as far as I thought it was going to.  It is a bit
>>> irritating trying to bring over code from 5.x as the formatting never
>>> quite
>>> matches and breaks the checkstyle rules.
>>>
>>> The Google style formatting rules are here:
>>> https://github.com/google/styleguide all in nice little files that can be
>>> imported into the IDE of your choice.
>>>
>>> For checkstyle configuration to use the Google style that is covered in
>>> the
>>> CheckStyle project here:
>>>
>>> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml
>>>
>>> Previous thread on this is here for reference:
>>> http://mail-archives.apache.org/mod_mbox/activemq-dev/201508.mbox/browser
>>>
>>>
 On Thu, Sep 29, 2016 at 2:41 PM, Christopher Shannon
  wrote:
>
> Hey Everyone,
>
> Last year we had a discussion on the coding style for Artemis and a
> change
> was made to the opening curly brace.  However, I've been in the code
> quite
> a bit the past couple weeks doing testing (I am starting to look at
> what
> needs to be done to help move missing features from 5.x) and I've
> noticed
> a
> couple of things that still don't match up with the 5.x style.
>
> In general I think think we should try and get the style closer to 5.x
> because it will make going back and forth between to two code bases
> easier.
> The main thing I noticed is the while the opening brace was moved
> the
> closing curly brace is still on its own line which doesn't match the
> style
> of 5.x. This makes it a bit annoying when working in one project and
> then
> doing work in a different project as suddenly you have to remember
> where
> the curly brace is supposed to go.
>
> For example:
>
> Current format:
>   try {
>   //do something
>}
>catch (Exception cause) {
>
> }
>
> Proposed format, notice that the catch(Exception) part is on the same
> line
> as the closing brace
>   try {
>   //do something
>} catch (Exception cause) {
>
>}
>
> Thoughts? My preference would be to adopt entire google style guide but
> I
> think at the least should fix the closing curly brace so it matches up
> with
> 5.x.



>>>
>>> --
>>> Tim Bish
>>> twitter: @tabish121
>>> blog: http://timbish.blogspot.com/
>>>
>>
>>
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>



-- 
Clebert Suconic

[GitHub] activemq-artemis pull request #800: POC for CDI Integration in Artemis

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/800


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #800: POC for CDI Integration in Artemis

[clebertsuconic]

Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/800#discussion_r81226383
  
--- Diff: docs/user-manual/en/cdi-integration.md ---
@@ -0,0 +1,32 @@
+# CDI Integration
+
+Apache ActiveMQ Artemis provides a simple CDI integration.  It can either 
use an embedded broker or connect to a remote broker.
+
+## Configuring a connection
+
+Configuration is provided by implementing the `ArtemisClientConfiguration` 
interface.
+
+```java
+public interface ArtemisClientConfiguration {
+   String getHost();
+
+   Integer getPort();
+
+   String getUsername();
+
+   String getPassword();
+
+   String getUrl();
+
+   String getConnectorFactory();
+
+   boolean startEmbeddedBroker();
+
+   boolean isHa();
+
+   boolean hasAuthentication();
+}
+```
+
+There's a default configuration out of the box, if none is specified.  
This will generate an embedded broker.
--- End diff --

@johnament  maybe an example as well?


I am merging this now though


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #811: ARTEMIS-763 Remove the legacy Qpid JMS c...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/811


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis pull request #811: ARTEMIS-763 Remove the legacy Qpid JMS c...

[tabish121]

GitHub user tabish121 opened a pull request:

https://github.com/apache/activemq-artemis/pull/811

ARTEMIS-763  Remove the legacy Qpid JMS client annotations

Removes the append of the destination annotations from the outbound JMS
transformer as the legacy client has be unsupported at Qpid for quite
some time now.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tabish121/activemq-artemis 
amqp-remove-deprecated

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/811.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 #811


commit 67fc49014e85a9e527810dacf4e7a461a183e88a
Author: Timothy Bish 
Date:   2016-09-29T19:37:47Z

ARTEMIS-763  Remove the legacy Qpid JMS client annotations

Removes the append of the destination annotations from the outbound JMS
transformer as the legacy client has be unsupported at Qpid for quite
some time now.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Artemis coding style part 2

[Timothy Bish]

On 09/29/2016 03:27 PM, Clebert Suconic wrote:

I tried using that checkstye directly and didn't work right away. it
probably needs update versions or something else.


+1 to just use the google checks... just needs to be worked out.


although I would add:







Those look good, they are actually part of the official Google style 
guide requirements if you read the doc





And  the sevntu checkstyle I contributed to sevntu:










On Thu, Sep 29, 2016 at 3:13 PM, Timothy Bish  wrote:

On 09/29/2016 03:01 PM, Clebert Suconic wrote:

I don't know about other, but to me this is trivial change to me and I
don't mind anyways.  All I really mind is to have a checkstyle in
place, whatever that is :)

What would need to be changed on the checkstyle rules? did you check?


 From the old thread we lazily decided that we should adopt the Google style
guide which is quite close to the 5.x code as it stands now.  I didn't look
close enough on the original commit to notice that this was not exactly what
was done but having been in the code over the past few days it has become
apparent it didn't go as far as I thought it was going to.  It is a bit
irritating trying to bring over code from 5.x as the formatting never quite
matches and breaks the checkstyle rules.

The Google style formatting rules are here:
https://github.com/google/styleguide all in nice little files that can be
imported into the IDE of your choice.

For checkstyle configuration to use the Google style that is covered in the
CheckStyle project here:
https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml

Previous thread on this is here for reference:
http://mail-archives.apache.org/mod_mbox/activemq-dev/201508.mbox/browser



On Thu, Sep 29, 2016 at 2:41 PM, Christopher Shannon
 wrote:

Hey Everyone,

Last year we had a discussion on the coding style for Artemis and a
change
was made to the opening curly brace.  However, I've been in the code
quite
a bit the past couple weeks doing testing (I am starting to look at what
needs to be done to help move missing features from 5.x) and I've noticed
a
couple of things that still don't match up with the 5.x style.

In general I think think we should try and get the style closer to 5.x
because it will make going back and forth between to two code bases
easier.
The main thing I noticed is the while the opening brace was moved the
closing curly brace is still on its own line which doesn't match the
style
of 5.x. This makes it a bit annoying when working in one project and then
doing work in a different project as suddenly you have to remember where
the curly brace is supposed to go.

For example:

Current format:
  try {
  //do something
   }
   catch (Exception cause) {

}

Proposed format, notice that the catch(Exception) part is on the same
line
as the closing brace
  try {
  //do something
   } catch (Exception cause) {

   }

Thoughts? My preference would be to adopt entire google style guide but I
think at the least should fix the closing curly brace so it matches up
with
5.x.





--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/







--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Artemis coding style part 2

[Christopher Shannon]

+1 for taking the google checkstyle as a baseline and then adding minor
tweaks for whatever we think is necessary.

FYI, from the google checkstyle they just do this for the right curly:








On Thu, Sep 29, 2016 at 3:27 PM, Clebert Suconic 
wrote:

> I tried using that checkstye directly and didn't work right away. it
> probably needs update versions or something else.
>
>
> +1 to just use the google checks... just needs to be worked out.
>
>
> although I would add:
>
> 
> 
> 
> 
>
>
> And  the sevntu checkstyle I contributed to sevntu:
>
> 
> 
> 
>
>
> 
>
>
>
> On Thu, Sep 29, 2016 at 3:13 PM, Timothy Bish  wrote:
> > On 09/29/2016 03:01 PM, Clebert Suconic wrote:
> >>
> >> I don't know about other, but to me this is trivial change to me and I
> >> don't mind anyways.  All I really mind is to have a checkstyle in
> >> place, whatever that is :)
> >>
> >> What would need to be changed on the checkstyle rules? did you check?
> >
> >
> > From the old thread we lazily decided that we should adopt the Google
> style
> > guide which is quite close to the 5.x code as it stands now.  I didn't
> look
> > close enough on the original commit to notice that this was not exactly
> what
> > was done but having been in the code over the past few days it has become
> > apparent it didn't go as far as I thought it was going to.  It is a bit
> > irritating trying to bring over code from 5.x as the formatting never
> quite
> > matches and breaks the checkstyle rules.
> >
> > The Google style formatting rules are here:
> > https://github.com/google/styleguide all in nice little files that can
> be
> > imported into the IDE of your choice.
> >
> > For checkstyle configuration to use the Google style that is covered in
> the
> > CheckStyle project here:
> > https://github.com/checkstyle/checkstyle/blob/master/src/
> main/resources/google_checks.xml
> >
> > Previous thread on this is here for reference:
> > http://mail-archives.apache.org/mod_mbox/activemq-dev/
> 201508.mbox/browser
> >
> >
> >>
> >> On Thu, Sep 29, 2016 at 2:41 PM, Christopher Shannon
> >>  wrote:
> >>>
> >>> Hey Everyone,
> >>>
> >>> Last year we had a discussion on the coding style for Artemis and a
> >>> change
> >>> was made to the opening curly brace.  However, I've been in the code
> >>> quite
> >>> a bit the past couple weeks doing testing (I am starting to look at
> what
> >>> needs to be done to help move missing features from 5.x) and I've
> noticed
> >>> a
> >>> couple of things that still don't match up with the 5.x style.
> >>>
> >>> In general I think think we should try and get the style closer to 5.x
> >>> because it will make going back and forth between to two code bases
> >>> easier.
> >>>The main thing I noticed is the while the opening brace was moved
> the
> >>> closing curly brace is still on its own line which doesn't match the
> >>> style
> >>> of 5.x. This makes it a bit annoying when working in one project and
> then
> >>> doing work in a different project as suddenly you have to remember
> where
> >>> the curly brace is supposed to go.
> >>>
> >>> For example:
> >>>
> >>> Current format:
> >>>  try {
> >>>  //do something
> >>>   }
> >>>   catch (Exception cause) {
> >>>
> >>>}
> >>>
> >>> Proposed format, notice that the catch(Exception) part is on the same
> >>> line
> >>> as the closing brace
> >>>  try {
> >>>  //do something
> >>>   } catch (Exception cause) {
> >>>
> >>>   }
> >>>
> >>> Thoughts? My preference would be to adopt entire google style guide
> but I
> >>> think at the least should fix the closing curly brace so it matches up
> >>> with
> >>> 5.x.
> >>
> >>
> >>
> >
> >
> > --
> > Tim Bish
> > twitter: @tabish121
> > blog: http://timbish.blogspot.com/
> >
>
>
>
> --
> Clebert Suconic
>

Re: [DISCUSS] Artemis coding style part 2

[Clebert Suconic]

I tried using that checkstye directly and didn't work right away. it
probably needs update versions or something else.


+1 to just use the google checks... just needs to be worked out.


although I would add:







And  the sevntu checkstyle I contributed to sevntu:




   
   




On Thu, Sep 29, 2016 at 3:13 PM, Timothy Bish  wrote:
> On 09/29/2016 03:01 PM, Clebert Suconic wrote:
>>
>> I don't know about other, but to me this is trivial change to me and I
>> don't mind anyways.  All I really mind is to have a checkstyle in
>> place, whatever that is :)
>>
>> What would need to be changed on the checkstyle rules? did you check?
>
>
> From the old thread we lazily decided that we should adopt the Google style
> guide which is quite close to the 5.x code as it stands now.  I didn't look
> close enough on the original commit to notice that this was not exactly what
> was done but having been in the code over the past few days it has become
> apparent it didn't go as far as I thought it was going to.  It is a bit
> irritating trying to bring over code from 5.x as the formatting never quite
> matches and breaks the checkstyle rules.
>
> The Google style formatting rules are here:
> https://github.com/google/styleguide all in nice little files that can be
> imported into the IDE of your choice.
>
> For checkstyle configuration to use the Google style that is covered in the
> CheckStyle project here:
> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml
>
> Previous thread on this is here for reference:
> http://mail-archives.apache.org/mod_mbox/activemq-dev/201508.mbox/browser
>
>
>>
>> On Thu, Sep 29, 2016 at 2:41 PM, Christopher Shannon
>>  wrote:
>>>
>>> Hey Everyone,
>>>
>>> Last year we had a discussion on the coding style for Artemis and a
>>> change
>>> was made to the opening curly brace.  However, I've been in the code
>>> quite
>>> a bit the past couple weeks doing testing (I am starting to look at what
>>> needs to be done to help move missing features from 5.x) and I've noticed
>>> a
>>> couple of things that still don't match up with the 5.x style.
>>>
>>> In general I think think we should try and get the style closer to 5.x
>>> because it will make going back and forth between to two code bases
>>> easier.
>>>The main thing I noticed is the while the opening brace was moved the
>>> closing curly brace is still on its own line which doesn't match the
>>> style
>>> of 5.x. This makes it a bit annoying when working in one project and then
>>> doing work in a different project as suddenly you have to remember where
>>> the curly brace is supposed to go.
>>>
>>> For example:
>>>
>>> Current format:
>>>  try {
>>>  //do something
>>>   }
>>>   catch (Exception cause) {
>>>
>>>}
>>>
>>> Proposed format, notice that the catch(Exception) part is on the same
>>> line
>>> as the closing brace
>>>  try {
>>>  //do something
>>>   } catch (Exception cause) {
>>>
>>>   }
>>>
>>> Thoughts? My preference would be to adopt entire google style guide but I
>>> think at the least should fix the closing curly brace so it matches up
>>> with
>>> 5.x.
>>
>>
>>
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>



-- 
Clebert Suconic

Re: [DISCUSS] Artemis coding style part 2

[Timothy Bish]

On 09/29/2016 03:01 PM, Clebert Suconic wrote:

I don't know about other, but to me this is trivial change to me and I
don't mind anyways.  All I really mind is to have a checkstyle in
place, whatever that is :)

What would need to be changed on the checkstyle rules? did you check?


From the old thread we lazily decided that we should adopt the Google 
style guide which is quite close to the 5.x code as it stands now.  I 
didn't look close enough on the original commit to notice that this was 
not exactly what was done but having been in the code over the past few 
days it has become apparent it didn't go as far as I thought it was 
going to.  It is a bit irritating trying to bring over code from 5.x as 
the formatting never quite matches and breaks the checkstyle rules.


The Google style formatting rules are here: 
https://github.com/google/styleguide all in nice little files that can 
be imported into the IDE of your choice.


For checkstyle configuration to use the Google style that is covered in 
the CheckStyle project here:

https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml

Previous thread on this is here for reference:
http://mail-archives.apache.org/mod_mbox/activemq-dev/201508.mbox/browser



On Thu, Sep 29, 2016 at 2:41 PM, Christopher Shannon
 wrote:

Hey Everyone,

Last year we had a discussion on the coding style for Artemis and a change
was made to the opening curly brace.  However, I've been in the code quite
a bit the past couple weeks doing testing (I am starting to look at what
needs to be done to help move missing features from 5.x) and I've noticed a
couple of things that still don't match up with the 5.x style.

In general I think think we should try and get the style closer to 5.x
because it will make going back and forth between to two code bases easier.
   The main thing I noticed is the while the opening brace was moved the
closing curly brace is still on its own line which doesn't match the style
of 5.x. This makes it a bit annoying when working in one project and then
doing work in a different project as suddenly you have to remember where
the curly brace is supposed to go.

For example:

Current format:
 try {
 //do something
  }
  catch (Exception cause) {

   }

Proposed format, notice that the catch(Exception) part is on the same line
as the closing brace
 try {
 //do something
  } catch (Exception cause) {

  }

Thoughts? My preference would be to adopt entire google style guide but I
think at the least should fix the closing curly brace so it matches up with
5.x.






--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Artemis coding style part 2

[Justin Bertram]

All things being equal I've got no problem with that change.

Assuming this change is ratified my only concern would be with the timing (e.g. 
minor vs. major version).  Changes like this can make things more difficult to 
back-port upstream fixes to older branches (unless there's some git magic I'm 
unaware of).


Justin

- Original Message -
From: "Christopher Shannon" 
To: dev@activemq.apache.org
Sent: Thursday, September 29, 2016 1:41:28 PM
Subject: [DISCUSS] Artemis coding style part 2

Hey Everyone,

Last year we had a discussion on the coding style for Artemis and a change
was made to the opening curly brace.  However, I've been in the code quite
a bit the past couple weeks doing testing (I am starting to look at what
needs to be done to help move missing features from 5.x) and I've noticed a
couple of things that still don't match up with the 5.x style.

In general I think think we should try and get the style closer to 5.x
because it will make going back and forth between to two code bases easier.
  The main thing I noticed is the while the opening brace was moved the
closing curly brace is still on its own line which doesn't match the style
of 5.x. This makes it a bit annoying when working in one project and then
doing work in a different project as suddenly you have to remember where
the curly brace is supposed to go.

For example:

Current format:
try {
//do something
 }
 catch (Exception cause) {

  }

Proposed format, notice that the catch(Exception) part is on the same line
as the closing brace
try {
//do something
 } catch (Exception cause) {

 }

Thoughts? My preference would be to adopt entire google style guide but I
think at the least should fix the closing curly brace so it matches up with
5.x.

[GitHub] activemq-artemis pull request #800: POC for CDI Integration in Artemis

[clebertsuconic]

Github user clebertsuconic commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/800#discussion_r81211716
  
--- Diff: docs/user-manual/en/cdi-integration.md ---
@@ -0,0 +1,32 @@
+# CDI Integration
+
+Apache ActiveMQ Artemis provides a simple CDI integration.  It can either 
use an embedded broker or connect to a remote broker.
+
+## Configuring a connection
+
+Configuration is provided by implementing the `ArtemisClientConfiguration` 
interface.
+
+```java
+public interface ArtemisClientConfiguration {
+   String getHost();
+
+   Integer getPort();
+
+   String getUsername();
+
+   String getPassword();
+
+   String getUrl();
+
+   String getConnectorFactory();
+
+   boolean startEmbeddedBroker();
+
+   boolean isHa();
+
+   boolean hasAuthentication();
+}
+```
+
+There's a default configuration out of the box, if none is specified.  
This will generate an embedded broker.
--- End diff --

Can we improve the doc a little here? how to use it.. etc? just a paragraph 
or two is fine.

I will merge it regardless of this.. but it would be nice to improve it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Artemis coding style part 2

[Clebert Suconic]

On Thu, Sep 29, 2016 at 3:01 PM, Clebert Suconic
 wrote:
> I don't know about other, but to me this is trivial change to me and I
> don't mind anyways.  All I really mind is to have a checkstyle in
> place, whatever that is :)
>

BTW: I didn't mean it wasn't important considering it. I just said
that if you think it needs to be done, lets do it as it is a trivial
change. As long as the checkstyle is updated.

Re: [DISCUSS] Artemis coding style part 2

[Clebert Suconic]

I don't know about other, but to me this is trivial change to me and I
don't mind anyways.  All I really mind is to have a checkstyle in
place, whatever that is :)

What would need to be changed on the checkstyle rules? did you check?

On Thu, Sep 29, 2016 at 2:41 PM, Christopher Shannon
 wrote:
> Hey Everyone,
>
> Last year we had a discussion on the coding style for Artemis and a change
> was made to the opening curly brace.  However, I've been in the code quite
> a bit the past couple weeks doing testing (I am starting to look at what
> needs to be done to help move missing features from 5.x) and I've noticed a
> couple of things that still don't match up with the 5.x style.
>
> In general I think think we should try and get the style closer to 5.x
> because it will make going back and forth between to two code bases easier.
>   The main thing I noticed is the while the opening brace was moved the
> closing curly brace is still on its own line which doesn't match the style
> of 5.x. This makes it a bit annoying when working in one project and then
> doing work in a different project as suddenly you have to remember where
> the curly brace is supposed to go.
>
> For example:
>
> Current format:
> try {
> //do something
>  }
>  catch (Exception cause) {
>
>   }
>
> Proposed format, notice that the catch(Exception) part is on the same line
> as the closing brace
> try {
> //do something
>  } catch (Exception cause) {
>
>  }
>
> Thoughts? My preference would be to adopt entire google style guide but I
> think at the least should fix the closing curly brace so it matches up with
> 5.x.



-- 
Clebert Suconic

[DISCUSS] Artemis coding style part 2

[Christopher Shannon]

Hey Everyone,

Last year we had a discussion on the coding style for Artemis and a change
was made to the opening curly brace.  However, I've been in the code quite
a bit the past couple weeks doing testing (I am starting to look at what
needs to be done to help move missing features from 5.x) and I've noticed a
couple of things that still don't match up with the 5.x style.

In general I think think we should try and get the style closer to 5.x
because it will make going back and forth between to two code bases easier.
  The main thing I noticed is the while the opening brace was moved the
closing curly brace is still on its own line which doesn't match the style
of 5.x. This makes it a bit annoying when working in one project and then
doing work in a different project as suddenly you have to remember where
the curly brace is supposed to go.

For example:

Current format:
try {
//do something
 }
 catch (Exception cause) {

  }

Proposed format, notice that the catch(Exception) part is on the same line
as the closing brace
try {
//do something
 } catch (Exception cause) {

 }

Thoughts? My preference would be to adopt entire google style guide but I
think at the least should fix the closing curly brace so it matches up with
5.x.

[GitHub] activemq-artemis issue #800: POC for CDI Integration in Artemis

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/800
  
although I will pull, rebase and run the tests myself.. I may merge before 
you can do it if everything ok.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #800: POC for CDI Integration in Artemis

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/800
  
testsuite was broken, can you rebase?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE]Apache ActiveMQ 5.14.1 #2

[Robbie Gemmell]

On 27 September 2016 at 18:40, Christopher Shannon
 wrote:
> Hi Everyone,
>
> I have re-created the ActiveMQ 5.14.1 release and it's ready for a vote.
>
> The list of resolved issues is here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12311210&version=12338124
>
> You can get binary distributions here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1108/org/apache/activemq/apache-activemq/5.14.1/
>
> Source archives are here:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1108/org/apache/activemq/activemq-parent/5.14.1/
>
> Maven repository is at:
> https://repository.apache.org/content/repositories/orgapacheactivemq-1108/
>
> Source tag:
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=594c79e531a7b9885cb28ca0a9e18fe25cd4f1c3
>
> Please vote to approve this release.  The vote will remain open for 72
> hours.
>
> [ ] +1 Release the binary as Apache ActiveMQ 5.14.1
> [ ] -1 (provide specific comments)
>
> Here's my +1


+1 (non-binding)

I gave things a check over as so:
- Verified the signatures for the source and binary archives.
- Checked for licence + notice files being present.
- Ran the source build (only, no tests).
- Started the broker from the tar.gz binary, ran some AMQP client
examples against it.
- Used the staged maven artifacts to run the Qpid JMS client master build+tests.

Robbie

[GitHub] activemq pull request #202: Fixes AMQ-6441 where a negative value can be ret...

[wcrowell]

GitHub user wcrowell opened a pull request:

https://github.com/apache/activemq/pull/202

Fixes AMQ-6441 where a negative value can be returned with large AWS EFS 
files systems when calling java.io.File.getTotalSpace()

Fixes AMQ-6441

A test, testLargeFileSystem(), was added to 
org.apache.activemq.broker.BrokerServiceTest for checking if the total space on 
a volume was too large to fit into a primitive long.  If this happens, then 
totalSpace is set to java.lang.Long.MAX_VALUE.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/wcrowell/activemq master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq/pull/202.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 #202


commit c94b1a2eec78a0fd15763b64dcdff455bfc66e52
Author: William Crowell 
Date:   2016-09-29T12:22:46Z

Fixes AMQ-6441 where a negative value can be returned with large AWS EFS 
files systems when calling java.io.File.getTotalSpace()

commit 0c98ecfa2b903ce1301802617b8c5152048364f4
Author: William Crowell 
Date:   2016-09-29T12:24:41Z

Fixes AMQ-6441 where a negative value can be returned with large AWS EFS 
files systems when calling java.io.File.getTotalSpace()




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #800: POC for CDI Integration in Artemis

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/800
  
* ..still not sure why you list dependencies w/ license in there, but hope 
this is fine

There was a need to list licenses at the initial commit to cleanup some 
CatX. Everyone kept doing it thereafter. If you think we should stop doing son 
we can stop it.  I think it is helpful but I wouldn't have a problem otherwise. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #810: ARTEMIS-758 - List/Object message sent by OpenW...

[mtaylor]

Github user mtaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/810
  
The issue aiui is that the CORE object message encoding adds some 
additional data to the serialized byte stream received from the client, it 
prepends the byte with the length of the binary, I presume this was used in the 
past when reading the binary back from the Journal.   The problem with just 
dumping the byte stream as we were doing previously, is that there's a 
different encoding for CORE vs OpenWire.  This small changes ensures that both 
encodings are the same.  

Another way to approach this would have been to add some extra meta-data to 
the message describing it's content as @tabish121 mentioned with the 
"'application/x-java-serialized-object" type or something similar.  I think we 
can do that as part of the larger task of removing the translations.  Right now 
though, this small change fixes the cross protocol issue.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] activemq-artemis issue #810: ARTEMIS-758 - List/Object message sent by OpenW...

[andytaylor]

Github user andytaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/810
  
fixed checkstyle errors


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---