You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/03/18 14:41:16 UTC
Re: [1.4] component management (Was: Re: [1.4] Ant tasks and publication
API)
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>
>> J. Wolfgang Kaltz wrote:
>>
>> [...]
>>
>>> BTW regarding performance I'm wondering if components in Lenya should
>>> typically define org.apache.avalon.excalibur.pool.Poolable ?
>>> (from the doc, "Components that are not pooled are created anew via a
>>> factory every time a request is made for the component.")
>>> IIUC the use cases I have seen thus far are poolable, so perhaps
>>> AbstractUsecase should declare that it is poolable?
>>
>>
>>
>> This is certainly a good idea.
>
>
> IIUC use case components are currently not released,
That's a bug. Actually, it's a bigger problem. We probably have to release
the component before we call sendPageAndWait(), because we can't be sure
that the flowscript is continued. So we need a way to re-build and
re-initialize the usecase handler transparently.
As a temporary fix, we can do cocoon.releaseComponent(usecase) before
exiting the usecases.js flowscript.
> so pooling has no
> effect - as a test, I edited usecases.js and added
> usecaseResolver.release(usecase)
> as second-last line, i.e. before the cocoon.redirectTo(url)
>
> In my test scenario this works (that is, a use case that was marked
> poolable is only instantiated once)
>
> Is this the appropriate place to release the usecase ?
See above ...
> If so, I will
> check in the modified usecases.js
>
> Next step would to decide whether all use cases should be poolable, or
> whether the individual use-case should declare poolable - I still have
> to investigate a bit more (see also below)
>
>>
>> But even more important are commonly used components:
>>
>> - WorkflowManager
>> - WorkflowResolver
>> - DocumentManager
>> - SiteManager (not yet fully avalonized)
>> - DocumentTypeResolver
>
>
> WorkflowManagerImpl and DocumentManagerImpl are poolable AFAIK (maybe
> even ThreadSafe ?
Hmm, no idea ... Maybe they are if they don't have any fields
besides the ServiceManager (is that one ThreadSafe?), but I'm not sure.
> don't know enough about that). I tested and seems OK
>
> WorkflowResolverImpl and DocumentTypeResolverImpl are currently not
> poolable, because the methods getSituation() respectively resolve() use
> the request in its implementation. The request is obtained from the
> context, which is obtained at initialization.
> Maybe it would be better to make the interfaces of these services more
> explicit, so that they would not rely on the request being passed at
> initialization.
That's probably a good idea. I already wondered about that when I
integrated the Cron block, which doesn't provide a "normal" request
at all. My workaround was to setup the CommandLineRequest.
> Not just for the goal of pooling these components, but
> also for clarity of API and implementation. It would require several
> changes however:
> - in WorkflowResolverImpl.getSituation(), the request is used to read
> the Identity attribute in the session, and to call the PolicyAuthorizer.
> The necessary info would need to be passed as parameters to getSituation
> to avoid using the request.
That would make the interface clearer, but also the code more verbose.
We would probably need another class to extract the situation information
from the session. What would be the appropriate place for that knowledge?
> - in DocumentTypeResolverImpl, the request is used to read the webapp
> context path, which is then used to construct the document URL. I think
> this would need to be changed anyway, if documents are no longer files
> in the webapp's path ?
Hmmm, why would that have to be changed? The DocumentManager operates on
sources. The contextPath is just an URL snippet, it won't change when
we introduce the repository.
>>> The more we use the component manager for Lenya objects (which IMO is
>>> a good thing), the more we need to think about such things.
>>>
>>> (I was just reading about these issues in the Langham&Ziegeler Cocoon
>>> book, which suggests to use poolable for every component, if at all
>>> possible. It suggests that thread-safe components - interface
>>> ThreadSafe - are the best, but difficult to implement; whereas all
>>> components should at least be Poolable)
>>
>>
>>
>> I agree to all points and I'm happy that you care about these concerns.
>
>
> Definitely :) I'm increasingly getting the feeling that a clean and
> efficient component model (in the larger sense, i.e. including use case
> framework) is essential for Lenya 1.4, to provide the basis for future
> developments, plugins, repository integration etc. Important steps have
> already been taken towards this model, but I don't think we are
> completely there yet.
No, we certainly aren't. But we are well on the way :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] component management (Was: Re: [1.4] Ant tasks and publication
API)
Posted by Andreas Hartmann <an...@wyona.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>
>>> [...]
>>> I refactored the usecase handling flowscript and added a proxy class.
>>> Now usecase handlers are allocated only temporarily and released before
>>> a response is sent to the user.
>>
>>
>>
>> [...]
>>
>> BTW, this means that usecases can now safely be used to present
>> data without requiring user interaction.
>
>
> Yes, I think this is an important improvement in the uc framework.
>
> However, there seems to be a problem recreating the usecase for the
> second step: Use-cases in the admin area now throw a NPE, for example
> GroupProfile:
The UsecaseProxy didn't pass the source URL to the usecase.
I fixed it, thanks for reporting!
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] component management (Was: Re: [1.4] Ant tasks and publication
API)
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
>> [...]
>> I refactored the usecase handling flowscript and added a proxy class.
>> Now usecase handlers are allocated only temporarily and released before
>> a response is sent to the user.
>
>
> [...]
>
> BTW, this means that usecases can now safely be used to present
> data without requiring user interaction.
Yes, I think this is an important improvement in the uc framework.
However, there seems to be a problem recreating the usecase for the
second step: Use-cases in the admin area now throw a NPE, for example
GroupProfile:
java.lang.NullPointerException
at
org.apache.lenya.cms.publication.URLInformation.<init>(URLInformation.java:71)
at
org.apache.lenya.cms.ac.PublicationAccessControllerResolver.generateCacheKey(PublicationAccessControllerResolver.java:59)
at
org.apache.lenya.ac.impl.AbstractAccessControllerResolver.resolveAccessController(AbstractAccessControllerResolver.java:55)
at
org.apache.lenya.cms.ac.usecases.AccessControlUsecase.initializeAccessController(AccessControlUsecase.java:70)
at
org.apache.lenya.cms.ac.usecases.AccessControlUsecase.getGroupManager(AccessControlUsecase.java:99)
at
org.apache.lenya.cms.ac.usecases.GroupProfile.setParameter(GroupProfile.java:54)
I've traced this to AbstractUsecase.getSourceURL() returning null in the
second step of the usecase (the first step works), but I don't know why
that happens. Since the usecase instance is no longer the same object
for both steps IIUC, I'm assuming it has to do with that.
Any further ideas ?
Re: [1.4] component management (Was: Re: [1.4] Ant tasks and publication
API)
Posted by Andreas Hartmann <an...@wyona.org>.
Andreas Hartmann wrote:
> Andreas Hartmann wrote:
>
>> J. Wolfgang Kaltz wrote:
>
>
> [...]
>
>>> IIUC use case components are currently not released,
>>
>>
>>
>> That's a bug. Actually, it's a bigger problem. We probably have to
>> release
>> the component before we call sendPageAndWait(), because we can't be sure
>> that the flowscript is continued. So we need a way to re-build and
>> re-initialize the usecase handler transparently.
>
>
>
> I refactored the usecase handling flowscript and added a proxy class.
> Now usecase handlers are allocated only temporarily and released before
> a response is sent to the user.
[...]
BTW, this means that usecases can now safely be used to present
data without requiring user interaction.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] component management (Was: Re: [1.4] Ant tasks and publication
API)
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> J. Wolfgang Kaltz wrote:
[...]
>> IIUC use case components are currently not released,
>
>
> That's a bug. Actually, it's a bigger problem. We probably have to release
> the component before we call sendPageAndWait(), because we can't be sure
> that the flowscript is continued. So we need a way to re-build and
> re-initialize the usecase handler transparently.
I refactored the usecase handling flowscript and added a proxy class.
Now usecase handlers are allocated only temporarily and released before
a response is sent to the user. A proxy object is used to store the
parameters and handle them to the JX template. This approach requires
that usecases don't use fields but parameters to store data.
Another approach would be to use POJOs for usecase handlers, but that
would mean we'd have to pass the ServiceManager to them manually.
I'd rather try the current solution.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] document model (Was: Re: [1.4] component management)
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Gregor J. Rothfuss schrieb:
> J. Wolfgang Kaltz wrote:
>
>> The way I see it, the Lenya core should definitely distinguish between
>> the content of a document and its meta-data. IMO meta-data must be
>> mandatory for a document, and the core must provide separate access to
>> a document's content vs. a document's meta-data.
>
>
> +1 as long as some of that metadata is maintained by the system. don't
> want to force the user to enter metadata if they dont want to. but
> exposing key metadata as searchable jcr properties makes sense.
Agreed,
actually I don't think the changes discussed would directly affect the
CMS user at all. "only" the internals would be affected (though it would
be an important change)
When a document is created, the system knows a lot of meta data: e.g.
the creator, the time, and the type of the document. So Lenya can always
create the mandatory meta data, the way I see it.
Re: [1.4] document model (Was: Re: [1.4] component management)
Posted by Torsten Schlabach <ts...@apache.org>.
+1 for separating metadata from content!
I had been thinking about this as well.
Torsten
Gregor J. Rothfuss schrieb:
> J. Wolfgang Kaltz wrote:
>
>> The way I see it, the Lenya core should definitely distinguish between
>> the content of a document and its meta-data. IMO meta-data must be
>> mandatory for a document, and the core must provide separate access to
>> a document's content vs. a document's meta-data.
>
>
> +1 as long as some of that metadata is maintained by the system. don't
> want to force the user to enter metadata if they dont want to. but
> exposing key metadata as searchable jcr properties makes sense.
>
>> This is in fact already what happens for assets, because meta-data
>> cannot be written into an asset, as opposed to an XML-based document.
>> Ironically, in this case it is unfortunate that you can store
>> arbitrary information in XML since this mislead us to store Lenya
>> meta-information within XHTML content.
>>
>> So here is my +1 to change the handling of document meta-data to make
>> it identical to asset meta-data, that is
>> - mandatory
>> - separately from content
>
>
> +1
>
>> I think it is more than that, also a maintenance / extensibility
>> issue. Generally speaking, we should have a document model which
>> accomplishes what we want (obviously ;) ), notwithstanding the storing
>> of the data within a repository. And I think it should be a goal of
>> 1.4. Regarding migration, the migration scripts can take the meta-data
>> from the xhtml header and generate a separate file, so that will be
>> painless. The documents of a custom doctype would perhaps be more
>> challenging to migrate.
>
>
> if they use the lenya:meta wrapper, it's pretty easy.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] document model (Was: Re: [1.4] component management)
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Michael Wechner schrieb:
> jplejacq wrote:
>
>> Gregor J. Rothfuss wrote:
>>
>>> J. Wolfgang Kaltz wrote:
>>>
>>>> So here is my +1 to change the handling of document meta-data to
>>>> make it identical to asset meta-data, that is
>>>> - mandatory
>>>> - separately from content
>>>
>>>
>>>
>>> +1
>>
>>
>>
>> I'm not sure that the meta-data should be separated from the content.
>> Many (if not most) asset file types already support meta-data directly
>> (for example, pdf, png, jpg). It seems to be that the meta-data and
>> content are intrinsically related.
This is an interesting point, but it is actually another type of
meta-data. The Lenya meta-data contains the meta-data relevant to Lenya,
such as the Lenya author who put this content in the system, the date
this was done, etc. The asset's internal meta-data, if present, is
unrelated to this. It might also contain an author field, but this has
no relation to the author in the Lenya sense. So, using the asset's
potential meta-data in some manner is an interesting idea, but we need
to define and handle the Lenya meta-data nonetheless.
>
>
>
> agreed, but I guess Wolfgang wants to make it more atomic (at least t
> that's how I understand it), such that meta and content for instance can
> be edited by different "users" at the same time and the interfaces
> should also become easier because
> of the atomization. Or do I misunderstand this completely?
Yes, I basically meant atomization, i.e. splitting up the meta and
content. Though for more far-reaching purposes than being able to edit
them separately at the same time. IMO making meta-data for documents
mandatory, and handling them separately from the content is an important
architectural basis, for things such as plugins, and anyway makes the
code and interfaces simpler, so makes new developments easier. Of course
it will also enhance the performance (see older mails).
Anyway it looks like we have a consensus on this - I should have time to
try to implement this, but this smells like the type of change that can
easily break things in trunk (unexpected side-effects and the like; I'm
also concerned about the editor integrations), so we should be aware of
that. If there are no objections, I will take a shot at it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] document model (Was: Re: [1.4] component management)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
jplejacq wrote:
> I prefer keeping the two together and would like us to move to
> supporting the native meta capabilities of assets.
can you define 'together' a bit more? do you care how it is implemented
in the backend, whether as seperate files, JCR properties, EXIF data or
embedded into the XML? or do you mean 'together' in a sense that you can
edit metadata and content at the same time?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] document model (Was: Re: [1.4] component management)
Posted by jplejacq <jp...@quoininc.com>.
Michael Wechner wrote:
> jplejacq wrote:
>
>>> J. Wolfgang Kaltz wrote:
>>>
>>>> So here is my +1 to change the handling of document meta-data to
>>>> make it identical to asset meta-data, that is
>>>> - mandatory
>>>> - separately from content
>>
>> I'm not sure that the meta-data should be separated from the content.
>> Many (if not most) asset file types already support meta-data directly
>> (for example, pdf, png, jpg). It seems to be that the meta-data and
>> content are intrinsically related.
>
>
> agreed, but I guess Wolfgang wants to make it more atomic (at least t
> that's how I understand it), such that meta and content for instance can
> be edited by different "users" at the same time and the interfaces
> should also become easier because
> of the atomization. Or do I misunderstand this completely?
Oh, I see. Makes sense. +1
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] document model (Was: Re: [1.4] component management)
Posted by Michael Wechner <mi...@wyona.com>.
jplejacq wrote:
> Gregor J. Rothfuss wrote:
>
>> J. Wolfgang Kaltz wrote:
>>
>>> So here is my +1 to change the handling of document meta-data to
>>> make it identical to asset meta-data, that is
>>> - mandatory
>>> - separately from content
>>
>>
>> +1
>
>
> I'm not sure that the meta-data should be separated from the content.
> Many (if not most) asset file types already support meta-data directly
> (for example, pdf, png, jpg). It seems to be that the meta-data and
> content are intrinsically related.
agreed, but I guess Wolfgang wants to make it more atomic (at least t
that's how I understand it), such that meta and content for instance can
be edited by different "users" at the same time and the interfaces
should also become easier because
of the atomization. Or do I misunderstand this completely?
> I prefer keeping the two together and would like us to move to
> supporting the native meta capabilities of assets.
I guess that's worth another thread ;-)
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] document model (Was: Re: [1.4] component management)
Posted by jplejacq <jp...@quoininc.com>.
Gregor J. Rothfuss wrote:
> J. Wolfgang Kaltz wrote:
>
>> So here is my +1 to change the handling of document meta-data to make
>> it identical to asset meta-data, that is
>> - mandatory
>> - separately from content
>
> +1
I'm not sure that the meta-data should be separated from the content.
Many (if not most) asset file types already support meta-data directly
(for example, pdf, png, jpg). It seems to be that the meta-data and
content are intrinsically related. I prefer keeping the two together and
would like us to move to supporting the native meta capabilities of assets.
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] document model (Was: Re: [1.4] component management)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
J. Wolfgang Kaltz wrote:
> The way I see it, the Lenya core should definitely distinguish between
> the content of a document and its meta-data. IMO meta-data must be
> mandatory for a document, and the core must provide separate access to a
> document's content vs. a document's meta-data.
+1 as long as some of that metadata is maintained by the system. don't
want to force the user to enter metadata if they dont want to. but
exposing key metadata as searchable jcr properties makes sense.
> This is in fact already what happens for assets, because meta-data
> cannot be written into an asset, as opposed to an XML-based document.
> Ironically, in this case it is unfortunate that you can store arbitrary
> information in XML since this mislead us to store Lenya meta-information
> within XHTML content.
>
> So here is my +1 to change the handling of document meta-data to make it
> identical to asset meta-data, that is
> - mandatory
> - separately from content
+1
> I think it is more than that, also a maintenance / extensibility issue.
> Generally speaking, we should have a document model which accomplishes
> what we want (obviously ;) ), notwithstanding the storing of the data
> within a repository. And I think it should be a goal of 1.4. Regarding
> migration, the migration scripts can take the meta-data from the xhtml
> header and generate a separate file, so that will be painless. The
> documents of a custom doctype would perhaps be more challenging to migrate.
if they use the lenya:meta wrapper, it's pretty easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
[1.4] document model (Was: Re: [1.4] component management)
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
> J. Wolfgang Kaltz wrote:
>
> [...]
>
>> That is true. But actually I'm wondering about something else in this
>> class now: why is the document type for a document resolved upon every
>> request ? The knowledge "document A is of type B" is something quite
>> static, so shouldn't the model reflect this somehow ?
>
>
> The problem here are the current concepts of meta data and document type
> assignment in Lenya.
>
> Meta data are stored in the document itself. But we want to allow arbitrary
> document structures, which means we can't require to store meta data in the
> document. That implies that all meta data are optional and therefore the
> document type can't be stored in the meta data.
> IMO this has to be changed (mandatory meta data). Praise the repository!
>
> The sitetree can't be used, because it is optional and the information
> doesn't belong to the site structure.
>
> That's why we decided to use the SourceTypeAction for document type
> resolving. Which means we need a cocoon:// request every time we want
> to obtain the document type.
>
> Up to now, it was not possible to implement Document.getDocumentType()
> because the document couldn't be provided with the ServiceManager and
> therefore not access the DocumentTypeResolver/URIParamterizer. That's
> why the document type is not even stored in the DocumentIdentityMap.
Thx for the explanation.
The way I see it, the Lenya core should definitely distinguish between
the content of a document and its meta-data. IMO meta-data must be
mandatory for a document, and the core must provide separate access to a
document's content vs. a document's meta-data.
This is in fact already what happens for assets, because meta-data
cannot be written into an asset, as opposed to an XML-based document.
Ironically, in this case it is unfortunate that you can store arbitrary
information in XML since this mislead us to store Lenya meta-information
within XHTML content.
So here is my +1 to change the handling of document meta-data to make it
identical to asset meta-data, that is
- mandatory
- separately from content
>
>
>> Please forgive my naivete if this is too simplistic :) But it seems to
>> me the model should know "What document type does a document have?"
>> without needing an http request ?
>
>
> Yes, definitely. The question is if we should implement a temporary
> solution until we have the repository. IMO this is not necesarry since
> it is "just" a performance issue.
I think it is more than that, also a maintenance / extensibility issue.
Generally speaking, we should have a document model which accomplishes
what we want (obviously ;) ), notwithstanding the storing of the data
within a repository. And I think it should be a goal of 1.4. Regarding
migration, the migration scripts can take the meta-data from the xhtml
header and generate a separate file, so that will be painless. The
documents of a custom doctype would perhaps be more challenging to migrate.
>
> The other option is to require meta data in a document, which reduces
> the flexibility (but IMO to a still reasonable amount).
+1, if we mean: a document must have meta data. But not "in" it, along
with it.
WDYT ?
Re: [1.4] component management
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
[...]
> That is true. But actually I'm wondering about something else in this
> class now: why is the document type for a document resolved upon every
> request ? The knowledge "document A is of type B" is something quite
> static, so shouldn't the model reflect this somehow ?
The problem here are the current concepts of meta data and document type
assignment in Lenya.
Meta data are stored in the document itself. But we want to allow arbitrary
document structures, which means we can't require to store meta data in the
document. That implies that all meta data are optional and therefore the
document type can't be stored in the meta data.
IMO this has to be changed (mandatory meta data). Praise the repository!
The sitetree can't be used, because it is optional and the information
doesn't belong to the site structure.
That's why we decided to use the SourceTypeAction for document type
resolving. Which means we need a cocoon:// request every time we want
to obtain the document type.
Up to now, it was not possible to implement Document.getDocumentType()
because the document couldn't be provided with the ServiceManager and
therefore not access the DocumentTypeResolver/URIParamterizer. That's
why the document type is not even stored in the DocumentIdentityMap.
> Please forgive my naivete if this is too simplistic :) But it seems to
> me the model should know "What document type does a document have?"
> without needing an http request ?
Yes, definitely. The question is if we should implement a temporary
solution until we have the repository. IMO this is not necesarry since
it is "just" a performance issue.
The other option is to require meta data in a document, which reduces
the flexibility (but IMO to a still reasonable amount).
> Regarding implementation, maybe storing "type" as meta-data does the
> trick, and Document would have a getType() method. If this is possible,
> it should improve efficiency significantly, plus clarity of code.
+1
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] component management
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
> (snip)
Wow, so many issues ... let's try to take them one by one
>>
>> WorkflowResolverImpl and DocumentTypeResolverImpl are currently not
>> poolable, because the methods getSituation() respectively resolve()
>> use the request in its implementation. The request is obtained from
>> the context, which is obtained at initialization.
>> Maybe it would be better to make the interfaces of these services more
>> explicit, so that they would not rely on the request being passed at
>> initialization.
>
>
> That's probably a good idea. I already wondered about that when I
> integrated the Cron block, which doesn't provide a "normal" request
> at all. My workaround was to setup the CommandLineRequest.
This is indeed further motivation to get the http request out of the
implementation of these services.
>
>
> (... skipping WorkflowResolverImpl for now ...)
>
>> - in DocumentTypeResolverImpl, the request is used to read the webapp
>> context path, which is then used to construct the document URL. I
>> think this would need to be changed anyway, if documents are no longer
>> files in the webapp's path ?
>
>
> Hmmm, why would that have to be changed? The DocumentManager operates on
> sources. The contextPath is just an URL snippet, it won't change when
> we introduce the repository.
That is true. But actually I'm wondering about something else in this
class now: why is the document type for a document resolved upon every
request ? The knowledge "document A is of type B" is something quite
static, so shouldn't the model reflect this somehow ?
Please forgive my naivete if this is too simplistic :) But it seems to
me the model should know "What document type does a document have?"
without needing an http request ?
Regarding implementation, maybe storing "type" as meta-data does the
trick, and Document would have a getType() method. If this is possible,
it should improve efficiency significantly, plus clarity of code.
WDYT ?