[alesj]

"mwringe" wrote:

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

Why -service.xml instead of -beans.xml?

"mwringe" wrote:

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.

Why MC kernel usage?
Inject portal objects directly.

"mwringe" wrote:

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.

OK, the common metadata driven approach.

Any new idea with the .tld handling?

[mwringe]

"alesj" wrote:

"mwringe" wrote:

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

Why -service.xml instead of -beans.xml?

Thats the way the current sar is setup, I can be converted to a -beans.xml in the future. Is there a big reason to switch?

"alesj" wrote:

"mwringe" wrote:

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.

Why MC kernel usage?
Inject portal objects directly.

Because the deployers are started before the deployables, so I can't inject something from a deployable into a deployer (correct me if I am wrong, but I have tried this)
So I use the MC kernel to get a reference to the objects at runtime which gives me the same result.

"alesj" wrote:

"mwringe" wrote:

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.

OK, the common metadata driven approach.

So the common metadata driven approach is the best?

"alesj" wrote:

Any new idea with the .tld handling?

No, and there are other deployers which need to do similar things (sometimes even worst than the tld deployers). I know its not the best way of doing it, but it works. It something that will need to be looked into more and fixed (if possible).

[alesj]

"mwringe" wrote:

Thats the way the current sar is setup, I can be converted to a -beans.xml in the future. Is there a big reason to switch?

JMX might not be there for 6.x. ;-)
Our beans IoC is far superior to our JMX IoC.
sar == jar in MC

"mwringe" wrote:

Because the deployers are started before the deployables, so I can't inject something from a deployable into a deployer (correct me if I am wrong, but I have tried this)
So I use the MC kernel to get a reference to the objects at runtime which gives me the same result.

It depends how you inject them. ;-)

After each phase deploy - boot, deployers, deploy - a MainDeployer::checkComplete is called,
to make sure everything is deployed as it should be.

But you can make your injections optional, injected via callback.
So it will be almost the same as you have now,
except that your code will be MC agnostic, hence more flexible.

Think POJO. ;-)

"mwringe" wrote:

So the common metadata driven approach is the best?

Best is relative term. ;-)
But I guess it's good, see our previous 4.x deployers vs. new VDF.

"mwringe" wrote:

No, and there are other deployers which need to do similar things (sometimes even worst than the tld deployers). I know its not the best way of doing it, but it works. It something that will need to be looked into more and fixed (if possible).

What about if we did this on our own?
As it looks like we'll have to wait forever for Remy. :-)
Or get ThomasH to ping/push the new JBossAS bosses about this issue,
as it's crucial for you guys.

I think all we need is a VDF based DirContext + investigate how this affects .tld lookup.
There already is a VFS based one, but it's not used due to some legacy Servlet api crap.

Perhaps we could make this dynamic,
e.g. if we see JBP app use VDFDirContext, else fall back to default.

[mwringe]

"alesj" wrote:

It depends how you inject them. ;-)

After each phase deploy - boot, deployers, deploy - a MainDeployer::checkComplete is called,
to make sure everything is deployed as it should be.

But you can make your injections optional, injected via callback.
So it will be almost the same as you have now,
except that your code will be MC agnostic, hence more flexible.

Think POJO. ;-)

Oh, ok, well that makes more sense.

But if we use the common metadata approach, this doesn't work as the deployer won't have access to the containers jars in its classpath, so I would still probably have to use the indirect reference method using the MC kernel.

[alesj]

"mwringe" wrote:

But if we use the common metadata approach, this doesn't work as the deployer won't have access to the containers jars in its classpath, so I would still probably have to use the indirect reference method using the MC kernel.

I don't get it. :-)

How do you then get stuff from container?
Plain object and then hack over reflection? :-)

You need type safe model.
All the interfaces should be on deployers side,
only some impls at container side.

This should work with current flat cl model (or "big ball of mud"),
once we kick-in OSGi you should add more exact cl logic + move to proxy services.

But that's another story. :-)

[mwringe]

"alesj" wrote:

"mwringe" wrote:

But if we use the common metadata approach, this doesn't work as the deployer won't have access to the containers jars in its classpath, so I would still probably have to use the indirect reference method using the MC kernel.

I don't get it. :-)

How do you then get stuff from container?
Plain object and then hack over reflection? :-)

You need type safe model.
All the interfaces should be on deployers side,
only some impls at container side.

yes, that how it should work.
mwringe needs more coffee today.

"alesj" wrote:

This should work with current flat cl model (or "big ball of mud"),
once we kick-in OSGi you should add more exact cl logic + move to proxy services.

But that's another story. :-)

Oh great, OSGi and manipulating jar manifest files, sounds like fun :P