11:17 a.m.
Hi all,
I have been looking at getting Shrinkwrap to work in a module-based
environment, like OSGi and JBoss Modules. I ran into issues with this
basically because the interaction goes through the ShrinkWrap-API module
and some static methods in there while the implementation requires that
the ThreadContextClassLoader has visibility of Shrinkwrap-Impl module.
In a classloader setting where all the SW jars are visible to the same
classloader this works fine, but in a modules-based system these two
modules would be loaded by two different classloaders so the only way to
get the current approach work is to set the TCCL explicitly to the
classloader that loads the ShrinkWrap-Impl module, which is a little
awkward to do but also typically requires a dependency on a
ShrinkWrap-Impl class which is ugly (IMHO), e.g:
ClassLoader oldCL = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(
JavaArchiveImpl.class.getClassloader()); // The impl class
Archive a = ShrinkWrap.create(...);
} finally {
Thread.currentThread().setContextClassLoader(oldCL);
}
I can see two solutions to this.
1. The nicest one (IMHO) would be to let the impl module register a
ShrinkWrap service (with MSC and/or OSGi) which handles all the TCCL
details. The nice thing is that the user doesn't need to get into any SW
implementation detail. Just use the service and it works - the API of
the service would be similar to the ShrinkWrap class that's there today
and defined in the API module. I guess the disadvantage would be that
you need to obtain the service instance from the service registry, so
you can't use a static API like ShrinkWrap.create().
2. An alternative could be to add additional static ShrinkWrap.create()
(etc) methods that take a classloader as an argument. You would then
still need to get hold of that classloader somehow, but at least you're
freed of the TCCL setter wrapping code...
Thoughts anyone?
David
BTW more context can be found in
https://jira.jboss.org/browse/SHRINKWRAP-242 where I'm providing an
initial proposal for #1 above to work in OSGi.
11:22 a.m.
For all the other tests shrinkwrap is executed 'on the client', so the full
classpath is available. The product is then deployed on the server and runs in the server
with modular classloading. Aslak says that Arquillian will soon support multiple
@Deployment methods so what ever you are doing will probably just be a temporaty
workaround. So I think you have two choices:
-Either construct your extra archives on the server and set up the arquillian module to
see the shrinkwrap module. But I think this might cause some problems since I think
arquillian uses a service loader to load up things from META-INF/services which will not
be visible from the arquillian service module (due to MODULES-55) unless you simply put
the shrinkwrap jars into the arquillian service module
-Have what calls shrinkwrap to create the extra deployment jars execute 'on the
client'. If I have understood you correctly you are doing this by using JMX
notifications? So the way to do that would be to register a notification listener with the
MBeanServerConnection on the client side, for example when starting up the server. You
could perhaps configure that with a system property or a META-INF/services service.
On 10 Dec 2010, at 10:17, David Bosschaert wrote:
Hi all,
I have been looking at getting Shrinkwrap to work in a module-based
environment, like OSGi and JBoss Modules. I ran into issues with this
basically because the interaction goes through the ShrinkWrap-API module
and some static methods in there while the implementation requires that
the ThreadContextClassLoader has visibility of Shrinkwrap-Impl module.
In a classloader setting where all the SW jars are visible to the same
classloader this works fine, but in a modules-based system these two
modules would be loaded by two different classloaders so the only way to
get the current approach work is to set the TCCL explicitly to the
classloader that loads the ShrinkWrap-Impl module, which is a little
awkward to do but also typically requires a dependency on a
ShrinkWrap-Impl class which is ugly (IMHO), e.g:
ClassLoader oldCL = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(
JavaArchiveImpl.class.getClassloader()); // The impl class
Archive a = ShrinkWrap.create(...);
} finally {
Thread.currentThread().setContextClassLoader(oldCL);
}
I can see two solutions to this.
1. The nicest one (IMHO) would be to let the impl module register a
ShrinkWrap service (with MSC and/or OSGi) which handles all the TCCL
details. The nice thing is that the user doesn't need to get into any SW
implementation detail. Just use the service and it works - the API of
the service would be similar to the ShrinkWrap class that's there today
and defined in the API module. I guess the disadvantage would be that
you need to obtain the service instance from the service registry, so
you can't use a static API like ShrinkWrap.create().
2. An alternative could be to add additional static ShrinkWrap.create()
(etc) methods that take a classloader as an argument. You would then
still need to get hold of that classloader somehow, but at least you're
freed of the TCCL setter wrapping code...
Thoughts anyone?
David
BTW more context can be found in
https://jira.jboss.org/browse/SHRINKWRAP-242 where I'm providing an
initial proposal for #1 above to work in OSGi.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12:15 p.m.
So the way to do that would be to register a notification listener
with the MBeanServerConnection on the client side, for example when starting up the
server. You could perhaps configure that with a system property or a META-INF/services
service.
And then have the notification listener in the client assemble things with
shrinkwrap and deploy those to the server
12:44 p.m.
New subject: [Discuss] Making Shrinkwrap more module-classloader friendly
Yes, this would also work. The concept is different however
now: test case requests an archive from the client and deploys the
archive itself
new: test case requests the client to deploy an archive
On 12/10/2010 12:15 PM, Kabir Khan wrote:
> So the way to do that would be to register a notification
listener with the MBeanServerConnection on the client side, for example when starting up
the server. You could perhaps configure that with a system property or a META-INF/services
service.
And then have the notification listener in the client assemble things with shrinkwrap and
deploy those to the server
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
1:05 p.m.
New subject: [Discuss] Making Shrinkwrap more module-classloader friendly
It's the 'new' scenario that will be supported out of the Arquillian box.
InContainer callback to Client asking it to 'generate/deploy' a Archive to
Container X. ShrinkWrap is not used inside the container at all.
-aslak-
----- "Thomas Diesler" <thomas.diesler(a)jboss.com> wrote:
Yes, this would also work. The concept is different however
now: test case requests an archive from the client and deploys the
archive itself
new: test case requests the client to deploy an archive
On 12/10/2010 12:15 PM, Kabir Khan wrote:
>> So the way to do that would be to register a notification listener
with the MBeanServerConnection on the client side, for example when
starting up the server. You could perhaps configure that with a system
property or a META-INF/services service.
> And then have the notification listener in the client assemble
things with shrinkwrap and deploy those to the server
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
1:12 p.m.
New subject: [Discuss] Making Shrinkwrap more module-classloader friendly
I take the test case can also execute this with the help of some Future,
so deployment failures can be fed back to the initiating test case.
The OSGiContainer interface, which also allows you to deploy archives
from the client classpath as well as from the local mvn repository is
currently limited to OSGi bundles only. That needs to fixed as well IMHO.
https://github.com/jbosgi/arquillian/blob/jbosgi/protocols/osgi/src/main/...
On 12/10/2010 01:05 PM, Aslak Knutsen wrote:
It's the 'new' scenario that will be supported out of the
Arquillian box.
InContainer callback to Client asking it to 'generate/deploy' a Archive to
Container X. ShrinkWrap is not used inside the container at all.
-aslak-
----- "Thomas Diesler"<thomas.diesler(a)jboss.com> wrote:
> Yes, this would also work. The concept is different however
>
> now: test case requests an archive from the client and deploys the
> archive itself
> new: test case requests the client to deploy an archive
>
> On 12/10/2010 12:15 PM, Kabir Khan wrote:
>>> So the way to do that would be to register a notification listener
> with the MBeanServerConnection on the client side, for example when
> starting up the server. You could perhaps configure that with a system
> property or a META-INF/services service.
>> And then have the notification listener in the client assemble
> things with shrinkwrap and deploy those to the server
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
1:17 p.m.
New subject: [Discuss] Making Shrinkwrap more module-classloader friendly
Maven repository and dependency resolution is work in progress:
http://github.com/kpiwko/shrinkwrap/tree/SHRINKWRAP-140
-aslak-
----- "Thomas Diesler" <thomas.diesler(a)jboss.com> wrote:
I take the test case can also execute this with the help of some
Future,
so deployment failures can be fed back to the initiating test case.
The OSGiContainer interface, which also allows you to deploy archives
from the client classpath as well as from the local mvn repository is
currently limited to OSGi bundles only. That needs to fixed as well
IMHO.
https://github.com/jbosgi/arquillian/blob/jbosgi/protocols/osgi/src/main/...
On 12/10/2010 01:05 PM, Aslak Knutsen wrote:
> It's the 'new' scenario that will be supported out of the Arquillian
box.
>
> InContainer callback to Client asking it to 'generate/deploy' a
Archive to Container X. ShrinkWrap is not used inside the container at
all.
>
> -aslak-
>
> ----- "Thomas Diesler"<thomas.diesler(a)jboss.com> wrote:
>
>> Yes, this would also work. The concept is different however
>>
>> now: test case requests an archive from the client and deploys the
>> archive itself
>> new: test case requests the client to deploy an archive
>>
>> On 12/10/2010 12:15 PM, Kabir Khan wrote:
>>>> So the way to do that would be to register a notification
listener
>> with the MBeanServerConnection on the client side, for example
when
>> starting up the server. You could perhaps configure that with a
system
>> property or a META-INF/services service.
>>> And then have the notification listener in the client assemble
>> things with shrinkwrap and deploy those to the server
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> --
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Thomas Diesler
>> JBoss OSGi Lead
>> JBoss, a division of Red Hat
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
3:07 p.m.
New subject: [Discuss] Making Shrinkwrap more module-classloader friendly
In what I'm currently working on the actual ShrinkWrap archive is
created on the client, but Shrinkwrap still gets slightly involved on
the test run side in that it is used to reconstitute the Archive it
receives over the wire from the client (via JMX) using a ZipImporter.
Aslak, in what you're planning to do, ShrinkWrap would not be used
inside the container, so that would work as well.
Aside from the actual use-case with Arquillian and AS7 (which we can
solve in a number of ways) I am interested should the design of
Shrinkwrap be adapted to support modular systems?
On a high level I agree with Thomas that Shrinkwrap should be usable as
a utility class, without any fancy classloading tricks needed by the
consumer. That would be ideal.
My Service Idea is more glued into the current SW design and would be
relatively easy to add, but usage as a simple utility class would be
even better...
Cheers,
David
On 10/12/2010 12:17, Aslak Knutsen wrote:
Maven repository and dependency resolution is work in progress:
http://github.com/kpiwko/shrinkwrap/tree/SHRINKWRAP-140
-aslak-
----- "Thomas Diesler"<thomas.diesler(a)jboss.com> wrote:
> I take the test case can also execute this with the help of some
> Future,
> so deployment failures can be fed back to the initiating test case.
>
> The OSGiContainer interface, which also allows you to deploy archives
>
> from the client classpath as well as from the local mvn repository is
>
> currently limited to OSGi bundles only. That needs to fixed as well
> IMHO.
>
>
https://github.com/jbosgi/arquillian/blob/jbosgi/protocols/osgi/src/main/...
>
>
>
> On 12/10/2010 01:05 PM, Aslak Knutsen wrote:
>> It's the 'new' scenario that will be supported out of the Arquillian
> box.
>>
>> InContainer callback to Client asking it to 'generate/deploy' a
> Archive to Container X. ShrinkWrap is not used inside the container at
> all.
>>
>> -aslak-
>>
>> ----- "Thomas Diesler"<thomas.diesler(a)jboss.com> wrote:
>>
>>> Yes, this would also work. The concept is different however
>>>
>>> now: test case requests an archive from the client and deploys the
>>> archive itself
>>> new: test case requests the client to deploy an archive
>>>
>>> On 12/10/2010 12:15 PM, Kabir Khan wrote:
>>>>> So the way to do that would be to register a notification
> listener
>>> with the MBeanServerConnection on the client side, for example
> when
>>> starting up the server. You could perhaps configure that with a
> system
>>> property or a META-INF/services service.
>>>> And then have the notification listener in the client assemble
>>> things with shrinkwrap and deploy those to the server
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> --
>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>> Thomas Diesler
>>> JBoss OSGi Lead
>>> JBoss, a division of Red Hat
>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
3:11 p.m.
New subject: [Discuss] Making Shrinkwrap more module-classloader friendly
If we were to use it from within Eclipse tooling the less magic classloader tricks needed
would be good for us too ;)
/max
On Dec 10, 2010, at 15:07, David Bosschaert wrote:
In what I'm currently working on the actual ShrinkWrap archive is
created on the client, but Shrinkwrap still gets slightly involved on
the test run side in that it is used to reconstitute the Archive it
receives over the wire from the client (via JMX) using a ZipImporter.
Aslak, in what you're planning to do, ShrinkWrap would not be used
inside the container, so that would work as well.
Aside from the actual use-case with Arquillian and AS7 (which we can
solve in a number of ways) I am interested should the design of
Shrinkwrap be adapted to support modular systems?
On a high level I agree with Thomas that Shrinkwrap should be usable as
a utility class, without any fancy classloading tricks needed by the
consumer. That would be ideal.
My Service Idea is more glued into the current SW design and would be
relatively easy to add, but usage as a simple utility class would be
even better...
Cheers,
David
On 10/12/2010 12:17, Aslak Knutsen wrote:
> Maven repository and dependency resolution is work in progress:
> http://github.com/kpiwko/shrinkwrap/tree/SHRINKWRAP-140
>
> -aslak-
>
> ----- "Thomas Diesler"<thomas.diesler(a)jboss.com> wrote:
>
>> I take the test case can also execute this with the help of some
>> Future,
>> so deployment failures can be fed back to the initiating test case.
>>
>> The OSGiContainer interface, which also allows you to deploy archives
>>
>> from the client classpath as well as from the local mvn repository is
>>
>> currently limited to OSGi bundles only. That needs to fixed as well
>> IMHO.
>>
>>
https://github.com/jbosgi/arquillian/blob/jbosgi/protocols/osgi/src/main/...
>>
>>
>>
>> On 12/10/2010 01:05 PM, Aslak Knutsen wrote:
>>> It's the 'new' scenario that will be supported out of the
Arquillian
>> box.
>>>
>>> InContainer callback to Client asking it to 'generate/deploy' a
>> Archive to Container X. ShrinkWrap is not used inside the container at
>> all.
>>>
>>> -aslak-
>>>
>>> ----- "Thomas Diesler"<thomas.diesler(a)jboss.com> wrote:
>>>
>>>> Yes, this would also work. The concept is different however
>>>>
>>>> now: test case requests an archive from the client and deploys the
>>>> archive itself
>>>> new: test case requests the client to deploy an archive
>>>>
>>>> On 12/10/2010 12:15 PM, Kabir Khan wrote:
>>>>>> So the way to do that would be to register a notification
>> listener
>>>> with the MBeanServerConnection on the client side, for example
>> when
>>>> starting up the server. You could perhaps configure that with a
>> system
>>>> property or a META-INF/services service.
>>>>> And then have the notification listener in the client assemble
>>>> things with shrinkwrap and deploy those to the server
>>>>> _______________________________________________
>>>>> jboss-as7-dev mailing list
>>>>> jboss-as7-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>> --
>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>> Thomas Diesler
>>>> JBoss OSGi Lead
>>>> JBoss, a division of Red Hat
>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> --
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Thomas Diesler
>> JBoss OSGi Lead
>> JBoss, a division of Red Hat
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:14 a.m.
New subject: [Discuss] Making Shrinkwrap more module-classloader friendly
Hi Aslak,
Could you tell us when we can see the this in an Arquillian release?
We would need this for our OSGi XServices functionality that Thomas has
been working on, Thomas has the details of what would exactly be needed.
Many thanks!
David
On 10/12/2010 12:05, Aslak Knutsen wrote:
It's the 'new' scenario that will be supported out of the
Arquillian box.
InContainer callback to Client asking it to 'generate/deploy' a Archive to
Container X. ShrinkWrap is not used inside the container at all.
-aslak-
----- "Thomas Diesler"<thomas.diesler(a)jboss.com> wrote:
> Yes, this would also work. The concept is different however
>
> now: test case requests an archive from the client and deploys the
> archive itself
> new: test case requests the client to deploy an archive
>
> On 12/10/2010 12:15 PM, Kabir Khan wrote:
>>> So the way to do that would be to register a notification listener
> with the MBeanServerConnection on the client side, for example when
> starting up the server. You could perhaps configure that with a system
> property or a META-INF/services service.
>> And then have the notification listener in the client assemble
> things with shrinkwrap and deploy those to the server
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:22 a.m.
New subject: [Discuss] Making Shrinkwrap more module-classloader friendly
It's planned for .next. A tad bit delayed currently, but any day now.. :)
-aslak-
----- "David Bosschaert" <david(a)redhat.com> wrote:
Hi Aslak,
Could you tell us when we can see the this in an Arquillian release?
We would need this for our OSGi XServices functionality that Thomas
has
been working on, Thomas has the details of what would exactly be
needed.
Many thanks!
David
On 10/12/2010 12:05, Aslak Knutsen wrote:
> It's the 'new' scenario that will be supported out of the Arquillian
box.
>
> InContainer callback to Client asking it to 'generate/deploy' a
Archive to Container X. ShrinkWrap is not used inside the container at
all.
>
> -aslak-
>
> ----- "Thomas Diesler"<thomas.diesler(a)jboss.com> wrote:
>
>> Yes, this would also work. The concept is different however
>>
>> now: test case requests an archive from the client and deploys the
>> archive itself
>> new: test case requests the client to deploy an archive
>>
>> On 12/10/2010 12:15 PM, Kabir Khan wrote:
>>>> So the way to do that would be to register a notification
listener
>> with the MBeanServerConnection on the client side, for example
when
>> starting up the server. You could perhaps configure that with a
system
>> property or a META-INF/services service.
>>> And then have the notification listener in the client assemble
>> things with shrinkwrap and deploy those to the server
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> --
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Thomas Diesler
>> JBoss OSGi Lead
>> JBoss, a division of Red Hat
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
10:22 a.m.
New subject: [Discuss] Making Shrinkwrap more module-classloader friendly
Hi Aslak,
could you please touch base with me to check that the ARQ .next release
can really be used by the AS7 Arquillian subsystem without loosing
functionality we already have?
This is not the right repo, is it?
https://github.com/arquillian/arquillian/tree/next
cheers
-thomas
On 12/16/2010 09:22 AM, Aslak Knutsen wrote:
It's planned for .next. A tad bit delayed currently, but any day
now.. :)
-aslak-
----- "David Bosschaert"<david(a)redhat.com> wrote:
> Hi Aslak,
>
> Could you tell us when we can see the this in an Arquillian release?
> We would need this for our OSGi XServices functionality that Thomas
> has
> been working on, Thomas has the details of what would exactly be
> needed.
>
> Many thanks!
>
> David
>
> On 10/12/2010 12:05, Aslak Knutsen wrote:
>> It's the 'new' scenario that will be supported out of the Arquillian
> box.
>> InContainer callback to Client asking it to 'generate/deploy' a
> Archive to Container X. ShrinkWrap is not used inside the container at
> all.
>> -aslak-
>>
>> ----- "Thomas Diesler"<thomas.diesler(a)jboss.com> wrote:
>>
>>> Yes, this would also work. The concept is different however
>>>
>>> now: test case requests an archive from the client and deploys the
>>> archive itself
>>> new: test case requests the client to deploy an archive
>>>
>>> On 12/10/2010 12:15 PM, Kabir Khan wrote:
>>>>> So the way to do that would be to register a notification
> listener
>>> with the MBeanServerConnection on the client side, for example
> when
>>> starting up the server. You could perhaps configure that with a
> system
>>> property or a META-INF/services service.
>>>> And then have the notification listener in the client assemble
>>> things with shrinkwrap and deploy those to the server
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> --
>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>> Thomas Diesler
>>> JBoss OSGi Lead
>>> JBoss, a division of Red Hat
>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:38 a.m.
Just a quick note while I'm bogged in TCK. :)
Find me on #jbosstesting for any integration questions or pull requests
and I'll be happy to assist as I can.
For whichever implementation path you choose, let's get that into a SW
extension module, built atop the existing API and implementation. The
static access and subsequent CL assumptions are in place to keep the
user grammar slim and intuitive, but we'll absolutely make room for
manual access in the right hooks if need be.
Let me know if we need some API changes to the core.
S,
ALR
On 12/10/2010 05:17 AM, David Bosschaert wrote:
Hi all,
I have been looking at getting Shrinkwrap to work in a module-based
environment, like OSGi and JBoss Modules. I ran into issues with this
basically because the interaction goes through the ShrinkWrap-API module
and some static methods in there while the implementation requires that
the ThreadContextClassLoader has visibility of Shrinkwrap-Impl module.
In a classloader setting where all the SW jars are visible to the same
classloader this works fine, but in a modules-based system these two
modules would be loaded by two different classloaders so the only way to
get the current approach work is to set the TCCL explicitly to the
classloader that loads the ShrinkWrap-Impl module, which is a little
awkward to do but also typically requires a dependency on a
ShrinkWrap-Impl class which is ugly (IMHO), e.g:
ClassLoader oldCL = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(
JavaArchiveImpl.class.getClassloader()); // The impl class
Archive a = ShrinkWrap.create(...);
} finally {
Thread.currentThread().setContextClassLoader(oldCL);
}
I can see two solutions to this.
1. The nicest one (IMHO) would be to let the impl module register a
ShrinkWrap service (with MSC and/or OSGi) which handles all the TCCL
details. The nice thing is that the user doesn't need to get into any SW
implementation detail. Just use the service and it works - the API of
the service would be similar to the ShrinkWrap class that's there today
and defined in the API module. I guess the disadvantage would be that
you need to obtain the service instance from the service registry, so
you can't use a static API like ShrinkWrap.create().
2. An alternative could be to add additional static ShrinkWrap.create()
(etc) methods that take a classloader as an argument. You would then
still need to get hold of that classloader somehow, but at least you're
freed of the TCCL setter wrapping code...
Thoughts anyone?
David
BTW more context can be found in
https://jira.jboss.org/browse/SHRINKWRAP-242 where I'm providing an
initial proposal for #1 above to work in OSGi.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12:28 p.m.
I think SW should work as a utility, not as a service. The client needs
to have the appropriate dependencies setup. If you don't want a direct
dependency on the SW impl you could re-export that from a SW wrapper module
org.jboss.shrinkwrap
+- org.jboss.shrinkwrap.api;export=true
+- org.jboss.shrinkwrap.impl;export=true
+- org.jboss.shrinkwrap.spi;export=true
Clients would than only need to have a dependency on org.jboss.shrinkwrap
The usage of TCCL in SW is questionable in the first place. SW should
work as a utility in the class loading context of the caller IMHO.
Also, there seem to be two separate issues
#1 SW initialization
#2 SW usage
The obvious client for SW in AS are ARQ test cases, so perhaps #1 can be
done as part of the Aquillian subsystem startup. For #2 to work, test
modules would need to have a dependency on org.jboss.shrinkwrap
cheers
-thomas
On 12/10/2010 11:17 AM, David Bosschaert wrote:
Hi all,
I have been looking at getting Shrinkwrap to work in a module-based
environment, like OSGi and JBoss Modules. I ran into issues with this
basically because the interaction goes through the ShrinkWrap-API module
and some static methods in there while the implementation requires that
the ThreadContextClassLoader has visibility of Shrinkwrap-Impl module.
In a classloader setting where all the SW jars are visible to the same
classloader this works fine, but in a modules-based system these two
modules would be loaded by two different classloaders so the only way to
get the current approach work is to set the TCCL explicitly to the
classloader that loads the ShrinkWrap-Impl module, which is a little
awkward to do but also typically requires a dependency on a
ShrinkWrap-Impl class which is ugly (IMHO), e.g:
ClassLoader oldCL = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(
JavaArchiveImpl.class.getClassloader()); // The impl class
Archive a = ShrinkWrap.create(...);
} finally {
Thread.currentThread().setContextClassLoader(oldCL);
}
I can see two solutions to this.
1. The nicest one (IMHO) would be to let the impl module register a
ShrinkWrap service (with MSC and/or OSGi) which handles all the TCCL
details. The nice thing is that the user doesn't need to get into any SW
implementation detail. Just use the service and it works - the API of
the service would be similar to the ShrinkWrap class that's there today
and defined in the API module. I guess the disadvantage would be that
you need to obtain the service instance from the service registry, so
you can't use a static API like ShrinkWrap.create().
2. An alternative could be to add additional static ShrinkWrap.create()
(etc) methods that take a classloader as an argument. You would then
still need to get hold of that classloader somehow, but at least you're
freed of the TCCL setter wrapping code...
Thoughts anyone?
David
BTW more context can be found in
https://jira.jboss.org/browse/SHRINKWRAP-242 where I'm providing an
initial proposal for #1 above to work in OSGi.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
4875
days inactive
4886
days old
13 comments
6 participants
participants (6)
-
Andrew Lee Rubinger -
Aslak Knutsen -
David Bosschaert -
Kabir Khan -
Max Rydahl Andersen -
Thomas Diesler