phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Istvan Toth <st...@cloudera.com.INVALID>
Subject Re: [DISCUSS] Unbundling Sqlline and slf4j backend from phoenix-client and phoenix-client embedded
Date Thu, 27 May 2021 04:36:06 GMT
The technical details:

The plan is to ship the sqlline ubjerjar (sqlline provides an uberjar with
all of its own dependencies shaded in)
in the /lib directory, along with the log4j slf4j  backend jar.
sqlline.py and friends is to be updated to add those to the classpath.

Richard has this already up in https://github.com/apache/phoenix/pull/1239

On Wed, May 26, 2021 at 9:43 PM Josh Elser <elserj@apache.org> wrote:

> I think the idea is that we would include a sqlline jar with the Phoenix
> distribution. Context: we had some grief where a sqlline upgrade caused
> user pain because they were relying on specific output from sqlline.
>
> If we have the sqlline jar _not_ packaged inside phoenix-client, then
> users can easily replace the version of sqlline which makes them happiest.
>
> While I agree with Istvan that #1 is the more "correct" option, I'm
> worried about the impact of folks who rely on the phoenix-client.jar to
> be a "batteries included" fat-jar. Removing sqlline from
> phoenix-client-embedded is great, so I'd lean towards #2.
>
> We can see what adoption of phoenix-client-embedded looks like now that
> we have it in releases. I imagine most folks haven't yet realized that
> it's even an option that's available.
>
> On 5/26/21 1:16 PM, larsh@apache.org wrote:
> > Will sqlline still be part of the Phoenix "distribution"? Or will it
> become a separate package to install?
> >
> >
> >
> >
> >
> >
> > On Wednesday, May 26, 2021, 1:07:17 AM PDT, Istvan Toth <
> stoty@apache.org> wrote:
> >
> >
> >
> >
> >
> > Hi!
> >
> > The current purpose of the phoenix-client JAR is twofold:
> > - It servers as a generic JDBC driver for embedding in applications
> > - It also contains the sqlline library used by the sqlline.py script, as
> > well as the slf4j log4j backend.
> > - (It also contains a some Phoenix code and HBase libraries not necessary
> > for a client, but we're already tracking that in different tickets)
> >
> > One major pain point is the slf4j backend, which makes phoenix-client
> > incompatible with applications and libraries that do not use log4j 1.2
> as a
> > backend, and kind of defeats the purpose of using slf4j in the first
> place.
> > phoenix-client-embedded solves this problem by removing the slf4j backend
> > from Phoenix.
> >
> > In PHOENIX-6378 <https://issues.apache.org/jira/browse/PHOENIX-6378> we
> aim
> > to remove sqlline from the phoenix-client JAR, as it further cleans up
> the
> > classpath, and avoids locking phoenix to the sqlline version that it was
> > built with.
> >
> > In Richard's current patch, we remove sqlline from
> phoenix-client-embedded,
> > and use that in the sqlline script.
> >
> > In our quest for a more useable phoenix-client, we can do two things now:
> >
> >    1. Remove both the slf4j backend, and sqlline from phoenix-client, and
> >    also drop phoenix-client-embedded as it would be the same as
> phoenix-client
> >    2. Remove sqlline from phoenix-client-embedded, and keep the current
> >    phoenix-client as backwards compatibility option
> >
> > I'd prefer the first option, but this is somewhat more disruptive than
> the
> > other.
> >
> > Please share your thoughts. Do you prefer option 1, 2, or something else
> > entirely ?
> >
> > Istvan
> >
>


-- 
*István Tóth* | Staff Software Engineer
stoty@cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https://www.cloudera.com/>
[image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
on LinkedIn] <https://www.linkedin.com/company/cloudera>
<https://www.cloudera.com/>
------------------------------

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message