You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "David H. DeWolf" <dd...@apache.org> on 2006/10/18 13:52:19 UTC
[tiles2] TilesContextFactory refactor
SB-44 has been filed suggesting that the TilesContextFactory and it's
usages be refactored to remove the use of static methods. This will
allow different implementations of the factory to be used as an
extension point in Tiles.
When implementing this change, one thing that will be noticed is that
several places throughout the codebase utilize the factory statically to
create a new context. Once the refactoring is done, this will no longer
be possible without either providing static access to the factory
instance or passing around a reference to it. I'd to propose the
following changes instead:
1) TilesContext is refactored into two different contexts - TilesContext
and TilesRequestContext. Only one instance of the TilesContext should
exist within the application and it will be used to provide application
scoped functions (e.g. getResource() or getInitParameters()) . The
TilesRequestContext will provide request/response specific operations
(e.g. include() or getParameters()).
2) The TilesContext is instantiated by a configured instance of the
TilesContextFactory at startup (indirectly by the TilesServlet,
TilesFilter, TilesListener or any other initialization feature the
client decides to implement).
3) In the servlet/portlet environment the TilesContext will be saved as
a ServletContext attribute and will be retrieved from here by the tags
and other dependent objects. (Other environments will need their own
mechanism and will be handled in their initialization)
4) The TilesRequestContext will be created by a method on the
TilesContext (createRequestContext(request, response).
I think that this approach provides the following advantages.
1) Ensures the consistent state of the TilesContext (there will no
longer be some instance where it can perform request scoped operations
and others where it can not)
2) Allows us to easily propagate a single TilesContext to the entire
application without needing to utilize a static factory and/or finder.
Please let me know your thoughts.
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by Greg Reddin <gr...@apache.org>.
On Oct 19, 2006, at 10:24 AM, David H. DeWolf wrote:
>
> Antonio Petrelli wrote:
>> David H. DeWolf ha scritto:
>>> 1) TilesContext is refactored into two different contexts -
>>> TilesContext and TilesRequestContext. Only one instance of the
>>> TilesContext should exist within the application and it will be
>>> used to provide application scoped functions (e.g. getResource()
>>> or getInitParameters()) . The TilesRequestContext will provide
>>> request/response specific operations (e.g. include() or
>>> getParameters()).
>> It seems like a good idea, anyway I would like to know from Greg
>> if it is ok for him.
>
> Greg, any thoughts? I'm interested in your opinion too.
Yes, I'm looking at it. I hope to respond by the end of today.
Sorry for the delay.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by "David H. DeWolf" <dd...@apache.org>.
Antonio Petrelli wrote:
> David H. DeWolf ha scritto:
>> 1) TilesContext is refactored into two different contexts -
>> TilesContext and TilesRequestContext. Only one instance of the
>> TilesContext should exist within the application and it will be used
>> to provide application scoped functions (e.g. getResource() or
>> getInitParameters()) . The TilesRequestContext will provide
>> request/response specific operations (e.g. include() or getParameters()).
>
> It seems like a good idea, anyway I would like to know from Greg if it
> is ok for him.
>
Greg, any thoughts? I'm interested in your opinion too.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by "David H. DeWolf" <dd...@apache.org>.
send me the output/errors offline and we'll work through it.
David
Antonio Petrelli wrote:
> David H. DeWolf ha scritto:
>> I figured out what I did. . .when refactoring I renamed classes such
>> as TilesContextFactory to BasicTilesContextFactory and then created a
>> new TilesContextFactory for the interface. I guess the
>> rename-recreate sequence confused the three of us (me, subversion, and
>> patch ;) )
>>
>> Anywho. . .a new patch is now attached to the issue.
>
> The patch still does not apply correctly :-(
> Both Eclipse (Subclipse) and GnuWin32's "patch" command cannot parse it,
> it gives a lot of errors.
> I am guessing that maybe *I* am doing something wrong...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by Antonio Petrelli <ap...@apache.org>.
David H. DeWolf ha scritto:
> I figured out what I did. . .when refactoring I renamed classes such
> as TilesContextFactory to BasicTilesContextFactory and then created a
> new TilesContextFactory for the interface. I guess the
> rename-recreate sequence confused the three of us (me, subversion, and
> patch ;) )
>
> Anywho. . .a new patch is now attached to the issue.
The patch still does not apply correctly :-(
Both Eclipse (Subclipse) and GnuWin32's "patch" command cannot parse it,
it gives a lot of errors.
I am guessing that maybe *I* am doing something wrong...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by "David H. DeWolf" <dd...@apache.org>.
I figured out what I did. . .when refactoring I renamed classes such as
TilesContextFactory to BasicTilesContextFactory and then created a new
TilesContextFactory for the interface. I guess the rename-recreate
sequence confused the three of us (me, subversion, and patch ;) )
Anywho. . .a new patch is now attached to the issue. Regarding your
comments, see below
Antonio Petrelli wrote:
> David H. DeWolf ha scritto:
>> 1) TilesContext is refactored into two different contexts -
>> TilesContext and TilesRequestContext. Only one instance of the
>> TilesContext should exist within the application and it will be used
>> to provide application scoped functions (e.g. getResource() or
>> getInitParameters()) . The TilesRequestContext will provide
>> request/response specific operations (e.g. include() or getParameters()).
>
> It seems like a good idea, anyway I would like to know from Greg if it
> is ok for him.
Yes, me too.
>
>> 2) The TilesContext is instantiated by a configured instance of the
>> TilesContextFactory at startup (indirectly by the TilesServlet,
>> TilesFilter, TilesListener or any other initialization feature the
>> client decides to implement).
>
> For configuration, I would like something like the configuration of
> DefinitionsReader, take a look at UrlDefinitionsFactory for that.
Agreed. The current patch does not provide such configuration, it
simply instantiates the BasicTilesContextFactory and proceeds (one step
at a time). Once we have agreement and this patch committed, I'll go
ahead and implement the configuration as you suggest.
>
>> 3) In the servlet/portlet environment the TilesContext will be saved
>> as a ServletContext attribute and will be retrieved from here by the
>> tags and other dependent objects. (Other environments will need their
>> own mechanism and will be handled in their initialization)
>>
>> 4) The TilesRequestContext will be created by a method on the
>> TilesContext (createRequestContext(request, response).
>
> I think that a utility class could be, err..., useful :-)
If you prefer, yes, we could, however, it's not unreasonable to assume
that someone wanting to provide their own TilesContext implementation
would also want to implement their own TilesRequestContext. If the
former acts as a factory for the latter, they continue to work as a pair
and can be implemented together. By moving to a utility class we either
sacrifice this second customization point or have to manage the
propagation of yet another factory - and this time it'll be used
throughout the code instead of just at initialization.
>
> Great work David! I really liked your ideas. It's a pity that it is
> ruined by your patch, come on, clean it up! :-)
Tell me about it! If the darn new guy could just figure out how to use
some basic tools ;)
Thanks,
David
>
> Ciao
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by Antonio Petrelli <ap...@apache.org>.
David H. DeWolf ha scritto:
> 1) TilesContext is refactored into two different contexts -
> TilesContext and TilesRequestContext. Only one instance of the
> TilesContext should exist within the application and it will be used
> to provide application scoped functions (e.g. getResource() or
> getInitParameters()) . The TilesRequestContext will provide
> request/response specific operations (e.g. include() or getParameters()).
It seems like a good idea, anyway I would like to know from Greg if it
is ok for him.
> 2) The TilesContext is instantiated by a configured instance of the
> TilesContextFactory at startup (indirectly by the TilesServlet,
> TilesFilter, TilesListener or any other initialization feature the
> client decides to implement).
For configuration, I would like something like the configuration of
DefinitionsReader, take a look at UrlDefinitionsFactory for that.
> 3) In the servlet/portlet environment the TilesContext will be saved
> as a ServletContext attribute and will be retrieved from here by the
> tags and other dependent objects. (Other environments will need their
> own mechanism and will be handled in their initialization)
>
> 4) The TilesRequestContext will be created by a method on the
> TilesContext (createRequestContext(request, response).
I think that a utility class could be, err..., useful :-)
Great work David! I really liked your ideas. It's a pity that it is
ruined by your patch, come on, clean it up! :-)
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory
refactor)
Posted by Antonio Petrelli <ap...@apache.org>.
David H. DeWolf ha scritto:
> I don't see these factory implementations changing much.
> ...
You've been very clear, thank you :-)
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory
refactor)
Posted by "David H. DeWolf" <dd...@apache.org>.
I don't see these factory implementations changing much. Instead, what
will change is how tiles interfaces with surrounding frameworks.
Specifically how it is:
1) Configured/Initialized
2) Invoked
3) Destroyed
By surrounding frameworks.
Instead of utilizing a series of static invocations, what I envision is
a container being instantiated and initialized. When ever the framework
needs to invoke it, it will retrieve it - probably from a static cache
that it maintains or from the servlet context - and will invoke instance
methods.
What this does is create a "container" environment in which frameworks
can "inject" custom implementations of the different Factories/Service.
By taking this approach, I think it will be easier to support this
level of customization. We will also avoid the common classloader issue
which we briefly mentioned and thus be able to support multiple
application contexts if necessary (even though we decided it's not).
David
Antonio Petrelli wrote:
> Greg Reddin ha scritto:
>>
>> On Oct 26, 2006, at 8:03 AM, David H. DeWolf wrote:
>>
>>> I'll probably have some time to finish up the TilesContextFactory
>>> configuration today and start doing some work on removing
>>> duplication. Once I get through that I'll start putting some
>>> container ideas down into code. The first step of that process will
>>> be to define the tiles container api. What are those things that we
>>> want to expose to the world?
>> ... Antonio may have more input since he's working with some Tiles
>> extensions.
>
> The "extension" that Greg was writing about is Dimensions:
> http://mutidimensions.sf.net/
> In the HEAD of the CVS repository I am trying to port Dimensions to
> Tiles 2. Although it is not updated to the latest changes it could be
> helpful. In my case I created:
> * a class (KeyedComponentDefinitionsImpl) that extends
> ComponentDefinitionsImpl, allowing to store Tiles definition in a
> different manner (it uses the user's role and the calling device,
> besides locale, to store specific definitions);
> * a pair of classes (ChannelDefinitionsFactory and
> ConfigurableDefinitionsFactory) that extend UrlDefinitionsFactory, that
> interpret the HTTP request and return the correct definition, using
> KeyedComponentDefinitionsImpl for the storage.
> How does your "container" fit in?
>
> HTH
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory
refactor)
Posted by Antonio Petrelli <ap...@apache.org>.
Greg Reddin ha scritto:
>
> On Oct 26, 2006, at 8:03 AM, David H. DeWolf wrote:
>
>> I'll probably have some time to finish up the TilesContextFactory
>> configuration today and start doing some work on removing
>> duplication. Once I get through that I'll start putting some
>> container ideas down into code. The first step of that process will
>> be to define the tiles container api. What are those things that we
>> want to expose to the world?
> ... Antonio may have more input since he's working with some Tiles
> extensions.
The "extension" that Greg was writing about is Dimensions:
http://mutidimensions.sf.net/
In the HEAD of the CVS repository I am trying to port Dimensions to
Tiles 2. Although it is not updated to the latest changes it could be
helpful. In my case I created:
* a class (KeyedComponentDefinitionsImpl) that extends
ComponentDefinitionsImpl, allowing to store Tiles definition in a
different manner (it uses the user's role and the calling device,
besides locale, to store specific definitions);
* a pair of classes (ChannelDefinitionsFactory and
ConfigurableDefinitionsFactory) that extend UrlDefinitionsFactory, that
interpret the HTTP request and return the correct definition, using
KeyedComponentDefinitionsImpl for the storage.
How does your "container" fit in?
HTH
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory refactor)
Posted by Greg Reddin <gr...@apache.org>.
On Oct 26, 2006, at 8:03 AM, David H. DeWolf wrote:
> I'll probably have some time to finish up the TilesContextFactory
> configuration today and start doing some work on removing
> duplication. Once I get through that I'll start putting some
> container ideas down into code. The first step of that process
> will be to define the tiles container api. What are those things
> that we want to expose to the world?
It doesn't seem like much. The majority of what people will do with
Tiles is plug it into another architecture, so we need to focus on
the points where it interfaces with MVC architectures I think.
Beyond that, there will be cases where people want to create, modify,
and access definitions and attributes. I'd say keep the public API
as small as possible and add to it as requests come in. Antonio may
have more input since he's working with some Tiles extensions.
> Do we prefer to do the container work in a branch, or continue
> working on it in the trunk?
Either way is fine with me. I would prefer to just do it in the
trunk since it can be done incrementally.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
[tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory
refactor)
Posted by "David H. DeWolf" <dd...@apache.org>.
Greg Reddin wrote:
>
> On Oct 21, 2006, at 10:02 PM, David H. DeWolf wrote:
>
>> The one negative to this approach is that it will eliminate the
>> ability to support multiple contexts (when tiles is packaged in a
>> common classloader). The TilesUtil currently appears to be
>> implemented in a way which suggests that the original intent was to
>> support multiple contexts. That said, the support is already only
>> partial since Tiles utilizes several static accessors and instances
>> such as TilesUtilImpl will be shared across applications.
>
> I don't personally want to go to great lengths to support running Tiles
> in a common classloader. If it happens to work then fine. But I would
> not call it a best practice. Maybe there's situations where it is
> warranted, but I haven't personally encountered those.
Agreed.
>
>> The second approach that would solve this issue would be to refactor
>> the codebase to eliminate the prevalent use of static methods.
>> Instead, all tiles functionality could be configured and encapsulated
>> into a self contained "container" which would be cached and retrieved
>> when needed.
>
> I'm definitely in favor of this approach. I have no problem with static
> methods but, as Antonio has pointed out, it makes things more difficult
> to configure. I'm having a similar issue with MyFaces Tomahawk
> components where I'd like to modify a renderer but the modification is
> in a non-configurable static utility class. Also, caching objects as
> static members of utility classes in a multi-threaded environment is
> problematic at best. So, I'm definitely in favor of this aspect.
Ok, good to know.
>
>> In this scenario, the configuration servlet, filter, or listener,
>> would create the container and provide access to it from a publicly
>> available place (perhaps the underlying context). Whenever tiles were
>> needed, the client would retrieve the container and invoke it.
>> Services like the TilesUtil would be provided by the container, not
>> statically accessed.
>
> I like this approach. Since this is the place where other frameworks
> will have the most interaction with Tiles we should try to make it as
> straightforward as possible. This kinda goes along with SB-56 [1] that
> you opened doesn't it?
To a degree yes. SB-56 speaks to removing the duplication of
initialization logic. Encapsulating all tiles functionality into a
container would definitely promote/help that, but I can also imagine
ways to remove the duplication which don't promote the componantization
we're looking for from a container approach (e.g. create more static
utilities to do the initialization).
As moving in this direction is quite a large undertaking from it's
current state, my suggestion is that we complete it in steps - the first
of which is probably completing the TilesContextFactory configuration
using the current TilesUtil implementation. From there we can start
removing duplication and componentizing/containerizing tiles.
I'll probably have some time to finish up the TilesContextFactory
configuration today and start doing some work on removing duplication.
Once I get through that I'll start putting some container ideas down
into code. The first step of that process will be to define the tiles
container api. What are those things that we want to expose to the world?
Do we prefer to do the container work in a branch, or continue working
on it in the trunk?
David
>
> Greg
>
> [1] https://issues.apache.org/struts/browse/SB-56
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by Greg Reddin <gr...@apache.org>.
On Oct 21, 2006, at 10:02 PM, David H. DeWolf wrote:
> The one negative to this approach is that it will eliminate the
> ability to support multiple contexts (when tiles is packaged in a
> common classloader). The TilesUtil currently appears to be
> implemented in a way which suggests that the original intent was to
> support multiple contexts. That said, the support is already only
> partial since Tiles utilizes several static accessors and instances
> such as TilesUtilImpl will be shared across applications.
I don't personally want to go to great lengths to support running
Tiles in a common classloader. If it happens to work then fine. But
I would not call it a best practice. Maybe there's situations where
it is warranted, but I haven't personally encountered those.
> The second approach that would solve this issue would be to
> refactor the codebase to eliminate the prevalent use of static
> methods. Instead, all tiles functionality could be configured and
> encapsulated into a self contained "container" which would be
> cached and retrieved when needed.
I'm definitely in favor of this approach. I have no problem with
static methods but, as Antonio has pointed out, it makes things more
difficult to configure. I'm having a similar issue with MyFaces
Tomahawk components where I'd like to modify a renderer but the
modification is in a non-configurable static utility class. Also,
caching objects as static members of utility classes in a multi-
threaded environment is problematic at best. So, I'm definitely in
favor of this aspect.
> In this scenario, the configuration servlet, filter, or listener,
> would create the container and provide access to it from a publicly
> available place (perhaps the underlying context). Whenever tiles
> were needed, the client would retrieve the container and invoke it.
> Services like the TilesUtil would be provided by the container, not
> statically accessed.
I like this approach. Since this is the place where other frameworks
will have the most interaction with Tiles we should try to make it as
straightforward as possible. This kinda goes along with SB-56 [1]
that you opened doesn't it?
Greg
[1] https://issues.apache.org/struts/browse/SB-56
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by Martin Cooper <ma...@apache.org>.
On 10/25/06, David H. DeWolf <dd...@apache.org> wrote:
>
>
>
> Greg Reddin wrote:
> >
> > On Oct 24, 2006, at 3:23 AM, Antonio Petrelli wrote:
> >
> >> Now the question is: Why do you need multiple
> >> TilesApplicationContexts? Just curious :-)
> >
> > I think David was asking the same question. If Tiles is deployed in a
> > common classloader (i.e. Tomcat's common/lib directory) you'd want each
> > application to have its own TilesApplicationContext since each
> > application would have its own instances of the internal components
> > wrapped by TilesApplicationContext. That just sounds like more trouble
> > than it's worth supporting IMO :-) But, inevitably somebody will plunk
> > the tiles JAR down in common/lib and start hollering about things not
> > working. So we should probably at least document the issues with it.
> >
>
> Exactly: the only reason you'd need more than one would be when someone
> tries to get fancy and use common/lib. MHO is that not only is it more
> trouble than it's worth - using common/lib for a webapp library is also
> something we should discourage. Providing documented "non-support" is
> definitely a form of discouragement :)
Yep, the more we can discourage this kind of thing, the better. It'll save
everyone touble in the long run.
--
Martin Cooper
I'll go ahead and refactor to support only one TilesApplicationContext
> and then move forward with the configurabality feature.
>
> > Greg
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [tiles2] TilesContextFactory refactor
Posted by "David H. DeWolf" <dd...@apache.org>.
Greg Reddin wrote:
>
> On Oct 24, 2006, at 3:23 AM, Antonio Petrelli wrote:
>
>> Now the question is: Why do you need multiple
>> TilesApplicationContexts? Just curious :-)
>
> I think David was asking the same question. If Tiles is deployed in a
> common classloader (i.e. Tomcat's common/lib directory) you'd want each
> application to have its own TilesApplicationContext since each
> application would have its own instances of the internal components
> wrapped by TilesApplicationContext. That just sounds like more trouble
> than it's worth supporting IMO :-) But, inevitably somebody will plunk
> the tiles JAR down in common/lib and start hollering about things not
> working. So we should probably at least document the issues with it.
>
Exactly: the only reason you'd need more than one would be when someone
tries to get fancy and use common/lib. MHO is that not only is it more
trouble than it's worth - using common/lib for a webapp library is also
something we should discourage. Providing documented "non-support" is
definitely a form of discouragement :)
I'll go ahead and refactor to support only one TilesApplicationContext
and then move forward with the configurabality feature.
> Greg
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by Greg Reddin <gr...@apache.org>.
On Oct 24, 2006, at 3:23 AM, Antonio Petrelli wrote:
> David H. DeWolf ha scritto:
>> The one negative to this approach is that it will eliminate the
>> ability to support multiple contexts (when tiles is packaged in a
>> common classloader). The TilesUtil currently appears to be
>> implemented in a way which suggests that the original intent was
>> to support multiple contexts. That said, the support is already
>> only partial since Tiles utilizes several static accessors and
>> instances such as TilesUtilImpl will be shared across applications.
>
> Now the question is: Why do you need multiple
> TilesApplicationContexts? Just curious :-)
I think David was asking the same question. If Tiles is deployed in
a common classloader (i.e. Tomcat's common/lib directory) you'd want
each application to have its own TilesApplicationContext since each
application would have its own instances of the internal components
wrapped by TilesApplicationContext. That just sounds like more
trouble than it's worth supporting IMO :-) But, inevitably somebody
will plunk the tiles JAR down in common/lib and start hollering about
things not working. So we should probably at least document the
issues with it.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [tiles2] TilesContextFactory refactor
Posted by Antonio Petrelli <ap...@apache.org>.
David H. DeWolf ha scritto:
> The one negative to this approach is that it will eliminate the
> ability to support multiple contexts (when tiles is packaged in a
> common classloader). The TilesUtil currently appears to be
> implemented in a way which suggests that the original intent was to
> support multiple contexts. That said, the support is already only
> partial since Tiles utilizes several static accessors and instances
> such as TilesUtilImpl will be shared across applications.
Now the question is: Why do you need multiple TilesApplicationContexts?
Just curious :-)
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org