Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 329878 - Blocking enhancement request for our product; ignoring inaccessible projects
Summary: Blocking enhancement request for our product; ignoring inaccessible projects
Status: RESOLVED FIXED
Alias: None
Product: WTP ServerTools
Classification: WebTools
Component: wst.server (show other bugs)
Version: 3.2   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.2.3   Edit
Assignee: Angel Vera CLA
QA Contact: Angel Vera CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-10 04:58 EST by Rob Stryker CLA
Modified: 2017-10-11 16:35 EDT (History)
0 users

See Also:


Attachments
Extracts the continue call (1.21 KB, patch)
2010-11-10 04:59 EST, Rob Stryker CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rob Stryker CLA 2010-11-10 04:58:50 EST
Currently when a publish request comes in for a module which has an inaccessible project, that request is ignored with a simple "continue" call. Our product (and I'll probably push this into JEE Tools if it works first) wants to enable deletion participants, which lead to inacessible projects.

The reason we want to use deletion participants is because during a deletion event, the project still exists, as does its module, which means a publish request can still cast into the module delegate's class (and other subclasses) to get custom module information. If the publish request happens AFTER the deletion, our publishers only get access to a DeletedModule, which is next ot useless for us.

I would like to see the ignoring extracted into a protected method.
Comment 1 Rob Stryker CLA 2010-11-10 04:59:50 EST
Created attachment 182797 [details]
Extracts the continue call
Comment 2 Rob Stryker CLA 2010-11-10 11:17:04 EST
Angel give this a look if you can...
Comment 3 Angel Vera CLA 2010-11-10 16:29:56 EST
Seems small and reasonable. The implementation doesn't seem to affect other server adopters as a new method (API) is created that defaults to the current behaviour. Thus no change in behaviour for adopters. 

I have to double check but we should be able to get this into 323 because of the above statement.

The only question I have are: 
- no javadocs?
- what kind of refression testing was done?
Comment 4 Angel Vera CLA 2010-12-08 15:14:09 EST
changes committed to HEAD with the corresponding java doc. I tested a few scenarios no impact.
Comment 5 Angel Vera CLA 2010-12-08 15:17:45 EST
changes committed to 32M
Comment 6 Angel Vera CLA 2010-12-08 16:09:52 EST
released to 32M
Comment 7 Angel Vera CLA 2010-12-08 16:10:00 EST
released to HEAD
Comment 8 Angel Vera CLA 2010-12-08 16:10:14 EST
fixed
Comment 9 Eclipse Genie CLA 2017-10-11 16:35:20 EDT
New Gerrit change created: https://git.eclipse.org/r/109006