On Wed, May 13, 2009 at 12:31 AM, Simon Nash <[email protected]> wrote: > I investigated this a bit more. There is a simple change that can > be made to the launcher code to avoid loading contribution code from > the classpath. Instead of the node-jumpstart code using the interface > com.goodvaluetrips.Trips to call the contribution code, the > node-jumpstart code can include a compatible interface scatours.Trips > that is loaded from the classpath. This avoids the need to load the > interface com.goodvaluetrips.Trips from the classpath. > > I tested this and it works. I changed the launcher code in the > jumpstart-launcher directory in the new structure to do this, but > I did not change the code in chapter-02/node-jumpstart. > > Simon > > Simon Nash wrote: >> >> I noticed that the launcher in chapter02/node-jumpstart puts the >> goodvaluetrips-contribution code on the classpath. In general it >> isn't a good idea to put contribution code on the classpath because >> this prevents the classes in the contribution from being loaded by >> the contribution class loader, which means that import.java and >> export.java don't work properly. >> >> In the launcher in chapter-02/node there is an example of how >> the code can be factored so that no contribution code appears on >> the classpath but instead is loaded by its contribution class loader. >> This requires an additional contribution for the client code, which >> is separate from the launcher instead of being part of it. >> >> Is there a reason why node-jumpstart needs to put the client code >> and contribution code on the classpath? If not, I think it would be >> better to use the pattern in chapter-02/node for all the launchers >> in the travel sample. >> >> Simon
Ok, that sounds like a reasonable approach. I'll start looking at the new about the old version. Simon
