[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default

[Robert Lu (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16338468#comment-16338468
 ] 

Robert Lu commented on THRIFT-4474:
---

Maybe this is a break change.

The code generated by old thrift compiler and new thrift compiler both can be 
loaded via classmap method(in composer).

But, \Thrift\ClassLoader\ThriftClassLoader donot use classmap, it just find 
class in Service.php or Types.php, so code generated by psr4 compiler *cannot* 
be load via \Thrift\ClassLoader\ThriftClassLoader::registerDefinition. 
\Thrift\ClassLoader\ThriftClassLoader::registerNamespace should be used. 


> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via 
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The 
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which 
> can only load via classmap), add {{classmap}} option.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16338457#comment-16338457
 ] 

ASF GitHub Bot commented on THRIFT-4474:


GitHub user RobberPhex opened a pull request:

https://github.com/apache/thrift/pull/1479

THRIFT-4474: generate PHP code use PSR-4 style default

ref: https://issues.apache.org/jira/browse/THRIFT-4474

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

$ git pull https://github.com/RobberPhex/thrift default-psr4

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

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


commit a083deebd3977f68bf5fdfe1d2e88ea240f8183a
Author: Robert Lu 
Date:   2018-01-17T11:40:39Z

generate PHP code use PSR-4 style default




> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via 
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The 
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which 
> can only load via classmap), add {{classmap}} option.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift pull request #1479: THRIFT-4474: generate PHP code use PSR-4 style de...

[RobberPhex]

GitHub user RobberPhex opened a pull request:

https://github.com/apache/thrift/pull/1479

THRIFT-4474: generate PHP code use PSR-4 style default

ref: https://issues.apache.org/jira/browse/THRIFT-4474

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

$ git pull https://github.com/RobberPhex/thrift default-psr4

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

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


commit a083deebd3977f68bf5fdfe1d2e88ea240f8183a
Author: Robert Lu 
Date:   2018-01-17T11:40:39Z

generate PHP code use PSR-4 style default




---

[jira] [Created] (THRIFT-4474) PHP generator use PSR-4 default

[Robert Lu (JIRA)]

Robert Lu created THRIFT-4474:
-

 Summary: PHP generator use PSR-4 default
 Key: THRIFT-4474
 URL: https://issues.apache.org/jira/browse/THRIFT-4474
 Project: Thrift
  Issue Type: Improvement
  Components: PHP - Compiler
Reporter: Robert Lu
Assignee: Robert Lu


Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
Those can only be load via 
[{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The 
latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].

thrift compiler can generate PSR-4 code default, if want old-style code(which 
can only load via classmap), add {{classmap}} option.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4308) D language docker images need demios for libevent and openssl fixed to re-enable make cross on dlang

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16338247#comment-16338247
 ] 

ASF GitHub Bot commented on THRIFT-4308:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/723
  
See https://issues.apache.org/jira/browse/THRIFT-4308

Essentially the upstream deimos modules for openssl and libevent no longer 
work, and we need to move to something else for secure and for non-blocking 
modes.  I think there's probably a better D crypto lib we can use, but I'm not 
sure about libevent.  In any case, there hasn't been much of an uproar from 
folks about these things not working.


> D language docker images need demios for libevent and openssl fixed to 
> re-enable make cross on dlang
> 
>
> Key: THRIFT-4308
> URL: https://issues.apache.org/jira/browse/THRIFT-4308
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process, D - Library
>Affects Versions: 0.11.0
> Environment: docker:ubuntu-xenial
>Reporter: James E. King, III
>Priority: Major
>
> I had to disable the deimos hooks for libevent and openssl because they were 
> causing build failures.  For openssl the deimos library only supports up to 
> 1.0.1, and ubuntu-xenial has 1.0.2; for libevent I was unable to get some of 
> the "make check" tests to link, citing unreferenced methods that were 
> actually in the libevent.so file that ld resolved to, so I don't know what's 
> going on there.
> A result of this change is that dlang is NOT tested in "make cross" at all, 
> because the test executables are only generated if openssl support exists, 
> and it does not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift issue #723: dub.sdl for integration into Dlang package registry

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/723
  
See https://issues.apache.org/jira/browse/THRIFT-4308

Essentially the upstream deimos modules for openssl and libevent no longer 
work, and we need to move to something else for secure and for non-blocking 
modes.  I think there's probably a better D crypto lib we can use, but I'm not 
sure about libevent.  In any case, there hasn't been much of an uproar from 
folks about these things not working.


---

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[bgedik]

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

https://github.com/apache/thrift/pull/1476#discussion_r163681677
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.h ---
@@ -78,6 +78,7 @@ class TSSLSocket : public TSocket {
   bool peek();
   void open();
   void close();
+  bool hasPendingDataToRead();
--- End diff --

Sam applies to ``read``. This goes back to my original point. TSocket 
should behave differently for blocking vs non-blocking socket. Look at how 
``TSocket`` and ``TSSLSocket`` handle ``read``s on a non-blocking socket. They 
throw exceptions. Luckily for me, when not using SSL, ``TNonBlockingServer`` 
does not ever call ``read`` on a socket that is not ready to consume data. 
However, that is not the case for ``SSL``.  Read calls in 
``TNonBlockingServer`` are retried by catching the exception and searching for 
``"retry"`` in the exception message.

The correct way to fix all this mess is to make ``TSocket`` aware of 
whether the socket is blocking and non-blocking and behave accordingly. 
Converting EAGAIN to an exception in the case of non-blocking sockets is a 
major performance hit. 

My suggesting is to handle the issue of making ``TSocket`` and 
``TSSLSocket`` aware of the blocking/non-blocking nature of the socket in a 
separate Jira issue. 


---

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[bgedik]

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

https://github.com/apache/thrift/pull/1476#discussion_r163679874
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.cpp ---
@@ -249,6 +249,17 @@ TSSLSocket::~TSSLSocket() {
   close();
 }
 
+bool TSSLSocket::hasPendingDataToRead() {
+  if (!isOpen()) {
+return false;
+  }
+  initializeHandshake();
+  if (!checkHandshake())
+throw TSSLException("SSL_peek: Handshake is not completed");
+  // data may be available in SSL buffers (note: SSL_pending does not have 
a failure mode)
+  return TSocket::hasPendingDataToRead() || SSL_pending(ssl_) > 0;
--- End diff --

Right. Nice catch.


---

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[bgedik]

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

https://github.com/apache/thrift/pull/1476#discussion_r163673632
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.cpp ---
@@ -249,6 +249,17 @@ TSSLSocket::~TSSLSocket() {
   close();
 }
 
+bool TSSLSocket::hasPendingDataToRead() {
+  if (!isOpen()) {
+return false;
+  }
+  initializeHandshake();
+  if (!checkHandshake())
+throw TSSLException("SSL_peek: Handshake is not completed");
--- End diff --

Fixed.


---

[GitHub] thrift issue #1476: Remove premature call to workSocket() in TNonblockingSer...

[bgedik]

Github user bgedik commented on the issue:

https://github.com/apache/thrift/pull/1476
  
Ok, reverted back.


---

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[jeking3]

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

https://github.com/apache/thrift/pull/1476#discussion_r163663375
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.cpp ---
@@ -249,6 +249,17 @@ TSSLSocket::~TSSLSocket() {
   close();
 }
 
+bool TSSLSocket::hasPendingDataToRead() {
+  if (!isOpen()) {
+return false;
+  }
+  initializeHandshake();
+  if (!checkHandshake())
+throw TSSLException("SSL_peek: Handshake is not completed");
--- End diff --

This should probably say something other than SSL_peek?


---

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[jeking3]

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

https://github.com/apache/thrift/pull/1476#discussion_r163664502
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.h ---
@@ -78,6 +78,7 @@ class TSSLSocket : public TSocket {
   bool peek();
   void open();
   void close();
+  bool hasPendingDataToRead();
--- End diff --

I think my comments were wrong; peek blocks until there is something to do 
when the socket is a blocking socket.  I think that if the socket knew it was 
non-blocking then a call to peek() would behave like a call to 
hasPendingDataToRead, i.e. it would be a non-blocking call.  Perhaps that's a 
better way to approach it, but I would have to look at the code a little more 
closely.  I think the original intention of my comment was correct, there 
should be only one way to peek.  Calling peek() on a non-blocking socket should 
not block; calling peek() on a blocking socket should block.


---

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[jeking3]

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

https://github.com/apache/thrift/pull/1476#discussion_r163663584
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.cpp ---
@@ -249,6 +249,17 @@ TSSLSocket::~TSSLSocket() {
   close();
 }
 
+bool TSSLSocket::hasPendingDataToRead() {
+  if (!isOpen()) {
+return false;
+  }
+  initializeHandshake();
+  if (!checkHandshake())
+throw TSSLException("SSL_peek: Handshake is not completed");
+  // data may be available in SSL buffers (note: SSL_pending does not have 
a failure mode)
+  return TSocket::hasPendingDataToRead() || SSL_pending(ssl_) > 0;
--- End diff --

Should SSL_pending be checked first for efficiency?  First check the SSL 
buffers, then if those are clear then check the socket.


---

[GitHub] thrift issue #1476: Remove premature call to workSocket() in TNonblockingSer...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1476
  
I see now, I may have led you down the wrong path with my comments.  So 
peek() blocks waiting for data the be available to read and the end result of 
peek is that there is data to read OR the socket disconnected.  What you are 
looking for is a call to see if the socket has data available but does not 
block.  As such, those are different code paths...

Perhaps your original code before this last push was correct.  I will take 
another look. 


---

[jira] [Resolved] (THRIFT-4471) Thrift CPAN release is missing Makefile.PL and the clients are unable to build the module

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-4471.

   Resolution: Fixed
Fix Version/s: 0.12.0

I fixed the build script and uploaded 0.11.0-2 to CPAN.

> Thrift CPAN release is missing Makefile.PL and the clients are unable to 
> build the module
> -
>
> Key: THRIFT-4471
> URL: https://issues.apache.org/jira/browse/THRIFT-4471
> Project: Thrift
>  Issue Type: Bug
>  Components: Perl - Library
>Affects Versions: 0.11.0
>Reporter: Burak Gursoy
>Assignee: James E. King, III
>Priority: Critical
> Fix For: 0.12.0
>
>
> Hi,
>  
> New releases are lacking the builder, so the cpan clients are not able to 
> build/install the releases. 
> [https://metacpan.org/diff/file?target=JKING/Thrift-0.11.0-1/=JKING%2FThrift-0.9.3]
> Apparently, the release was broken after 0.9.3. Without a proper builder code 
> (Makefile.PL / Build.PL), the releases can't be installed. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[bgedik]

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

https://github.com/apache/thrift/pull/1476#discussion_r163651048
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.h ---
@@ -78,6 +78,7 @@ class TSSLSocket : public TSocket {
   bool peek();
   void open();
   void close();
+  bool hasPendingDataToRead();
--- End diff --

I implemented option #2. In terms of your matrix choice suggestion: How can 
we make that happen? Is that something I can help with? I am bothered by the 
TNonblockingSeverTest not catching the problem reported in this bug. The moment 
we switched to 0.11, it started throwing unexpected exceptions for us, when 
using Java client against C++ server. This should have been caught by the 
existing tests, but it did not happen. I would like to help with this. So if 
you have a suggestion for me, please let me know.


---

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[bgedik]

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

https://github.com/apache/thrift/pull/1476#discussion_r163640014
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.h ---
@@ -78,6 +78,7 @@ class TSSLSocket : public TSocket {
   bool peek();
   void open();
   void close();
+  bool hasPendingDataToRead();
--- End diff --

@jeking3 You said it would be preferable to have one way to ask, "is there 
any data I can read" that does not block. I completely agree. But the existing 
``peek`` method is not designed to be non-blocking. So I have a few choices 
here:
  * Update the doxygen comment of ``peek`` to reflect what it does and keep 
``hasPendingDataToRead``
  * Add an optional argument to peek that says ``nonBlocking=false`` and if 
it is provided as ``true``, do what ``hasPendingDataToRead`` used to do and 
remove ``hasPendingDataToRead``.
  * Change ``peek`` to be always non-blocking.

How about #2 above? I think #3 is not easy, as it will require code changes 
in other places that I am not comfortable with.


---

[jira] [Commented] (THRIFT-4473) Move Thrift.Console.pas out of the Library

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16338018#comment-16338018
 ] 

ASF GitHub Bot commented on THRIFT-4473:


GitHub user Jens-G opened a pull request:

https://github.com/apache/thrift/pull/1478

THRIFT-4473 Move Thrift.Console.pas out of the Library

Client: Delphi
Patch: Jens Geyer

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

$ git pull https://github.com/Jens-G/thrift THRIFT-4473

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

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


commit cf753348438bf800446e393a6d114408b314f438
Author: Jens Geyer 
Date:   2018-01-24T18:14:32Z

THRIFT-4473 Move Thrift.Console.pas out of the Library
Client: Delphi
Patch: Jens Geyer




> Move Thrift.Console.pas out of the Library
> --
>
> Key: THRIFT-4473
> URL: https://issues.apache.org/jira/browse/THRIFT-4473
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
>
> Thrift.Console.pas is ok as part of the tests, but should not be in the 
> library. The code does neither belong into the library nor does it adhere to 
> quality standards expected for a software library. It's ok for the tests 
> suite though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift pull request #1478: THRIFT-4473 Move Thrift.Console.pas out of the Li...

[Jens-G]

GitHub user Jens-G opened a pull request:

https://github.com/apache/thrift/pull/1478

THRIFT-4473 Move Thrift.Console.pas out of the Library

Client: Delphi
Patch: Jens Geyer

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

$ git pull https://github.com/Jens-G/thrift THRIFT-4473

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

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


commit cf753348438bf800446e393a6d114408b314f438
Author: Jens Geyer 
Date:   2018-01-24T18:14:32Z

THRIFT-4473 Move Thrift.Console.pas out of the Library
Client: Delphi
Patch: Jens Geyer




---

[jira] [Updated] (THRIFT-4473) Move Thrift.Console.pas out of the Library

[Jens Geyer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer updated THRIFT-4473:
---
Component/s: Delphi - Library

> Move Thrift.Console.pas out of the Library
> --
>
> Key: THRIFT-4473
> URL: https://issues.apache.org/jira/browse/THRIFT-4473
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Library
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
>
> Thrift.Console.pas is ok as part of the tests, but should not be in the 
> library. The code does neither belong into the library nor does it adhere to 
> quality standards expected for a software library. It's ok for the tests 
> suite though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4468) Make the class TGUIConsole thread-safe

[Jens Geyer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer updated THRIFT-4468:
---
Issue Type: Sub-task  (was: Improvement)
Parent: THRIFT-4473

> Make the class TGUIConsole thread-safe
> --
>
> Key: THRIFT-4468
> URL: https://issues.apache.org/jira/browse/THRIFT-4468
> Project: Thrift
>  Issue Type: Sub-task
>  Components: Delphi - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Priority: Major
>
> In Delphi all methods that refer to VCL should do it only from main thread. 
> But class TGUIConsole despite the name does not contain any synchronization 
> methods.
> My suggestion is to rename this class to TStringsConsole, make method 
> InternalWrite virtual and make new class TGUIConsole inherits from 
> TStringsConsole
> {{ TGUIConsole = class( TStringsConsole )}}
> {{ protected}}
> {{  procedure InternalWrite(const S: string; bWriteLine: Boolean); override;}}
> {{ end;}}
> {{{ TGUIConsole }}}
> {{procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);}}
> {{begin}}
> {{  if TThread.CurrentThread.ThreadID <> MainThreadID then begin}}
> {{    TThread.Synchronize(nil, procedure}}
> {{      begin}}
> {{        inherited InternalWrite(S, bWriteLine);}}
> {{      end}}
> {{    );}}
> {{  end else}}
> {{    inherited InternalWrite(S, bWriteLine);}}
> {{end;}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4467) Add methods WriteFmt/WriteLineFmt to TThriftConsole class

[Jens Geyer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer updated THRIFT-4467:
---
Issue Type: Sub-task  (was: Improvement)
Parent: THRIFT-4473

> Add methods WriteFmt/WriteLineFmt to TThriftConsole class
> -
>
> Key: THRIFT-4467
> URL: https://issues.apache.org/jira/browse/THRIFT-4467
> Project: Thrift
>  Issue Type: Sub-task
>  Components: Delphi - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Priority: Minor
>  Labels: Console
>
> For ease of use, add methods
> {{procedure TThriftConsole.WriteFmt(const AFmt: string;}}
>  const AArgs: array of const);
>  {{begin}}
>  {{  Write(Format(AFmt, AArgs));}}
>  {{end;}}
> {{procedure TThriftConsole.WriteLineFmt(const AFmt: string;}}
>  const AArgs: array of const);
>  {{begin}}
>  {{  WriteLine(Format(AFmt, AArgs));}}
>  {{end;}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (THRIFT-4473) Move Thrift.Console.pas out of the Library

[Jens Geyer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer reassigned THRIFT-4473:
--

Assignee: Jens Geyer

> Move Thrift.Console.pas out of the Library
> --
>
> Key: THRIFT-4473
> URL: https://issues.apache.org/jira/browse/THRIFT-4473
> Project: Thrift
>  Issue Type: Improvement
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
>
> Thrift.Console.pas is ok as part of the tests, but should not be in the 
> library. The code does neither belong into the library nor does it adhere to 
> quality standards expected for a software library. It's ok for the tests 
> suite though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (THRIFT-4473) Move Thrift.Console.pas out of the Library

[Jens Geyer (JIRA)]

Jens Geyer created THRIFT-4473:
--

 Summary: Move Thrift.Console.pas out of the Library
 Key: THRIFT-4473
 URL: https://issues.apache.org/jira/browse/THRIFT-4473
 Project: Thrift
  Issue Type: Improvement
Reporter: Jens Geyer


Thrift.Console.pas is ok as part of the tests, but should not be in the 
library. The code does neither belong into the library nor does it adhere to 
quality standards expected for a software library. It's ok for the tests suite 
though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4471) Thrift CPAN release is missing Makefile.PL and the clients are unable to build the module

[James E. King, III (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337967#comment-16337967
 ] 

James E. King, III commented on THRIFT-4471:


How can I test a package that I build locally without first publishing it to 
CPAN?

> Thrift CPAN release is missing Makefile.PL and the clients are unable to 
> build the module
> -
>
> Key: THRIFT-4471
> URL: https://issues.apache.org/jira/browse/THRIFT-4471
> Project: Thrift
>  Issue Type: Bug
>  Components: Perl - Library
>Affects Versions: 0.11.0
>Reporter: Burak Gursoy
>Assignee: James E. King, III
>Priority: Critical
>
> Hi,
>  
> New releases are lacking the builder, so the cpan clients are not able to 
> build/install the releases. 
> [https://metacpan.org/diff/file?target=JKING/Thrift-0.11.0-1/=JKING%2FThrift-0.9.3]
> Apparently, the release was broken after 0.9.3. Without a proper builder code 
> (Makefile.PL / Build.PL), the releases can't be installed. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift issue #1474: Recognize fbthrift TApplicationException codes

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1474
  
@Jens-G what do you think about the notion of moving the definition of 
error message enumerations into a single common .thrift file that gets compiled 
and then comsumed by the libraries?  It would certainly go a long way to 
ensuring that these error codes are handled in a standardized way across all 
languages.  I think that the generated code would have to be packaged along 
with the built library in some cases, but that shouldn't be a problem.


---

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[jeking3]

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

https://github.com/apache/thrift/pull/1476#discussion_r163623295
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.h ---
@@ -78,6 +78,7 @@ class TSSLSocket : public TSocket {
   bool peek();
   void open();
   void close();
+  bool hasPendingDataToRead();
--- End diff --

Note that the cross test suite currently does not test asynchronous.  It is 
more of a protocol test; it would be interesting to add one more matrix choice 
of threaded vs. nonblocking for the languages that support it, and test both 
against both.


---

[GitHub] thrift pull request #1476: Remove premature call to workSocket() in TNonbloc...

[jeking3]

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

https://github.com/apache/thrift/pull/1476#discussion_r163622772
  
--- Diff: lib/cpp/src/thrift/transport/TSSLSocket.h ---
@@ -78,6 +78,7 @@ class TSSLSocket : public TSocket {
   bool peek();
   void open();
   void close();
+  bool hasPendingDataToRead();
--- End diff --

It would be preferable to have one way to ask, "is there any data I can 
read" that does not block.


---

[jira] [Resolved] (THRIFT-4294) Java Configure Fails for Ant >= 1.10

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-4294.

   Resolution: Fixed
 Assignee: James E. King, III
Fix Version/s: 0.12.0

Resolved by commit 7004a61e44fe538805b44c3fb66bd5cb872548d4.

> Java Configure Fails for Ant >= 1.10
> 
>
> Key: THRIFT-4294
> URL: https://issues.apache.org/jira/browse/THRIFT-4294
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.12.0
>Reporter: Mike Rettig
>Assignee: James E. King, III
>Priority: Major
>  Labels: ant_build_system
> Fix For: 0.12.0
>
>
> The configure step enables building the java lib if the ant version is >= 
> 1.7.  Unfortunately this check fails for ant 1.10 which is the latest 
> version. The library builds fine with 1.10.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (THRIFT-4259) Thrift does not compile due to Ant Maven task errors

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-4259.

   Resolution: Fixed
 Assignee: James E. King, III
Fix Version/s: 0.12.0

Resolved by commit 7004a61e44fe538805b44c3fb66bd5cb872548d4.

> Thrift does not compile due to Ant Maven task errors
> 
>
> Key: THRIFT-4259
> URL: https://issues.apache.org/jira/browse/THRIFT-4259
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.9.3, 0.10.0, 0.11.0
> Environment: Fedora 25, Linux, any project docker image (all use ant 
> 1.9.x)
>Reporter: Jacek Furmankiewicz
>Assignee: James E. King, III
>Priority: Blocker
> Fix For: 0.12.0
>
>
> Cannot compile neither 0.9.3 nor 0.10.0
> They both fail with same errors in the Ant / Maven task
> -
> ./configure --without-ruby --without-cpp --without-nodejs --without-python 
> --without-go --without-c_glib 
> /usr/bin/ant 
> Buildfile: /home/jfurmank/Downloads/thrift-0.10.0/lib/java/build.xml
> setup.init:
> mvn.ant.tasks.check:
> proxy:
> mvn.ant.tasks.download:
>   [get] Getting: 
> http://repo1.maven.org/maven2/org/apache/maven/maven-ant-tasks/2.1.3/maven-ant-tasks-2.1.3.jar
>   [get] To: 
> /home/jfurmank/Downloads/thrift-0.10.0/lib/java/build/tools/maven-ant-tasks-2.1.3.jar
>   [get] Not modified - so not downloaded
> mvn.init:
> BUILD FAILED
> /home/jfurmank/Downloads/thrift-0.10.0/lib/java/build.xml:324: 
> java.lang.NoSuchMethodError: 
> org.apache.maven.settings.RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V
>   at 
> org.apache.maven.artifact.ant.AbstractArtifactTask.loadSettings(AbstractArtifactTask.java:328)
>   at 
> org.apache.maven.artifact.ant.AbstractArtifactTask.initSettings(AbstractArtifactTask.java:278)
>   at 
> org.apache.maven.artifact.ant.AbstractArtifactTask.getSettings(AbstractArtifactTask.java:223)
>   at 
> org.apache.maven.artifact.ant.AbstractArtifactTask.getDefaultLocalRepository(AbstractArtifactTask.java:212)
>   at 
> org.apache.maven.artifact.ant.AbstractArtifactTask.getLocalRepository(AbstractArtifactTask.java:700)
>   at 
> org.apache.maven.artifact.ant.AbstractArtifactTask.createLocalArtifactRepository(AbstractArtifactTask.java:110)
>   at org.apache.maven.artifact.ant.Pom.getMavenProject(Pom.java:272)
>   at org.apache.maven.artifact.ant.Pom.setGroupId(Pom.java:560)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.tools.ant.IntrospectionHelper$AttributeSetter.setObject(IntrospectionHelper.java:1506)
>   at 
> org.apache.tools.ant.IntrospectionHelper.setAttribute(IntrospectionHelper.java:411)
>   at 
> org.apache.tools.ant.RuntimeConfigurable.maybeConfigure(RuntimeConfigurable.java:527)
>   at 
> org.apache.tools.ant.RuntimeConfigurable.maybeConfigure(RuntimeConfigurable.java:463)
>   at org.apache.tools.ant.Task.maybeConfigure(Task.java:202)
>   at 
> org.apache.tools.ant.UnknownElement.configure(UnknownElement.java:200)
>   at 
> org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:164)
>   at org.apache.tools.ant.Task.perform(Task.java:347)
>   at org.apache.tools.ant.Target.execute(Target.java:435)
>   at org.apache.tools.ant.Target.performTasks(Target.java:456)
>   at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
>   at org.apache.tools.ant.Project.executeTarget(Project.java:1376)
>   at 
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>   at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
>   at org.apache.tools.ant.Main.runBuild(Main.java:853)
>   at org.apache.tools.ant.Main.startAnt(Main.java:235)
>   at org.apache.tools.ant.launch.Launcher.run(Launcher.java:285)
>   at org.apache.tools.ant.launch.Launcher.main(Launcher.java:112)
> Total time: 0 seconds
> Totally blocked, cannot install Thrift on my box, critical for our 
> development.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (THRIFT-4178) Java libraries missing from package when using cmake

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-4178.

   Resolution: Fixed
 Assignee: James E. King, III
Fix Version/s: 0.12.0

Resolved by commit 7004a61e44fe538805b44c3fb66bd5cb872548d4.

> Java libraries missing from package when using cmake
> 
>
> Key: THRIFT-4178
> URL: https://issues.apache.org/jira/browse/THRIFT-4178
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process, Java - Library
>Reporter: Arnaud Lacombe
>Assignee: James E. King, III
>Priority: Major
> Fix For: 0.12.0
>
>
> The CMake infrastructure fails to include the java libraries in the generated 
> package. Instead, the libraries are wrongly installed on the build host. The 
> problem is likely due to the following line:
> lib/java/CMakeLists.txt:
> {noformat}
> [...]
> # Hook the ant install task into CMake install
>   
> 
> install(CODE "execute_process(
> COMMAND ${Ant_EXECUTABLE} ${ANT_FLAGS} install
>   
> 
> -Dbuild.dir=\"${CMAKE_CURRENT_BINARY_DIR}\"
> -Dinstall.path=\"${JAVA_INSTALL_DIR}\" 
> -Dinstall.javadoc.path=\"${JAVA_DOC_INSTALL_DIR}\" -f build.xml
> WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} 
>   
> 
> )")
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (THRIFT-4120) pom files are not generated or provided in the build

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-4120.

   Resolution: Fixed
 Assignee: James E. King, III
Fix Version/s: 0.12.0

Resolved by commit 7004a61e44fe538805b44c3fb66bd5cb872548d4.

> pom files are not generated or provided in the build
> 
>
> Key: THRIFT-4120
> URL: https://issues.apache.org/jira/browse/THRIFT-4120
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process, Java - Library
>Affects Versions: 0.10.0
>Reporter: Christopher Tubbs
>Assignee: James E. King, III
>Priority: Major
> Fix For: 0.12.0
>
>
> It appears pom files are being manually created and uploaded to the Nexus 
> staging repository when thrift jars are uploaded there. They should be 
> version-controlled and part of the source tarball, or created during the 
> build process.
> This affects both libthrift.jar and libfb303.jar
> Including these files in the source tree, or created during the build would 
> make it easier for downstream packagers to reproduce good Maven artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (THRIFT-3983) libthrift is deployed on central with pom packaging instead of jar

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-3983.

   Resolution: Fixed
 Assignee: James E. King, III
Fix Version/s: 0.12.0

Resolved by commit 7004a61e44fe538805b44c3fb66bd5cb872548d4.

> libthrift is deployed on central with pom packaging instead of jar
> --
>
> Key: THRIFT-3983
> URL: https://issues.apache.org/jira/browse/THRIFT-3983
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.9.3
>Reporter: Stéphane Landelle
>Assignee: James E. King, III
>Priority: Blocker
> Fix For: 0.12.0
>
>
> Hi,
> libthrift is deployed with a "pom" packaging on maven central, see 
> https://repo1.maven.org/maven2/org/apache/thrift/libthrift/0.9.3/libthrift-0.9.3.pom
> org.apache.thrift
> libthrift
> 0.9.3
> pom
> Apache Thrift
> This is very wrong. "pom" means "no jar, just a list of dependencies to be 
> pulled transitively".
> As a consequence, some build tools, such as sbt, don't pull the libthrift jar 
> itself.
> The pom should be be using a "jar" packaging, or even no packaging at all as 
> "jar" is the default value.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (THRIFT-1507) Maven can't download resource from central when behind a proxy and won't use local repository

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-1507.

   Resolution: Fixed
 Assignee: James E. King, III  (was: Jake Farrell)
Fix Version/s: 0.12.0

Resolved by commit 7004a61e44fe538805b44c3fb66bd5cb872548d4.

> Maven can't download resource from central when behind a proxy and won't use 
> local repository
> -
>
> Key: THRIFT-1507
> URL: https://issues.apache.org/jira/browse/THRIFT-1507
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.8
> Environment: Ubuntu 10.04 LTS, running in a VM in VMWare Player 
> hosted on Windows XP Pro which is behind a proxy server.
>Reporter: Mark Anderson
>Assignee: James E. King, III
>Priority: Major
>  Labels: build, maven
> Fix For: 0.12.0
>
>
> When 'make' enters lib/java, the build fails on the mvn.init target with:
> . . .
> [artifact:dependencies] [WARNING] Overriding profile: 
> 'maven-ant-tasks-repo-profile' (source: pom) with new instance from source: 
> pom
> [artifact:dependencies] Downloading: 
> org/slf4j/slf4j-api/1.5.8/slf4j-api-1.5.8.pom from repository central at 
> http://repo1.maven.org/maven2
> [artifact:dependencies] Error transferring file: Connection refused
> [artifact:dependencies] [WARNING] Unable to get resource 
> 'org.slf4j:slf4j-api:pom:1.5.8' from repository central 
> (http://repo1.maven.org/maven2): Error transferring file: Connection refused
> . . .
> This occurs for every dependency in the 'pom' artifact (on some files, the 
> error is "Connection timed out").
> The preceding target, mvn.ant.tasks.download, succeeds (the 
> maven-ant-tasks-2.1.3.jar file is sitting in the tools directory).
> I have added to build.xml:
> proxy.host=proxy1.domain.com
> proxy.port=80
> proxy.user=
> proxy.pass=
> proxy.enabled=true
> and to /etc/maven2/settings.xml:
>  
>   proxy1
>   true
>   http
>   proxy1.domain.com
>   80
>   localhost
> 
> Maven does not seem to be picking up the proxy.  If I manually download all 
> the resources and install them into my local repository (~/.m2/repository) as 
> suggested and re-run make, I still get the errors -- Maven doesn't try to use 
> the local repository.
> If I move the machine out from behind the firewall, everything works fine: 
> Maven downloads all the dependencies and the Java stuff is able to be built.  
> If I then put the machine back behind the firewall and run 'sudo make 
> install', Maven again tries to download the dependencies from central and 
> that, of course, fails.  It doesn't realize that all the dependencies have 
> been downloaded and the Java files have been compiled.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (THRIFT-1418) Compiling Thrift from source: Class org.apache.tools.ant.taskdefs.ConditionTask doesn't support the nested "typefound" element

[James E. King, III (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-1418.

   Resolution: Fixed
 Assignee: James E. King, III
Fix Version/s: 0.12.0

Resolved by commit 7004a61e44fe538805b44c3fb66bd5cb872548d4.

> Compiling Thrift from source: Class 
> org.apache.tools.ant.taskdefs.ConditionTask doesn't support the nested 
> "typefound" element
> --
>
> Key: THRIFT-1418
> URL: https://issues.apache.org/jira/browse/THRIFT-1418
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.7
> Environment: CentOS 5.5, Ant 1.8.2, Java 1.6.0_13-b03
>Reporter: Robert A. Lerche
>Assignee: James E. King, III
>Priority: Major
> Fix For: 0.12.0
>
> Attachments: compile-thrift
>
>
> I am trying to build Thrift from source in the above configuration.  "make" 
> succeeds but "sudo make install" gives the error shown.  I attach the build 
> log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift issue #723: dub.sdl for integration into Dlang package registry

[nrTQgc]

Github user nrTQgc commented on the issue:

https://github.com/apache/thrift/pull/723
  
I replaced dub.sdl with dub.json and fixed deprecation warnings. Can you 
explain issues with current versions of openssl and libevent? What options we 
have? 


---

[GitHub] thrift issue #1448: Thrift-4441: Support compilation without Boost

[Typz]

Github user Typz commented on the issue:

https://github.com/apache/thrift/pull/1448
  
Indeed, it is complete now: the lib can be built without Boost, both 
through autoconf or cmake.
Tests (based on boost test) and tutorial still require boost, though.


---