"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.

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?

"mwringe" wrote:

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.

Tricky how?
What about if you change the deployer hierarchy order?
e.g. setParentFirst == false

"mwringe" wrote:


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

Where? To kick some butt ... :-)

"alesj" wrote:

What exactly are you trying to do?
As it sounds weird/wrong. :-)
e.g. .sar is only finished when its children (in this case .war) are finished
but your .war should wait for .sar to finish ... chicken and egg problem ;-)

"alesj" wrote:

Although in this case you might even get away with this,
as .war at the end is nothing more than a mbean --> ServiceDeployer.
And if you put proper depends on it, it would have the right order dependencies.
I'm just not sure how easy/hard it is to add dependencies to a .war's mbean representation.

"alesj" wrote:

What about if you deploy things separately - with proper jboss-dependency.xml in the top level?
The classloading should work, as long as the flat (non-scoped) model is used.
Or it's part of common/server lib - which I guess is right place so real jbp users can write against your custom jbp api.

"mwringe" wrote:

Things work properly is deployed separetely, it just means there will be more things to deploy on the server than just a single sar.

"alesj" wrote:
btw: any more info on tld?

"alesj" wrote:

I've added methods that allow you to add/remove metadata locations:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=149197

The deployers snapshot should be in the repo in a few hours.
You can then test if this helps you.

ok

FYI it also checks the file path so that its located within the war, so it wont work if you try and reference it from another location on the file system.

OK, so I have done some more work on this. There are still some remaining issues where we have to use the tomcat deployer to get a reference to a webapplication running in the server, but there is not much we can do about that right now.

As far as doing things the "proper" way with deployers, which is the better approach:

1) The current approach is that we have all the jars that used to exist in the portlet container sar moved over to the deployer. The sar is then used to just to start the portlet container at run time (it becomes basically just a jboss-service.xml file).
The deployer uses the microcontainer kernel to get a reference to the portlet containers runtime objects and uses those to directly inject the information into the running server.

2) more distinct separation between the deployer and the portlet container.
The deployer would only contain jars for the metadata, the deployers themselves and for interface classes that will be used to pass data between the deployer and the portlet container.
In this case the deployer would parse the xml files into metadata, then convert the metadata into the proper classes for the common interface, then have the portal container have new classes to interface with the deployer to convert the common interface into the classes that it requires.

Thoughts?