Ugh, resending the below message now without the [unsure] mixed into the
subject (thanks to my ISP SPAM checker).
Sorry for the noise, ignore either this or my previous email, or both if you
don't care ;)
Hi Carsten,
First of all, I think all your proposed changes are fine by me.
But, I'd prefer if you can hold off these changes a few more days?
As you know I proposed some other major refactorings for Pluto 3 weeks ago, see:
http://www.nabble.com/More-required-Pluto-2.0-SPI-and-implementation-refactoring-issues-td21973310.html
I started working on the major part of these already, see
PLUTO-529/530/531/532, and already have a large part of those completed locally.
As a matter of fact, some of your recent changes I already had taken care of
myself too ;)
Now, my changes will result in quite some SPI usage changes, and for instance I could remove almost all the *Internal* interfaces (now only
needing the Portlet 2.0 request/response interfaces itself), and no more "wrapping" or "blending" of the portlet and servlet interfaces.
As such, I planned to commit my changes to a separate branch this week so everyone can review the effect of all this, before I would merge
it back into trunk.
I've encountered a small problem however: I broke my elbow this Sunday at a soccer game and because of that I'm stuck with an immobilized
left arm for the next 2 weeks :(
I *can* and will continue working on this however, even if only with one hand,
and still plan to proceed with the above.
Randy Watler has indicated he wants to help me out with the remaining tasks (which still are considerable), so we definitely should still be
on track.
FYI: what I've done so far is abstracting every logic and interaction which is container/portal specific in new SPI request/response
"-Context" interfaces. The request/response implementations (now no longer implementing "Internal-") all only deal with the Portlet 2.0
*restrictions/requirements*, so ensure all validations, checks, and then (where applicable) delegate to the "-Context" SPI.
As result, we'll have a clean, and *complete* Portlet 2.0 implementation layer to be used by the portlet developers, and a complete
pluggable SPI layer for processing the *already* validated input.
So far, I've almost completed the painstakingly implementation of the first layer (I now must have read the 2.0 spec and javadoc at least
100x), and have the second SPI layer defined but still no SPI impl. yet.
For the new SPI however we should be able to provide a new default/Pluto impl quickly enough as most of that logic is either a simple
delegate to the underlying servlet request/response objects or doesn't have a real impl like cache handling (in the Pluto Driver case that is).
Only real impact will be for the Portal Driver PortletURLProviderImpl and EventProviderImpl instances, but still it will be mostly
moving/shuffling existing code/behavior, not really a rewrite.
Anyway, as you can understand from the above, I'd rather wait with your proposed repackaging changes until we've gone through the above
transition, otherwise merging will become extremely difficult thereafter.
I've already had difficulty validating/merging your recent changes as the meat of those are formatting changes only but with some real
changes embedded. It would be nice if you can separate those 2 different types of changes in individual commits?
Regards,
Ate
Carsten Ziegeler wrote:
Hi,
I'm currently trying to add portlet support to Apache Sling by using our
2.0 implementation.
One thing that strikes me is the use of packages in the various modules.
In order to have a clear separation and to easily support OSGi (where
there's no package overlap between modules), I think we should change
the following:
container-api:
- The api currently contains packages like core and internal which do
not sound like api packages. The "internal" stuff (request/response
impl) are used in the spi, so I think we should move it to the spi package.
- "core" contains the NullPortlet and the PortletServlet. The
NullPortlet is only used inside the PortletServlet, so we should make
this an inner class and not expose it. The PortletServlet could move to
a different package, something like "servlet".
container:
- The container should not use the org.apache.pluto package. We should
move the PortletContainerFactory class to the core or the util package
- Core contains the o.a.p.util package which is already taken by the
pluto-utils (which makes sense), so we shoud move this to another package.
- To have the best separation possible, we could move all container
stuff (impl) to o.a.p.container.*, but maybe this change is too much?
If noone objects, I'll do the obvious changes.
WDYT?
Carsten
