[Design of JBoss Portal] - Re: Design of Portal Deployer
by alesj
A few comments to your current work and we'll pick it up from here.
1) Deployer - Portal Container dependency
(a) like you're doing it now by adding dependencies to deployment
(b) making deployers optionally depend on the portal container
e.g. @Inject(option=InjectOption.CALLBACK)
Then if the portal container is not present do nothing.
I like (a) better, as it holds all the dependencies at a single place.
It's just the way your doing it - not cleaning up in undeploy + duplication code.
See how I do it with DependenciesMetaDataDeployer or DeploymentDependencyDeployer,
meaning you only need to provide Portal specific DependenciesMetaData or DeploymentDependencies impl.
WRT "container - deployer" interface, I would go to a bean directly, via some proper interface.
2) PortletTLDDeployer
TLD usage in portal should be metadata driven,
as is the rest of the metadata stuff that we do in JBossAS.
Hence making it easier and cleaner to do this tld addition.
I guess this approach would still work if we still always unpack .war deployment.
Dunno if that's true with the VFS usage?
3) PortletDeployer
What's the point of this one?
4) PortletDependencyDeployer
As already mentioned.
This one should just produce custom portal DependenciesMetaData or DeploymentDependencies impl.
The way it's currently done is wrong, as ControllerContext is only present in top deployment unit.
5) CommandServletDeployer
Looks OK.
This is how TLD stuff should look like. ;-)
6) PortalPostWebDeployer
What does this do?
And using such hacks:
| public int getRelativeOrder()
| {
| //return the order just after the war deployer
| //note: should really be +1 but other portal deployer is getting in the way right now
| return warDeployerOrder + 2;
| }
|
defeats the purpose of deployers chain/changeability/inputs/outputs/...
7) LibDirectoryStructure
What should this do?
Similar to my legacy DirectoryStructure?
8) ParsingDeployers
OK, we just need tests so we know they work.
Overall the stuff makes sense, it's the details that are missing.
Perhaps some work on Portal Container side, to incorporate all the hooks.
I mostly don't like the WarDeployer hacks, there should be a better way to do this.
Perhaps a direct deployer-container communication?
Then it means you need a clean spi split, placing it along with the deployer.
But that should be fine for a container, since it will see those classes.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198279#4198279
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4198279
15 years, 4 months
[Design of POJO Server] - Re: JBAS-6061 or weird nested jar
by rzumwalt
I was seeing this same problem as Luc in CR2, but the original fix for this issue only partially resolved my problem. Our archive file actually includes sqljdbc.jar in it's WEB-INF/lib directory. We do this because we ship an EAR file out to customers who then install it on one of the app servers we support (JBoss being one of them). If I remove the JAR from our EAR and place it in the server's lib directory, then everything works just fine. I'd prefer to be able to deploy our EAR file with the jar inside of it since it reduces the number of steps to deploy our app.
the stack trace I see is below:
| 07:17:40,080 ERROR [AbstractKernelController] Error installing to ClassLoader: name=vfszip:/E:/jboss-5.0.0.GA/server/default/deploy/pr-war.war state=Describe mode=Manual requiredState=ClassLoader
| org.jboss.deployers.spi.DeploymentException: Error creating classloader for vfszip:/E:/jboss-5.0.0.GA/server/default/deploy/pr-war.war
| at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
| at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.createClassLoader(AbstractDeploymentContext.java:576)
| at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.createClassLoader(AbstractDeploymentUnit.java:159)
| at org.jboss.deployers.spi.deployer.helpers.AbstractClassLoaderDeployer.deploy(AbstractClassLoaderDeployer.java:53)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405)
| at org.jboss.Main.boot(Main.java:209)
| at org.jboss.Main$1.run(Main.java:547)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.Error: Error visiting DelegatingHandler(a)27305459[path=pr-war.war/WEB-INF/lib/sqljdbc-1.0.jar context=file:/E:/jboss-5.0.0.GA/server/default/deploy/ real=file:/E:/jboss-5.0.0.GA/server/default/deploy/pr-war.war/WEB-INF/lib/sqljdbc-1.0.jar]
| at org.jboss.classloading.plugins.vfs.PackageVisitor.determineAllPackages(PackageVisitor.java:98)
| at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.determineCapabilities(VFSDeploymentClassLoaderPolicyModule.java:108)
| at org.jboss.classloading.spi.dependency.Module.getCapabilities(Module.java:485)
| at org.jboss.classloading.spi.dependency.Module.determinePackageNames(Module.java:544)
| at org.jboss.classloading.spi.dependency.Module.getPackageNames(Module.java:529)
| at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.determinePolicy(VFSDeploymentClassLoaderPolicyModule.java:129)
| at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.determinePolicy(VFSDeploymentClassLoaderPolicyModule.java:48)
| at org.jboss.classloading.spi.dependency.policy.ClassLoaderPolicyModule.getPolicy(ClassLoaderPolicyModule.java:149)
| at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.getPolicy(VFSDeploymentClassLoaderPolicyModule.java:122)
| at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.getPolicy(VFSDeploymentClassLoaderPolicyModule.java:48)
| at org.jboss.classloading.spi.dependency.policy.ClassLoaderPolicyModule.registerClassLoaderPolicy(ClassLoaderPolicyModule.java:88)
| at org.jboss.deployers.plugins.classloading.AbstractLevelClassLoaderSystemDeployer.createClassLoader(AbstractLevelClassLoaderSystemDeployer.java:120)
| at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.createClassLoader(AbstractDeploymentContext.java:562)
| ... 21 more
| Caused by: java.lang.RuntimeException: Failed to read zip file: org.jboss.virtual.plugins.context.zip.ZipFileWrapper@25211b - E:\jboss-5.0.0.GA\server\default\tmp\vfs-nested.tmp\e7d09837_sqljdbc.jar
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:563)
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.checkIfModified(ZipEntryContext.java:693)
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.getChildren(ZipEntryContext.java:765)
| at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChildren(ZipEntryHandler.java:149)
| at org.jboss.virtual.plugins.context.DelegatingHandler.getChildren(DelegatingHandler.java:120)
| at org.jboss.virtual.plugins.context.AbstractVFSContext.getChildren(AbstractVFSContext.java:171)
| at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:288)
| at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:258)
| at org.jboss.virtual.VFS.visit(VFS.java:404)
| at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:407)
| at org.jboss.virtual.VirtualFile.getChildren(VirtualFile.java:356)
| at org.jboss.virtual.VirtualFile.getChildren(VirtualFile.java:337)
| at org.jboss.classloading.plugins.vfs.PackageVisitor.visit(PackageVisitor.java:200)
| at org.jboss.virtual.plugins.vfs.helpers.WrappingVirtualFileHandlerVisitor.visit(WrappingVirtualFileHandlerVisitor.java:62)
| at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:313)
| at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:258)
| at org.jboss.virtual.VFS.visit(VFS.java:404)
| at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:407)
| at org.jboss.classloading.plugins.vfs.PackageVisitor.determineAllPackages(PackageVisitor.java:94)
| ... 33 more
| Caused by: java.util.zip.ZipException: error in opening zip file
| at java.util.zip.ZipFile.open(Native Method)
| at java.util.zip.ZipFile.<init>(ZipFile.java:203)
| at java.util.zip.ZipFile.<init>(ZipFile.java:234)
| at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.ensureZipFile(ZipFileWrapper.java:175)
| at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.acquire(ZipFileWrapper.java:245)
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.initEntries(ZipEntryContext.java:461)
| at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:554)
| ... 51 more
|
I assumed from the comments for the fix that the intent was to be able to specify additional exception handlers for problematic jars in conf/bootstrap/vfs.xml when needed. I tried adding an additional exception handler (that used the server's tmp/vfs-nested.tmp/ directory as the key since that is where the JAR is read from when deploying) to the vfs.xml file but that did not work. Perhaps I did something wrong, here was the entry I added to vfs.xml
${jboss.server.home.url}tmp/vfs-nested.tmp/
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198268#4198268
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4198268
15 years, 4 months