[ https://jira.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.plug... ] Work on SHRINKWRAP-242 started by David Bosschaert. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.plug... ] David Bosschaert commented on SHRINKWRAP-242: --------------------------------------------- Quite possibly! I think having SHRINKWRAP-234 fixed certainly helps the OSGi use case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.plug... ] David Bosschaert commented on SHRINKWRAP-242: --------------------------------------------- I have a first phase of this implemented. You can find it in the shrinkwrap_osgi branch of my fork: https://github.com/bosschaert/shrinkwrap/tree/shrinkwrap_osgi Changes involved are: * Made shrinkwrap-api.jar, shrinkwrap-spi.jar and shrinkwrap-impl-base.jar OSGi bundles by adding OSGi metadata to the MANIFEST.MF. These jars are also still ordinary jars so they can be used both in an OSGi framework as well as outside of OSGi as plain jars. The OSGi metadata is added with the maven-bundle-plugin. * Created a Service API for ShrinkWrap (ShrinkWrapService) and created an implementation of it for OSGi which gets registered through the Bundle Activator in the shrinkwrap-impl-base.jar. OSGi bundles access ShrinkWrap via the Service Registry. * Tested in JBoss OSGi, Felix, Equinox. * I moved 2 classes (UnknownExtensionTypeExceptionDelegator and IOUtilDelegator) from the impl-base module to the API module, since they were causing split packages across API and Impl-Base (the org.jboss.shrinkwrap.api and org.jboss.shrinkwrap.api.asset packages belong in the API bundle). * Added tests. I did find an issue when running it in AS7 in that when addClass(SomeClass.class) or addClass("org.acme.MyClass", myclassloader) was used that somewhere down the line the ThreadContextClassLoader gets used instead of the classloader passed in to this API, but I think this is a separate issue, I've created SHRINKWRAP-244 for that. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger updated SHRINKWRAP-242: --------------------------------------- Fix Version/s: 1.0.0-beta-1 Priority: Critical (was: Major) We need to work out ASAP if API changes are required to the SW core in order to fulfill this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-242: -------------------------------------------- I don't mind things being involved in the SW side (in terms of changing the impl), but our users rather like this syntax: JavaArchive archive = ShrinkWrap.create(JavaArchive.class) ...requiring the CL to be passed in for things to work isn't likely to be embraced by our users. Sure, we could add an additional method to accept the CL, but my feeling is that folks won't use this option; then stuff will break when their archives get into AS. I'll find you on IRC to discuss further...both solutions look workable, and both also look detrimental to overall user experience. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-242: -------------------------------------------- I haven't considered that, no. What I'm thinking perhaps is a separate "ShrinkWrap Static Initializer/Config" which can accept a CL, and then use that for all subsequent static access. So if AS were to initialize for the user; no matter what API the user called, the CL set through the initializer would be the one consulted. WDYT? This is a prime reason why static access should be avoided, but ShrinkWrap is intended to be EASY, and users love this aspect of the API. (I don't see many people consulting the more manual routes that aren't static). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-242: -------------------------------------------- With regards to the timing: It'd be a mutable "reinitialization/configuration". ServiceExtensionLoader in impl-base has a cache of mappings which we could clear, and set an explicit CL (instead of the now-hardcoded TCCL). So subsequent calls using the default Domain would be rerouted to use the configured CL, and this would apply to all static calls. In other words, it'd be reconfiguring the default Domain (which is shared by the static access entry points). That avoids the need for a Service Registry. Keep in mind that for things like getting the ExecutorService used in exporting to streams, we already support a Configurtion-per-Archive. So we *could* tack onto the config a CL there too, but users wouldn't be able to use that for static access (which is tied to the default Domain). They'd have to take the more manual step of: JavaArchive archive = ShrinkWrap.createDomain(ConfigurationBuilder).getArchiveFactory().create(JavaArchive.class) ...where they define in the ConfigurationBuilder the CL to use. That's fine for services where we do something like populate a known Domain in MSC and have users inject it: @Inject Domain domain; domain.getArchiveFactory().create(JavaArchive.class) ...but not for the most simple API hook. Outstanding question: Does your Service Base approach render the static usage useless? How exactly would that work, or do you like the proposal above? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] David Bosschaert commented on SHRINKWRAP-242: --------------------------------------------- On the reinitialization - maybe I'm not understanding this properly but there is still a chance that the service is not configured correctly when I try to access it as the reconfiguration hasn't happened yet. So yes, in that case you probably need to inject something which is properly configured and this is precisely what I did in my service-based approach. However what I did instead of injecting a Domain was I injected a 'ShrinkWrapService' which had more or less the same API as the static ShrinkWrap class. So when using that you would get something like: @Inject ShrinkWrapService sws; sws.create(JavaArchive.class); They only way in which I can see that static usage is still possible is to make it stateless and independent of the TCCL or any state anywhere else so that there would be no initialization at all and the methods become simple utility methods. This would certainly be the simplest from a user's point of view. Not quite sure how to achieve this, but one way would be by merging some of the sw modules so that initialization becomes unnecessary, but in the total spectrum of solutions I might be missing something... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger edited comment on SHRINKWRAP-242 at 3/18/11 2:51 PM: --------------------------------------------------------------------- OK, so I see what you've done here with the SWS. We're getting closer to meeting in the middle. Though this might not be necessary to have a separate SWS...instead of injecting Domain you could inject ArchiveFactory directly, which already has methods to mirror the static ShrinkWrap util. This is actually why I made Domains, ArchiveFactories etc in the first place; so we could inject under a specific config (and this config would not interfere with other configs in the VM). The only problem is that users would have to inject the ArchiveFactory as obtained from MSC, and any usage of ShrinkWrap utility methods would still be OSGi non-compatible. Does this solve the issue? Will be have cases of users STILL using ShrinkWrap.create() from within the OSGi environment? I think of course we will. So let's take the two-pronged approach: 1) Add to Domain/Configuration/ArchiveFactory a CL association to be used instead of TCCL. 2) Provide mechanism to apply a given CL for static usage (effectively configuring the default Domain/Configuration). The preferred usage inside AS will be to get an ArchiveFactory from MSC. Failing that, use the static thing, which we'll configure properly (though the timing issues you mention will be at play). Approve? was (Author: ALRubinger): OK, so I see what you've done here with the SWS. We're getting closer to meeting in the middle. Though this might not be necessary to have a separate SWS...instead of injecting Domain you could inject ArchiveFactory directly, which already has methods to mirror the static ShrinkWrap util. This is actually why I made Domains, ArchiveFactories etc in the first place; so we could inject under a specific config (and this config would not interfere with other configs in the VM). The only problem is that users would have to inject the ArchiveFactory as obtained from the, and any usage of ShrinkWrap utility methods would still be OSGi non-compatible. Does this solve the problem? Will be have cases of users STILL using ShrinkWrap.create() from within the OSGi environment? I think of course we will. So let's take the two-pronged approach: 1) Add to Domain/Configuration/ArchiveFactory a CL association to be used instead of TCCL. 2) Provide mechanism to apply a given CL for static usage (effectively configuring the default Domain/Configuration). The preferred usage inside AS will be to get an ArchiveFactory from MSC. Failing that, use the static thing, which we'll configure properly (though the timing issues you mention will be at play). Approve? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-242: -------------------------------------------- David: Care to review the general idea behind: Working branch: https://github.com/ALRubinger/shrinkwrap/commits/SHRINKWRAP-246 Commit: https://github.com/ALRubinger/shrinkwrap/commit/87bd7cada1f123390213a766a... ...before I invest in adding a bunch of new CL-related test cases? These changes affect my point 1) above, but don't yet get into the Service approach or configuration of the default Domain yet. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-242: -------------------------------------------- To create an ArchiveFactory with a given ClassLoader: final ClassLoader cl = null; // Use whatever CL final ConfigurationBuilder builder = new ConfigurationBuilder().classLoader(cl); final Domain domain = ShrinkWrap.createDomain(builder); final ArchiveFactory factory = domain.getArchiveFactory(); This will ensure that the specified CL will be used for creating impl instances of Archives; is this the same as "loading the impl-base module"? Yes, there is the case where more than one module would need to be visible. For instance, extension-sip adds archive types specific to SIP servlet grammars. So the above assumes that the CL passed in has visibility to both extension-sip and impl-base. If that's not true, then yes, we need a Collection of CLs to search. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-242: -------------------------------------------- David: Pushed up changes to allow multi ClassLoaders associated w/ a Configuration/Archive: https://github.com/ALRubinger/shrinkwrap/commits/SHRINKWRAP-246 WDYT of this? Still out of scope is the static TCCL issue/Service Registry approach. Which I'd like to discuss Wednesday a bit; when are you free? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] David Bosschaert commented on SHRINKWRAP-242: --------------------------------------------- Just thinking a little more about the OSGi and JBoss-modules use-cases... While all of the above seems fine - there is a missing part IMHO. If you're in OSGi or in JBoss modules, it's still kinda hard to find out what the classloader is that you need to pass in. In the simple case its the classloader that loads the sw-impl-base module but how you find that classloader is non-trivial (I think). Therefore I would recommend that in addition to what you did, you register the ArchiveFactory as a service, either in MSC, in OSGi, or in both. This means that someone who wants to use SW from such an environment doesn't need to do any crazy stuff to find the appropriate classloader. The ArchiveFactory instance is just there. It also means that the user doesn't need to declare a hard dependency on the impl-base module. You can do this in a way that doesn't hamper anyone else... * For OSGi you simply add a bundle activator that registers the instance * For JBoss-modules/msc you add a service activator Ideally you would do both :) The nice thing is that if you're running outside of any of these the activators are ignored... If you need any help with this I would be happy to assist... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-242: -------------------------------------------- Yup, I actually plan on installing the Domain (which has the ArchiveFactory and the Configuration both) as a service. Don't quite know how to do that yet, but I figure that's just details. :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-242: -------------------------------------------- Can you point me to an example of a simple OSGi harness I can use for testing to be sure things are working as expected? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-242?page=com.atlassian.jira.pl... ] Andrew Rubinger resolved SHRINKWRAP-242. ---------------------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira