Details
-
Type:
Feature Request
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 1.1.0-alpha-1
-
Component/s: None
-
Labels:None
Description
A interesting feature would be to be able to add listeners for events on ContainerTypes or paths.
/META-INF/* or all events generated via ClassContainer
usecase 1, if/when we add something like a ManifestDescriptor, instead of having it like the WebArchiveDescriptor.addServlet, adding a addMenifestLibrary that delegates down to addLibrary and update the 'classpath: ' manifest entry.. we could register a listener on the LibraryContainer and get callbacks when a 'normal' addLibrary happens
usecase 2, could deploy a 'live' archive to embedded.. one could register a listener on all changes in the archive and auto redeploy it on events..
deploy it once, redeploy on change
Gliffy Diagrams
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
In it's simples form:
Archive:
/**
- Add a listener for call back based on a specific filter.
- @param filter Filter to match for this {@link Listener}
- @param listener CallBack on add
- @return This archive
*/
T addListener(Filter<ArchivePath> filter, Listener listener);
Listener:
public interface Listener
{
/**
- CallBack when a
{@link Asset}
is added to a specific
{@link ArchivePath}.
- @param archivePath Where in the
{@link Archive} it is being added.
* @param asset What is being added
* @return the Asset to insert into the {@link Archive}, null to not add.
*/
Asset added(ArchivePath archivePath, Asset asset);
}
MemoryMapArchiveBase:
@Override
public T add(Asset asset, ArchivePath path)
{
Validate.notNull(asset, "No asset was specified");
Validate.notNull(path, "No path was specified");
Asset listenerAsset = invokeListeners(path, asset);
........
// should support listener chaining, not just the first one found?
private Asset invokeListeners(ArchivePath path, Asset asset)
{
for(Map.Entry<Filter<ArchivePath>, Listener> listenerEntry : listeners.entrySet())
{
if(listenerEntry.getKey().include(path))
}
return asset;
}
Aslak Knutsen
added a comment - In it's simples form:
Archive:
/**
Add a listener for call back based on a specific filter.
@param filter Filter to match for this
{@link Listener}
@param listener CallBack on add
@return This archive
*/
T addListener(Filter<ArchivePath> filter, Listener listener);
Listener:
public interface Listener
{
/**
CallBack when a
{@link Asset}
is added to a specific
{@link ArchivePath}
.
@param archivePath Where in the
{@link Archive} it is being added.
* @param asset What is being added
* @return the Asset to insert into the {@link Archive}
, null to not add.
*/
Asset added(ArchivePath archivePath, Asset asset);
}
MemoryMapArchiveBase:
@Override
public T add(Asset asset, ArchivePath path)
{
Validate.notNull(asset, "No asset was specified");
Validate.notNull(path, "No path was specified");
Asset listenerAsset = invokeListeners(path, asset);
........
// should support listener chaining, not just the first one found?
private Asset invokeListeners(ArchivePath path, Asset asset)
{
for(Map.Entry<Filter<ArchivePath>, Listener> listenerEntry : listeners.entrySet())
{
if(listenerEntry.getKey().include(path))
{
return listenerEntry.getValue().added(path, asset);
}
}
return asset;
} What about something like this:
Archive:
T addListener(Listener listener);
|
MemoryMapArchiveBase:
private Asset invokeListeners(ArchivePath path, Asset asset)
|
{
|
foreach (Listener listener : listeners) {
|
{
|
listener.added(path, asset);
|
}
|
return asset;
|
}
|
In this case the decision to intercept the add operation is left to the listener.
WDT?
Davide D'Alto
added a comment - What about something like this:
Archive:
T addListener(Listener listener);
MemoryMapArchiveBase:
private Asset invokeListeners(ArchivePath path, Asset asset)
{
foreach (Listener listener : listeners) {
{
listener.added(path, asset);
}
return asset;
}
In this case the decision to intercept the add operation is left to the listener.
WDT? Holding this feature on deck in upstream/SHRINKWRAP-85 until we lift the feature freeze or make a 1.1.x development line. May be resolved when this hits the upstream.
Andrew Rubinger
added a comment - Holding this feature on deck in upstream/ SHRINKWRAP-85 until we lift the feature freeze or make a 1.1.x development line. May be resolved when this hits the upstream.
https://github.com/shrinkwrap/shrinkwrap/tree/SHRINKWRAP-85 Andrew Rubinger
added a comment - Upstream: https://github.com/shrinkwrap/shrinkwrap/commit/b62f29f81c1f5bce2b4cee3be2c5c10ab7e5cc3b 
usecase 3, changing the Asset content. This opens up for Package time class manipulation / properties filtering etc