Community
Participate
Working Groups
Some small cleanup on VirtualComponent. The primary action I've done is create two more protected methods: protected IVirtualReference createVirtualReference( ReferencedComponent) protected URI getHandle(IVirtualReference reference) Then I made each method call these instead. I feel that this pulling apart is a bit cleaner, but also allows for easier subclassing and support for new or different handles without having to override every method in the superclass.
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
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.
I would like to see this targeted in teh 3.2 branch if possible.
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.
Hey Chuck: I was wondering if you could review this API addition for M2. Thanks.
Reviewing this for M3 inclusion.... marked for plan
I "finally" have reviewed this change, and verify the "default" dependency resolution hasn't changed behavior. I approve these changes
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()]); }
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();
Committed to HEAD for WTP 3.2.
