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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...