Cargo

Make expanded WAR a proper deployable type

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 0.7
  • Fix Version/s: None
  • Component/s: Core
  • Labels:
    None
  • Number of attachments :
    0

Description

This will make it more visible if expanded WAR are supported or not by the different containers using the ContainerCapability.supportsDeployableType(DeployableType).

Issue Links

is related to

Improvement - An improvement or enhancement to an existing feature or task. CARGO-341 FileHandler should support an operation that explodes a war

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Improvement - An improvement or enhancement to an existing feature or task. CARGO-902 Consolidate Deployable.isExpanded() and isExpanded*()

  • Trivial - Cosmetic problem like misspelt words or misaligned text.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Bentmann added a comment -

IMHO, it's not ideal to merge the (content) type of a deployable and its file organization (packed/expanded) into one value. I think adding ContainerCapability.supportsDeployable(DeployableType type, boolean expanded) would make more sense.

On the other hand. does it really matter whether a container natively supports packaged/expanded WARs? The container-specific deployers could also pack/unpack the deployables on the fly if needed, couldn't they?

Show
Benjamin Bentmann added a comment - IMHO, it's not ideal to merge the (content) type of a deployable and its file organization (packed/expanded) into one value. I think adding ContainerCapability.supportsDeployable(DeployableType type, boolean expanded) would make more sense. On the other hand. does it really matter whether a container natively supports packaged/expanded WARs? The container-specific deployers could also pack/unpack the deployables on the fly if needed, couldn't they?
Hide
Permalink
Anders Hammar added a comment -

After going through this code for a different ticket, I agree with Benjamin. Making these abstractions would simplify the code and the logic. However, it would require some modifications to the Cargo API I believe.

Show
Anders Hammar added a comment - After going through this code for a different ticket, I agree with Benjamin. Making these abstractions would simplify the code and the logic. However, it would require some modifications to the Cargo API I believe.
Hide
Permalink
Savas Ali Tokmen added a comment -

Generally, applications that deploy theirselves as expanded (WARs, most notably) have their own reasons for doing so (such as, for example, application data being stored in the expanded WAR's directory).

So, automatically packing/expanding could be a bad idea.

Also, would expanded WAR type expand the existing WAR type? If yes, containers would need to check with more caution, as instanceof WAR would not work, you would need to check if instanceof WAR and not instanceof ExpandedWAR.

Show
Savas Ali Tokmen added a comment - Generally, applications that deploy theirselves as expanded (WARs, most notably) have their own reasons for doing so (such as, for example, application data being stored in the expanded WAR's directory). So, automatically packing/expanding could be a bad idea. Also, would expanded WAR type expand the existing WAR type? If yes, containers would need to check with more caution, as instanceof WAR would not work, you would need to check if instanceof WAR and not instanceof ExpandedWAR.

People

  • Assignee:
    Unassigned
    Reporter:
    Vincent Massol
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: