Bug 282269

Comment 1 Rob Stryker 2009-07-02 05:29:41 EDT

Created attachment 140678 [details]
non-behavior-changing cleanup

No behaviour should change from this patch... it just makes subclassing a bit easier and also makes the code a bit cleaner. 

I would like to see this for 3.2

Comment 2 Rob Stryker 2009-07-02 09:32:14 EDT

Created attachment 140694 [details]
Addition of an extension point

I believe my new patch is much better, though more in depth.
Officially it changes no behaviour as the flow of execution should be pretty much identical, however it adds an extension point. The primary functionality of this point is one place to turn an IVirtualReference into a ReferencedComponent, and back. 

The benefit here is that if the component.xml file has some weird dependency uri inside it, such as "module:/robs/secret/sauce", typically it is the VirtualComponent's job to turn this ReferencedComponent into an actual IVirtualReference. And invariably the default implementation will not find the actual correct VirtualComponent in order to instantiate it, as componentcore knows absolutely nothing about rob's secret sauce.

Now, however, an extension point can be provided to turn this reference into a solid IVirtualComponent rather than just confusing the code in StructureEdit. The patch also helps to consolidate some of the code that was repetitive in one place.

Comment 3 Rob Stryker 2009-07-02 10:28:55 EDT

I would like to see this targeted in teh 3.2 branch if possible. 

Comment 4 Rob Stryker 2009-07-08 06:50:00 EDT

For those who don't want to go dig through the patch, the suggested API is something like this:


 public interface IReferenceResolver {
 	public boolean canResolve(IVirtualComponent context, ReferencedComponent referencedComponent);
 	public IVirtualReference resolve(IVirtualComponent context, ReferencedComponent referencedComponent);
 	public boolean canResolve(IVirtualReference reference);
 	public ReferencedComponent resolve(IVirtualReference reference);
 }

This would allow any VirtualComponent objects to turn any handle into some type of virtual component and expose it as a reference. This would also allow wst.server type modules to expose these references as child modules. 

Comment 5 Rob Stryker 2009-09-09 19:10:21 EDT

Hey Chuck:

I was wondering if you could review this API addition for M2. Thanks.

Comment 6 Chuck Bridgham 2009-09-21 13:46:41 EDT

Reviewing this for M3 inclusion....  marked for plan

Comment 7 Chuck Bridgham 2009-09-30 23:39:41 EDT

I "finally" have reviewed this change, and verify the "default" dependency resolution hasn't changed behavior.  I approve these changes

Comment 8 Chuck Bridgham 2009-10-01 00:58:10 EDT

Ok ran into one NPE if "no" resolvers are found....

I changed this method on ReferenceResolverUtil

public IReferenceResolver[] getResolvers() {
		if( resolvers == null )
			loadResolvers();
		if (sorted.isEmpty()) return new IReferenceResolver[0];
		return (IReferenceResolver[]) sorted.toArray(new IReferenceResolver[sorted.size()]);
	}

Comment 9 Carl Anderson 2009-10-01 14:49:15 EDT

Created attachment 148568 [details]
Addition of an extension point plus 2 NPE fixes

I had to add a call, first thing, in the following method:

public IReferenceResolver getResolver(IVirtualReference reference) {
     getResolvers();

Otherwise, running the Java EE JUnits would not even work- we would get an InvocationException due to the NPE that occurs when it tries to reference sorted.iterator();

Comment 10 Carl Anderson 2009-10-01 15:31:11 EDT

Committed to HEAD for WTP 3.2.