[
https://issues.apache.org/jira/browse/OOZIE-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007929#comment-14007929
]
Robert Kanter commented on OOZIE-1760:
--------------------------------------
While putting additional jars in the sharelib will work, it's not considered a
good practice for a number of reasons.
There are 3 other ways to include jars with your workflows/actions that you
should use instead. A recent blog post I wrote included a summary of these
ways and their pros and cons:
----
Below are the various ways to include a jar with your workflow:
# Set {{oozie.libpath=/path/to/jars,another/path/to/jars}} in job.properties.
#- This is useful if you have many workflows that all need the same jar; you
can put it in one place in HDFS and use it with many workflows. The jars will
be available to all actions in that workflow.
#- There is no need to ever point this at the ShareLib location. (I see that in
a lot of workflows.) Oozie knows where the ShareLib is and will include it
automatically if you set {{oozie.use.system.libpath=true}} in job.properties.
# Create a directory named “lib” next to your workflow.xml in HDFS and put jars
in there.
#- This is useful if you have some jars that you only need for one workflow.
Oozie will automatically make those jars available to all actions in that
workflow.
# Specify the {{<archive>}} tag in an action with the path to a single jar; you
can have multiple {{<archive>}} tags.
#- This is useful if you want some jars only for a specific action and not all
actions in a workflow.
#- The downside is that you have to specify them in your workflow.xml, so if
you ever need to add/remove some jars, you have to change your workflow.xml.
# Add jars to the ShareLib (e.g. {{/user/oozie/share/lib/lib_<timestamp>/pig}})
#- While this will work, it’s not recommended for two reasons:
#- The additional jars will be included with every workflow using that
ShareLib, which may be unexpected to those workflows and users.
#- When upgrading the ShareLib, you’ll have to recopy the additional jars to
the new ShareLib.
----
source:
http://blog.cloudera.com/blog/2014/05/how-to-use-the-sharelib-in-apache-oozie-cdh-5/
A "java" sharelib is problematic in particular because it can be used for many
different things by many different users. For example, what happens if you put
some HBase jars in the "java" sharelib to make your Java action talk to HBase,
but so does another user and they need a different version of the HBase jars?
Or what if someone wants to run something else? They're going to automatically
get the HBase jars even though they don't need them (and maybe they'll cause a
conflict with jars they do need).
> Set default shared lib dir for java action
> ------------------------------------------
>
> Key: OOZIE-1760
> URL: https://issues.apache.org/jira/browse/OOZIE-1760
> Project: Oozie
> Issue Type: Improvement
> Components: action
> Affects Versions: 3.3.2
> Reporter: Hersh Shafer
> Priority: Minor
> Fix For: trunk
>
> Attachments: set_getDefaultShareLibName_as_java.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Change {{JavaActionExecutor.getDefaultShareLibName()}} to return "java".
> Currently it returns null.
> In all descendants this method returns dir name according to the action name.
> It required for using default oozie hdfs path (/user/oozie/shared/lib/java)
> as cllasspath in java action
--
This message was sent by Atlassian JIRA
(v6.2#6252)
