JDF 159 - Demonstrate usage of Deactivateable from Deltaspike updating relevant Quickstarts that uses Extension #371
Conversation
|
The Deactivateable feature was added to cdi-portable-extension and cdi-veto quickstarts. But I'm now wondering if we should keep just on cdi-portable-extension to avoid any confusion that could exist mixing a veto with deactivateable. What you think? |
|
I don't think we want it on every CDI extension, just the ones using DeltaSpike. Pulling in DS for two classes in an already small extension seems overkill to me. The idea is they demonstrate one concept, so we shouldn't needlessly be confusing the users. Sent from my iPhone On Dec 10, 2012, at 7:48, Rafael Benevides notifications@github.com wrote:
|
|
Ok. So I'll revert the cdi-veto quickstart and keep on cdi-portable-extension only. Thanks |
|
Will create another QS that shows how to deactivate an existing DeltaSpike extension |
| What is it? | ||
| ----------- | ||
|
|
||
| DeltaSpike artifacts can be deactivated manually (e.g. to improve the performance if a part isn't needed, to provide a custom implementation if the default implementation isn't pluggable by default or to bypass an implementation which causes an issue). |
There was a problem hiding this comment.
As we are demonstrating this facility, we should say "DeltaSpike allows..."
|
Looks good beyond the minor issues commented on. |
| @@ -0,0 +1,122 @@ | |||
| DeltaSpike Deactivateable: Demonstrate usage of Deactivateable | |||
There was a problem hiding this comment.
Use quickstart name before colon.
s/deactivateable/deactivatable
For example:
deltaspike-deactivatable: Demonstrate use of DeltaSpike Deactivatable
|
There are a few minor typos in the README file and pom.xml files where README typos:
pom.xml typos:
Other than that, this looks good to me. |
|
Looks good to me if @LightGuard and @pmuir are OK with this one. |
|
I'm happy :-) |
|
Rebased upstream, squashed commits, and merged. |
WFLY-13021 adding servlet dependency in pom.xml
No description provided.