[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation

[alesj]

"mstruk" wrote : I commited noCopy support to jar-alter-work branch. I also added two additional system property switches:
  | 
  | -Djboss.vfs.forceVfsJar=true
  | to fallback to vfsjar
  | 
  | and
  | 
  | -Djboss.vfs.forceNoReaper=true
  | 
  | to turn off asynchronous release of file locks
  | 
Nice. ;-)

"mstruk" wrote : 
  | Known issues:
  | 
  | 1) When deployment archive is removed from deploy directory an exception occurs, and the application is not undeployed - even though the file has been removed.
  | 
  | 00:29:28,205 WARN  [HDScanner] Scan failed
  |   | org.jboss.deployers.spi.DeploymentException: Exception determining structure: AbstractVFSDeployment(autogen-bloated.ear)
  |   |         at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
  |   |         at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:85)
  |   |         at org.jboss.deployers.plugins.main.MainDeployerImpl.determineStructure(MainDeployerImpl.java:845)
  |   |         at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:303)
  |   |         at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:260)
  |   |         at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:270)
  |   |         at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
  |   |         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
  |   |         at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
  |   |         at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
  |   |         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
  |   |         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
  |   |         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
  |   |         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
  |   |         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  |   |         at java.lang.Thread.run(Thread.java:619)
  |   | Caused by: java.lang.RuntimeException: Error determining structure: autogen-bloated.ear
  |   |         at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:274)
  |   |         at org.jboss.deployers.vfs.plugins.structure.StructureDeployerWrapper.determineStructure(StructureDeployerWrapper.java:72)
  |   |         at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.doDetermineStructure(VFSStructuralDeployersImpl.java:196)
  |   |         at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.determineStructure(VFSStructuralDeployersImpl.java:220)
  |   |         at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:77)
  |   |         ... 14 more
  |   | Caused by: java.lang.RuntimeException: /autogen-bloated.jar module listed in application.xml does not exist within .ear autogen-bloated.ear
  |   |         at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:253)
  |   |         ... 18 more
  |   | 
  | 
  | I'm not sure this is VFS's problem.
  | 
Better question is why is this ear being treated as new deployment.
Since you can see that it's being added as deployment.

1) Why is it added / who still sees it?
2) What's the real cause module jar cannot be found?

"mstruk" wrote : 
  | 2) As applications are redeployed, memory consumption keeps increasing. It needs to be investigated.
  | 
That would be great.

"mstruk" wrote : 
  | Tomorrow I'm merging the code into trunk :)
  | 
Like Dimitris said, little commits as possible - making revert simple. :-)


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154536#4154536

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154536