Exploding jar libraries in deployments| JBoss.org Content Archive (Read Only)

15. Re: Exploding jar libraries in deployments

alrubinger Aug 3, 2009 5:17 PM (in response to jaikiran)

"jason.greene@jboss.com" wrote:
Why don't you just switch from vfsmrmory to using a file based VFS on a temp location for now, until we see what happens with VFS in trunk?

I should write a new virtual archive impl just for this one case, which could be addressed through the addition of one overloaded method in VFS?

S,
ALR

16. Re: Exploding jar libraries in deployments

jason.greene Aug 3, 2009 5:35 PM (in response to jaikiran)

"ALRubinger" wrote:
"jason.greene@jboss.com" wrote:
Why don't you just switch from vfsmrmory to using a file based VFS on a temp location for now, until we see what happens with VFS in trunk?

I should write a new virtual archive impl just for this one case, which could be addressed through the addition of one overloaded method in VFS?

Is it really that hard to copy files into a temp dir and point the VFS at it?

Part of the reason for issues with the current VFS impl is that everyone treats it like some magic silver-bullet and keeps hacking it to solve problems that should be solved elsewhere.

17. Re: Exploding jar libraries in deployments

alrubinger Aug 3, 2009 5:47 PM (in response to jaikiran)

"jason.greene" wrote:
Part of the reason for issues with the current VFS impl is that everyone treats it like some magic silver-bullet and keeps hacking it to solve problems that should be solved elsewhere.

Let's forget for a moment that JBossWeb has this dependency upon a flat file structure. They've identified this and will be correcting it in the future.

Use case:

I have a vfsmemory archive. I want to copy its contents as a flat directory. With other VirtualFileHandler impls this is possible, but not currently memory. Which to me is a hole in the abstraction layer.

S,
ALR

18. Re: Exploding jar libraries in deployments

wolfc Aug 3, 2009 5:50 PM (in response to jaikiran)

Don't blame the use case for the fact that VFS can't unjar vfsmemory.

It's a plain bug in VFS.

19. Re: Exploding jar libraries in deployments

jason.greene Aug 3, 2009 5:51 PM (in response to jaikiran)

"ALRubinger" wrote:

Use case:

I have a vfsmemory archive. I want to copy its contents as a flat directory. With other VirtualFileHandler impls this is possible, but not currently memory. Which to me is a hole in the abstraction layer.

vfsmemory is not a use case, is a solution (a bad one at that). The use case is you have some files you want to make into a deployment. The VFS is not supposed to be a virtual deployment API, event though it keeps getting hacked to be one.

20. Re: Exploding jar libraries in deployments

jason.greene Aug 3, 2009 5:55 PM (in response to jaikiran)

"wolfc" wrote:
Don't blame the use case for the fact that VFS can't unjar vfsmemory.

It's a plain bug in VFS.

Yes, it's broken, among other things, which is why its currently nuked from the VFS3 prototype.

21. Re: Exploding jar libraries in deployments

alrubinger Aug 3, 2009 6:07 PM (in response to jaikiran)

"jason.greene@jboss.com" wrote:
The use case is you have some files you want to make into a deployment. The VFS is not supposed to be a virtual deployment API, event though it keeps getting hacked to be one.

To be very clear, I have my own Deployment type. But in the end deployable types are backed by some file-esque archive. And I happen to be using the vfsmemory backend. So I expect it to support the full range of operations permitted upon VirtualFile.

S,
ALR

22. Re: Exploding jar libraries in deployments

alesj Aug 4, 2009 3:18 AM (in response to jaikiran)

"ALRubinger" wrote:

I have a vfsmemory archive. I want to copy its contents as a flat directory. With other VirtualFileHandler impls this is possible, but not currently memory. Which to me is a hole in the abstraction layer.

OK, I think the only proper solution here is to make this VFSUtils::unjar take into account all possible VFSHandler types,
while the end result should be exactly the same as what original (from Common-core) unjar creates.

You (and definitely *not* Carlo) are free to hack this away on Branch_2_0, and if you need any help let me know.
Or you would rather see that I hack this?

23. Re: Exploding jar libraries in deployments

alrubinger Aug 4, 2009 10:08 AM (in response to jaikiran)

"alesj" wrote:
You (and definitely *not* Carlo) are free to hack this away on Branch_2_0, and if you need any help let me know.
Or you would rather see that I hack this?

I'll open an issue and submit my patches for you to reject. ;)

S,
ALR

24. Re: Exploding jar libraries in deployments

alesj Aug 4, 2009 10:22 AM (in response to jaikiran)

"ALRubinger" wrote:

submit my patches for you to reject. ;)

If it will be any near Carlo's MC hacks, I can reject it right now, and save you the trouble. :-)

Just kiddin', go ahead.
Dunno how useful you will find the current VFSUtils::(modification-type) tests.

Perhaps move the current unjar to legacyUnjar (or some better name),
and test your work with the current tests.
Or try adding a few new ones. ;-)

25. Re: Exploding jar libraries in deployments

jaikiran Aug 6, 2009 12:22 PM (in response to jaikiran)

"jaikiran" wrote:

I'll create a JIRA for this and attach the testcase.

This is taking longer than i expected. It's going to take some more time. Turns out the way MainDeployer deploys applications (this is how it's done in testcase), behaves differently from directly deploying in the deploy folder.

There is some VFS magic in AbstractWarDeployer http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java which adds the "org.jboss.web.expandedWarClasspath" classpath attachment to the war deployment. And this behaves differently when deploying through MainDeployer (whose input is the entire path of the war outside the AS structure) and when deployed by placing in deploy folder of AS:

// get the real unjared url
 expWarUrl = VFSUtils.getRealURL(unjared);

 // Map
 String warPathName = root.getPathName();
 if (warPathName.endsWith("/") == false)
 warPathName += "/";
 List<VirtualFile> classpathVFs = vfsUnit.getClassPath();
 if (classpathVFs != null)
 {
 List<URL> classpath = new ArrayList<URL>();
 for (VirtualFile vf : classpathVFs)
 {
 try
 {
 String path = vf.getPathName();
 if (path.startsWith(warPathName))
 {
 path = path.substring(warPathName.length());
 URL pathURL = new URL(expWarUrl, path);
 classpath.add(pathURL);
 }
 else
 {
 log.debug("Ignoring path element: " + vf);
 }
 }
 catch (Exception e)
 {
 log.debug("Ignoring path element: " + vf, e);
 }
 }
 unit.addAttachment("org.jboss.web.expandedWarClasspath", classpath);
 }

In short, i need more time :)

26. Re: Exploding jar libraries in deployments

alesj Sep 16, 2009 6:23 AM (in response to jaikiran)

Looking at the issue more closely,
I don't think handling of vfs-memory via some copy mechanism would actually help here.
As it would be the tld handling that wouldn't work then - as shown in our initial exception.

tld handling currently explicitly expects zip file,
where in our case we wouldn't know how to generically create one out from vfs-memory contents.
Only proper solution, and that's what Remy is currently working on, is to have tld handling ported (back) to VFS.