[
https://issues.apache.org/jira/browse/GEODE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-2289:
-----------------------------
Description:
Feature request: add a "deploy resource" command that can be used to deploy
dependency jars (such as Spring jars) and application config files (such Spring
xml files) to servers. Servers would then store these files to a subdir under
its working directory. Subsequent start server commands could then reference
the deployed jars on its --classpath.
Comparison to "deploy jar": this command does not scan and load Functions or
other Callbacks from the jar file. Deploy jar command is currently only used to
deploy implementations of Apache Geode callback interfaces (Function,
CacheListener, etc). Attempting to deploy a dependency jar with optional
transitive dependencies will result in NoClassDefFoundErrors because deploy
loads every class in the jar, inspects it to determine if it's a Function and
then auto-registers it if it is.
Email proposal and discussion thread on dev@geode.apache.org:
http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3CCANZq1gDhf7st27YsKCBEQo8Cd1PVcQMfA3b_qu4_PM%3DrwS5dxA%40mail.gmail.com%3E
Current status: the community rejected this proposal.
Text of initial proposal email (see above link):
Some application may need to copy files to all the servers. These files
could either be data files or they could be configuration files needed by
the application or they could be jar files (that don't have functions but
have say, spring data geode jar files) that need to be on the server's
classpath.
We could accomplish this by enhancing the current gfsh "deploy" command to
accept any kind of file and write it to the servers file system OR create a
new gfsh "copy" command to copy any arbitrary file to the servers.
I would personally like to repurpose the deploy command but would like to
hear the community's opinion.
was:
Feature request: add a "deploy resource" command that can be used to deploy
dependency jars (such as Spring jars) and application config files (such Spring
xml files) to servers. Servers would then store these files to a subdir under
its working directory.
Comparison to "deploy jar": this command does not scan and load Functions or
other Callbacks from the jar file. Deploy jar command is currently only used to
deploy implementations of Apache Geode callback interfaces (Function,
CacheListener, etc). Attempting to deploy a dependency jar with optional
transitive dependencies will result in NoClassDefFoundErrors because deploy
loads every class in the jar, inspects it to determine if it's a Function and
then auto-registers it if it is.
Email proposal and discussion thread on dev@geode.apache.org:
http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3CCANZq1gDhf7st27YsKCBEQo8Cd1PVcQMfA3b_qu4_PM%3DrwS5dxA%40mail.gmail.com%3E
Current status: the community rejected this proposal.
Text of initial proposal email (see above link):
Some application may need to copy files to all the servers. These files
could either be data files or they could be configuration files needed by
the application or they could be jar files (that don't have functions but
have say, spring data geode jar files) that need to be on the server's
classpath.
We could accomplish this by enhancing the current gfsh "deploy" command to
accept any kind of file and write it to the servers file system OR create a
new gfsh "copy" command to copy any arbitrary file to the servers.
I would personally like to repurpose the deploy command but would like to
hear the community's opinion.
> Request: add deploy resource command to deploy dependency jars and
> application specific files
> ---------------------------------------------------------------------------------------------
>
> Key: GEODE-2289
> URL: https://issues.apache.org/jira/browse/GEODE-2289
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
> Reporter: Kirk Lund
>
> Feature request: add a "deploy resource" command that can be used to deploy
> dependency jars (such as Spring jars) and application config files (such
> Spring xml files) to servers. Servers would then store these files to a
> subdir under its working directory. Subsequent start server commands could
> then reference the deployed jars on its --classpath.
> Comparison to "deploy jar": this command does not scan and load Functions or
> other Callbacks from the jar file. Deploy jar command is currently only used
> to deploy implementations of Apache Geode callback interfaces (Function,
> CacheListener, etc). Attempting to deploy a dependency jar with optional
> transitive dependencies will result in NoClassDefFoundErrors because deploy
> loads every class in the jar, inspects it to determine if it's a Function and
> then auto-registers it if it is.
> Email proposal and discussion thread on dev@geode.apache.org:
> http://mail-archives.apache.org/mod_mbox/geode-dev/201701.mbox/%3CCANZq1gDhf7st27YsKCBEQo8Cd1PVcQMfA3b_qu4_PM%3DrwS5dxA%40mail.gmail.com%3E
> Current status: the community rejected this proposal.
> Text of initial proposal email (see above link):
> Some application may need to copy files to all the servers. These files
> could either be data files or they could be configuration files needed by
> the application or they could be jar files (that don't have functions but
> have say, spring data geode jar files) that need to be on the server's
> classpath.
> We could accomplish this by enhancing the current gfsh "deploy" command to
> accept any kind of file and write it to the servers file system OR create a
> new gfsh "copy" command to copy any arbitrary file to the servers.
> I would personally like to repurpose the deploy command but would like to
> hear the community's opinion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
