FAQ
As new custom buildpacks are developped, new app file formats will arise
(e.g. .ear or .phar ...). The current cfoundry client has a limited number
of patterns that it supports[1] and preprocesses/unzips. New unsupported
patterns are not detected as archives and thus not unzipped. This results
in buildpacks having to unzip the archive themselves, and make special
handling: for instance, the jonas container class [2] need to handle wars
as unzipped directories while ears are plain files.

I'm also suspecting unsupported formats won't benefit from the fingerprints
that allow to save bandwidth on uploads and would require the whole app
binary to be transmitted at each push.

Could we find a way to uniformly handle app formats/extensions so that
upcoming extensions in new buildpacks don't have to assume/handle the
special handling ? Could we imagine the buildpack to be used to express the
supported archive extensions, so that new extension dynamically get
registred in cfoundry. Should buildpack authors merely ask for a cfoundry
update for new 'zip' extensions to support ?

BTW, for wars, the default behavior of unzipping the war is kind of
lossless: the original app name is lost in the unzipping process.
Buildpacks that would like to expose apps on path relative to the war name
can't easily currently do this. How can buildpack authors for supported
types could retreive the original file name, or possibly control whether to
leave app bits are zipped/unzipped ?

Thanks in advance,

Guillaume.

[1]
https://github.com/cloudfoundry/cfoundry/blob/master/lib/cfoundry/upload_helpers.rb#L57
[2]
https://github.com/Orange-OpenSource/java-buildpack/blob/jonas/docs/container-jonas.md

Search Discussions

  • Ben Hale at Jul 15, 2013 at 4:39 pm

    BTW, for wars, the default behavior of unzipping the war is kind of
    lossless: the original app name is lost in the unzipping process.
    Buildpacks that would like to expose apps on path relative to the war name
    can't easily currently do this. How can buildpack authors for supported
    types could retreive the original file name, or possibly control whether to
    leave app bits are zipped/unzipped ?
    I can't speak to the first part of your question (my experience starts at
    the staging interface), but for this part I think I can provide some
    clarification. In the case that a single WAR file is pushed (let's just
    assume WARs for simplicity's sake) the name of the WAR file is indeed lost.
      However, this application should be exposed at the root URL of the
    application eliminating the need for the name to be preserved. In the case
    where a whole collection of WARs is pushed (n.b. this isn't supported by
    any of the official buildpacks) only the top level directory/archive looses
    it's name. The WARs that were contained within would retain their names
    and then could be referenced by their peers.

    -Ben Hale
    Cloud Foundry Java Experience
  • Scott Frederick at Jul 15, 2013 at 7:17 pm
    The CF clients only unzip the first level of archives on push - zip, jar,
    and war files contained in the pushed file are not exploded. So, archive
    files can be pushed intact by wrapping them in a zip file. We had a
    scenario recently where an OSGi container needed jar files left intact for
    the buildpack to process, and used this technique successfully.

    I'm not suggesting this is the answer to the points you are making, but it
    can be used as a work-around for the cases where a buildpack needs to
    process an archive instead of an exploded archive.

    Scott
    On Monday, July 15, 2013 4:33:23 AM UTC-5, Guillaume Berche wrote:

    As new custom buildpacks are developped, new app file formats will arise
    (e.g. .ear or .phar ...). The current cfoundry client has a limited number
    of patterns that it supports[1] and preprocesses/unzips. New unsupported
    patterns are not detected as archives and thus not unzipped. This results
    in buildpacks having to unzip the archive themselves, and make special
    handling: for instance, the jonas container class [2] need to handle wars
    as unzipped directories while ears are plain files.

    I'm also suspecting unsupported formats won't benefit from the
    fingerprints that allow to save bandwidth on uploads and would require the
    whole app binary to be transmitted at each push.

    Could we find a way to uniformly handle app formats/extensions so that
    upcoming extensions in new buildpacks don't have to assume/handle the
    special handling ? Could we imagine the buildpack to be used to express the
    supported archive extensions, so that new extension dynamically get
    registred in cfoundry. Should buildpack authors merely ask for a cfoundry
    update for new 'zip' extensions to support ?

    BTW, for wars, the default behavior of unzipping the war is kind of
    lossless: the original app name is lost in the unzipping process.
    Buildpacks that would like to expose apps on path relative to the war name
    can't easily currently do this. How can buildpack authors for supported
    types could retreive the original file name, or possibly control whether to
    leave app bits are zipped/unzipped ?

    Thanks in advance,

    Guillaume.

    [1]
    https://github.com/cloudfoundry/cfoundry/blob/master/lib/cfoundry/upload_helpers.rb#L57
    [2]
    https://github.com/Orange-OpenSource/java-buildpack/blob/jonas/docs/container-jonas.md
  • Guillaume Berche at Jul 15, 2013 at 7:28 pm
    Thanks Scott and Ben for your answers. Yes, I currently worked around the
    issue by renaming "myapp.ear" into "myapp.war" and leaving the same
    content. The buildpack then detects both the META-INF/application.xml for
    EARs and WEB-INF/web.xml for WARs in the exploded archives it receives from
    the push process. But this is not satisfactory from the user point-of-view
    to have to perform this manual renaming, or wrapping into an additional zip.

    The "lossy" push process can become problematic at times if a particular
    buildpack needs to access the original file extension (e.g. to trigger
    different behavior between top-level .war and .jar files)

    Guillaume.

    On Mon, Jul 15, 2013 at 9:17 PM, Scott Frederick wrote:

    The CF clients only unzip the first level of archives on push - zip, jar,
    and war files contained in the pushed file are not exploded. So, archive
    files can be pushed intact by wrapping them in a zip file. We had a
    scenario recently where an OSGi container needed jar files left intact for
    the buildpack to process, and used this technique successfully.

    I'm not suggesting this is the answer to the points you are making, but it
    can be used as a work-around for the cases where a buildpack needs to
    process an archive instead of an exploded archive.

    Scott

    On Monday, July 15, 2013 4:33:23 AM UTC-5, Guillaume Berche wrote:

    As new custom buildpacks are developped, new app file formats will arise
    (e.g. .ear or .phar ...). The current cfoundry client has a limited number
    of patterns that it supports[1] and preprocesses/unzips. New unsupported
    patterns are not detected as archives and thus not unzipped. This results
    in buildpacks having to unzip the archive themselves, and make special
    handling: for instance, the jonas container class [2] need to handle wars
    as unzipped directories while ears are plain files.

    I'm also suspecting unsupported formats won't benefit from the
    fingerprints that allow to save bandwidth on uploads and would require the
    whole app binary to be transmitted at each push.

    Could we find a way to uniformly handle app formats/extensions so that
    upcoming extensions in new buildpacks don't have to assume/handle the
    special handling ? Could we imagine the buildpack to be used to express the
    supported archive extensions, so that new extension dynamically get
    registred in cfoundry. Should buildpack authors merely ask for a cfoundry
    update for new 'zip' extensions to support ?

    BTW, for wars, the default behavior of unzipping the war is kind of
    lossless: the original app name is lost in the unzipping process.
    Buildpacks that would like to expose apps on path relative to the war name
    can't easily currently do this. How can buildpack authors for supported
    types could retreive the original file name, or possibly control whether to
    leave app bits are zipped/unzipped ?

    Thanks in advance,

    Guillaume.

    [1] https://github.com/**cloudfoundry/cfoundry/blob/**
    master/lib/cfoundry/upload_**helpers.rb#L57<https://github.com/cloudfoundry/cfoundry/blob/master/lib/cfoundry/upload_helpers.rb#L57>
    [2] https://github.com/Orange-**OpenSource/java-buildpack/**
    blob/jonas/docs/container-**jonas.md<https://github.com/Orange-OpenSource/java-buildpack/blob/jonas/docs/container-jonas.md>
  • Ben Hale at Jul 15, 2013 at 8:21 pm

    The "lossy" push process can become problematic at times if a particular
    buildpack needs to access the original file extension (e.g. to trigger
    different behavior between top-level .war and .jar files)
    In general (since we do already discriminate between JARs and WARs) we've
    found that you don't actually need the archive's extension to determine
    what to do. So for example, after poring over the Servlet spec, we can say
    that the indicator that something is a WAR file is the existence of a
    WEB-INF/ directory. I'd guess that with enough reasoning, it's possible to
    figure out what constitutes a particular archive type based on it's
    contents rather than it's extension.

    -Ben Hale
    Cloud Foundry Java Experience

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupvcap-dev @
postedJul 15, '13 at 9:33a
activeJul 15, '13 at 8:21p
posts5
users3

People

Translate

site design / logo © 2021 Grokbase