[jboss-dev-forums] [Design of JBoss Portal] - Re: Design of Portal Deployer

[mwringe]

"alesj" wrote : 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.
  | 

I don't think (b) is even possible since we can't guarantee the order of when the container or deployment is deployed. We could do something like storing the deployment data in the deployer until the container starts or making the container directly contact the server to check what it has already deployed, but I don't like these ideas.

anonymous wrote : 
  | See how I do it with DependenciesMetaDataDeployer or DeploymentDependencyDeployer,
  | meaning you only need to provide Portal specific DependenciesMetaData or DeploymentDependencies impl.
  | 
ok

anonymous wrote : 
  | WRT "container - deployer" interface, I would go to a bean directly, via some proper interface.
  | 
agreed

anonymous wrote : 
  | 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?
  | 

I really don't like how this is working right now, its a hack. It's something that needs to be fixed. I will need to read up on how tlds work to see if it can done in a different manner (perhaps referencing the tld location in metadata instead of imbedding it into the war).

I took some time to look into the VFS, but couldn't figure out a way to make this work nicely. If anyone has any suggestions on how to add a file to a webapp during the deployment phase please speak up :)

anonymous wrote : 
  | 3) PortletDeployer
  | 
  | What's the point of this one?
  | 
No point right now, it was just initially done to check somethings while I am working on the deployer.

anonymous wrote : 
  | 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.
  | 
Ah, good point, this will be fixed. But it does get a little tricky when the top deployment is the dependency of a child deployment, last I tried doing this it doesn' work as expected.

anonymous wrote : 
  | 5) CommandServletDeployer
  | 
  | Looks OK.
  | This is how TLD stuff should look like. ;-)
  | 
This is how I want the TLD stuff to work, I just need to figure out how.

anonymous wrote : 
  | 6) PortalPostWebDeployer
  | 
  | What does this do?
  | 
This is a hack that will be removed once the portal is completely moved over to using the microcontainer deployment.  The way portal used to get this type of information was changed too much in AS5 so this replaces the lost functionality. Its meant to be removed at some point.

anonymous wrote : 
  | 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/...
  | 

For those deployers right now, knowing when the war deployer has finished deploying the app is required as we access that information from the war deployer in our own deployer.
This is only being used in deployers that are meant to be removed or the TLD deployer which needs to be rewritten more cleanly anyways. So this issue will be gone.

FYI, the manipulation of deployer order based on another deployer's order is also used in a few other deployers in AS5. 

anonymous wrote : 
  | 7) LibDirectoryStructure
  | 
  | What should this do?
  | Similar to my legacy DirectoryStructure?
  | 
Yes, except it doesn't look through the whole directory structure, only at directories called "lib" within the first level of the deployment. I don't believe its needed anymore, but it used to cause all sorts of problems without it when nested deployments (like sars) were used that would have worked fine on AS4.
And I know that using jboss-structure.xml files would have worked, but it meant that we could no longer add or remove wars to the portal sar without rewriting that file each time.



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

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