This has been merged to develop.
On Tue, Oct 1, 2019 at 8:15 AM Jens Deppe wrote:
> Somewhat related to this - I've found that the V1 Admin Rest API
> (geode-web) will not start when Spring 5 libs are on the classpath. I've
> raised https://issues.apache.org/jira/browse/GEODE-7261. I'd like to
Somewhat related to this - I've found that the V1 Admin Rest API
(geode-web) will not start when Spring 5 libs are on the classpath. I've
raised https://issues.apache.org/jira/browse/GEODE-7261. I'd like to see
this included too.
--Jens
On Mon, Sep 30, 2019 at 12:35 PM Udo Kohlmeyer wrote:
>
@Robert, I think the consensus is that WAR is the correct option.
So unless someone objects, GEODE-7241 is a GO!
--Udo
On 9/30/19 10:58 AM, Robert Houghton wrote:
I am unclear on the consensus of this thread.
On Wed, Sep 25, 2019 at 12:55 PM John Blum wrote:
@Jake - Ah, indeed it was
I am unclear on the consensus of this thread.
On Wed, Sep 25, 2019 at 12:55 PM John Blum wrote:
> @Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar. I never
> heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.
>
> On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett
>
@Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar. I never
heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.
On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett wrote:
> Udo,
>
> I didn’t say we shouldn’t fix it for the future. I said I don’t believe it
> warrants a
Udo,
I didn’t say we shouldn’t fix it for the future. I said I don’t believe it
warrants a backport and a patch release.
-Jake
@Jake, whilst I agree with your statement that there is a preference
that sers use GFSH to manage their clusters. With that statement are you
also making a blanket statement we should remove the exposed public
API's we expose in GEODE to start a Client/Server/Locator?
IF the expected usage of
-1 for updating previous releases or merging into the current release. I see no
overwhelming need to have these published so that a downstream project can
subvert the prescribed why of starting a server with all its dependencies. A
workaround to this issue is to depend on the full distribution
@Anthony, you must have missed the LACK OF excitement in that
question... 1.8.x should stay as is... I was merely asking the question.
--Udo
On 9/25/19 11:58 AM, Anthony Baker wrote:
Since SBDG is fixed to Geode 1.9.x I can see an argument for backporting to
there. I’m personally not as
Since SBDG is fixed to Geode 1.9.x I can see an argument for backporting to
there. I’m personally not as excited about a new 1.8 patch release but I’m
open to hearing your ideas :-)
Anthony
> On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer wrote:
>
> So it seems there is consensus around jar
So it seems there is consensus around jar vs war. WAR's win by nose.
(until we can find a more creative way to expose said artifacts)
That said, do we need to start another thread about fixing 1.8.x or 1.9.x?
I'm already considering proposing that GEODE-7241 is included into
1.9.2, as that
> On Sep 25, 2019, at 11:01 AM, John Blum wrote:
> -1 to publishing a GWAR file. These are still valid WAR files regardless
> of the dependencies they provide or don't provide (which is a documentation
> concern in my mind).
Just to be really clear, GWAR was a joke and a reference to the
It occurred to me after *Charlie* shared the link to installing *Pulse* in
a standalone Servlet Container (e.g. Apache Tomcat) that we don't properly
describe how to handle the Geode dependencies (e.g. geode-core). Again,
this is not bundled as part of the Geode WAR files.
-1 to publishing a
Thanks for the reminder. If these files are required to start a geode member,
I agree they should be published artifacts. Perhaps there’s a better way to
pull them in…but this seems like the best option for now.
Anthony
> On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer wrote:
>
> @Anthony.
@Anthony. Ticket was updated.. In a nutshell, to run integration tests,
using the REST endpoints, requires the starting of the server with and
embedded web-server.
As all tests run on dependency management only and don't have access to
a downloaded product, the HTTP endpoints are not part of
Just incase here is the docs on pushing the war:
https://geode.apache.org/docs/guide/16/tools_modules/pulse/pulse-hosted.html
On Wed, Sep 25, 2019 at 9:53 AM Jacob Barrett wrote:
>
>
> > On Sep 25, 2019, at 9:33 AM, Dan Smith wrote:
> >
> > +1 to making them .GWAR instead :)
>
> Ok I think
> On Sep 25, 2019, at 9:33 AM, Dan Smith wrote:
>
> +1 to making them .GWAR instead :)
Ok I think this constitutes consensus on GWAR! ;)
+1 to Jens and John comments.
I'm 100% sure some of our users certainly deploy the *war* file (at least
the *PULSE* one) to external web application servers.
Cheers.
On Wed, Sep 25, 2019 at 5:07 PM Jens Deppe wrote:
> I also cannot recall any reason as to the need to *publish* wars.
>
>
I could see value in publishing the war files, if geode will actually pick
up the war file from the classpath and deploy it when these features are
enabled. Udo - it looks like you actually made a change with GEODE-5660 to
enable that?
+1 to making them .GWAR instead :)
-Dan
On Wed, Sep 25,
I also cannot recall any reason as to the need to *publish* wars.
However, please do not change the files to .jar. To John's point, despite
the lack of some dependent jars, the structure still conforms to a .war
format.
--Jens
On Wed, Sep 25, 2019 at 8:40 AM John Blum wrote:
> Actually, to
Actually, to clarify 2 points.
1. Technically, it is a bit more involved than simply just validating the
"format". For instance, the web.xml file must be valid and well-formed.
2. There was a reason why the geode-core and other Apache Geode libs were
not bundled in WEB-INF/lib of the WAR files,
Udo,
Can you update GEODE-7241 to help us understand the reason why we need to
publish geode-web* WARs to maven? I get that we used to do this but I can’t
recall why we choose that approach.
There is one request for Pulse on maven (GEODE-6208).
Anthony
> On Sep 24, 2019, at 3:44 PM, Udo
Bundling "all" dependencies in a WAR file is a rather subjective topic
since, typically, in practice developers did not bundle things like JDBC
drivers in a WAR file for their Web app. Common practice was to put
"shared" libs in the Servlet Containers global libs directory (using the
Common
Seems these should have been Jars all along...
On 9/24/19 8:09 PM, Jacob Barrett wrote:
Why publish them as WAR files at all? As they are currently packaged they can't
be deployed in just any J2EE web container because they lack all the
dependencies. Sure they look like WAR files internally
Why publish them as WAR files at all? As they are currently packaged they can't
be deployed in just any J2EE web container because they lack all the
dependencies. Sure they look like WAR files internally but they are really
modules that expect to run in and only in the Geode server. Publishing
For context, these are the docs for running Pulse as stand alone
https://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_795C97B46B9843528961A094EE520782
The instructions always seemed odd since we tell folks to go "tools/pulse"
to copy the pulse.war file to their
Maybe the better question is, WHY are we publishing geode-web and
geode-web-api.
Pulse, from what I remember, could be a standalone deployment. At least
that is what I remember.
Most likely an oversight...
--Udo
On 9/24/19 3:38 PM, Robert Houghton wrote:
The geode-pulse module also builds
The geode-pulse module also builds a war, but does not publish it. Is this
an oversight, or by design?
On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton
wrote:
> I am working on the change to get the geode-web and geode-web-api war
> artifacts published instead of the jars. I have found the
>
I am working on the change to get the geode-web and geode-web-api war
artifacts published instead of the jars. I have found the
geode-web-management project is also producing a war artifact, in addition
to a jar. Do we want it to be published as well? What is the criterion we
use to decide?
I
29 matches
Mail list logo
