bob.mcwhirter wrote :
| Yah, I looked at that too. Though, that requires extending the
ModificationType enumeration and registering a ModificationAction. Non-trivial
to try out a different ModificationAction, it would seem.
|
| Perhaps a ModificationType.ATTACHED and go looking for a
We already have this. ;-)
You can define this in jboss-structure.xml.
Its context element takes modification attribute.
It can either be temp, unpack or explode:
-
alesj wrote : Its context element takes modification attribute.
|
Eventually this is part of ContextInfo,
so you can pre-determine this yourself.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4193824#4193824
Reply to the post :
Yah, if the top-level deployment isn't bundled up in an archive, I can assume
it's filesystem-based and can do vfsFile.toURL().getFile(). It might be
somewhat evil, but it works for me so far. :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4193827#4193827
I'm finding this difficult to get right...
If I use TEMP, it seems to just copy my archive into tmp/ as a single file.
If I use EXPLODE, it recursively explodes my archive, along with any .jar
contained within. This upsets jruby, because it expects foo.jar to be a
jarfile, not a directory.
bob.mcwhirter wrote : I'm finding this difficult to get right...
|
There might not be the modification type you're looking for.
But it's easy to add what ever you want. ;-)
And I also see types behave as I expected. :-)
You're welcome to impl top == 'I effectively want is just a top-level
alesj wrote :
| There might not be the modification type you're looking for.
| But it's easy to add what ever you want. ;-)
|
Yah, I looked at that too. Though, that requires extending the
ModificationType enumeration and registering a ModificationAction. Non-trivial
to try out a
