-
1. Re: Autoexplosion of archives
alesj Dec 2, 2008 1:26 PM (in response to bob.mcwhirter)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":
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-core-spi/src/main/java/org/jboss/deployers/spi/structure/ModificationType.java
Dunno how will this fix URLs issues,
as they will still remain VFS urls.
Refs are correctly re-wired, deployers have no knowledge of any modification. -
2. Re: Autoexplosion of archives
alesj Dec 2, 2008 1:27 PM (in response to bob.mcwhirter)"alesj" wrote:
Its context element takes modification attribute.
Eventually this is part of ContextInfo,
so you can pre-determine this yourself. -
3. Re: Autoexplosion of archives
bob.mcwhirter Dec 2, 2008 1:30 PM (in response to bob.mcwhirter)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. :)
-
4. Re: Autoexplosion of archives
bob.mcwhirter Dec 2, 2008 4:35 PM (in response to bob.mcwhirter)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.
If I use UNPACK, nothing happens. The UnpackCopyMechanism gives up at the root level, since it's testing if it's nested inside something else.
What I effectively want is just a top-level un-jarring.
as if I'd done
jar xvf myapp.rails
and deposited the results into tmp/myapp-tmp/...
My RailsStructure is creating a ContextInfo attached to the StructureContext, and setting the modification type upon it.
Should I instead be also creating a ContextInfo for each top-level child I want slurped out of my archive?
Thanks,
-Bob -
5. Re: Autoexplosion of archives
alesj Dec 2, 2008 7:09 PM (in response to bob.mcwhirter)"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 un-jarring'.
And I'll add it to VFS 2.0.1. ;-) -
6. Re: Autoexplosion of archives
bob.mcwhirter Dec 2, 2008 7:56 PM (in response to bob.mcwhirter)"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 different ModificationAction, it would seem.
Perhaps a ModificationType.ATTACHED and go looking for a ModificationAction.class attachment if set?"alesj" wrote:
And I also see types behave as I expected. :-)
Yah, I think they all work as expected, just not a complete set from my POV. I did see some examples with an UNPACK on the root, but that seems to be non-tenable. UNPACK only works on child context-infos from the look of it. Else, the isNested() check stops it on the root without doing anything if you point it at the root deployed archive, not a nested archive."alesj" wrote:
You're welcome to impl "top" == 'I effectively want is just a top-level un-jarring'.
And I'll add it to VFS 2.0.1. ;-)
I'll poke around, but I should be able to tell the difference between foo.jar as a real directory and foo.jar as a mounted vfszip? I can still do a byte-for-byte copy of a vfszip-mounted JAR?
I'll work on an implementation.
Thanks!
-Bob -
7. Re: Autoexplosion of archives
alesj Dec 3, 2008 3:24 AM (in response to bob.mcwhirter)"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 ModificationAction.class attachment if set?
I don't think it makes sense to go that far,
we just need to cover all useful cases,
as I think there are not that many of them.
Apart from your case + the one's we already have,
I can't think of another one. :-)"bob.mcwhirter" wrote:
Yah, I think they all work as expected, just not a complete set from my POV. I did see some examples with an UNPACK on the root, but that seems to be non-tenable. UNPACK only works on child context-infos from the look of it. Else, the isNested() check stops it on the root without doing anything if you point it at the root deployed archive, not a nested archive.
Yes, unpack is only meant for nested jars."bob.mcwhirter" wrote:
I'll poke around, but I should be able to tell the difference between foo.jar as a real directory and foo.jar as a mounted vfszip?
From VFS no.
We already had this dev discussion,
and afaik Scott had some good arguments.
In the worst case you can do this:
- http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/system/server/profile/basic/MetaDataAwareProfile.java
See hasBeenModified."bob.mcwhirter" wrote:
I can still do a byte-for-byte copy of a vfszip-mounted JAR?
Sure."bob.mcwhirter" wrote:
I'll work on an implementation.
+ tests. ;-) -
8. Re: Autoexplosion of archives
alesj Oct 22, 2009 3:43 PM (in response to bob.mcwhirter)There is unjar now, if that helps:
- ModificationType.UNJAR --> http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-core-spi/src/main/java/org/jboss/deployers/spi/structure/ModificationType.java
- JarUtils::unjar --> http://anonsvn.jboss.org/repos/common/common-core/trunk/src/main/java/org/jboss/util/file/JarUtils.java