commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lin <xuhua....@gmail.com>
Subject Re: [chain] questions about various servlet/*Mapper classes
Date Thu, 03 Mar 2005 20:46:12 GMT
To answer your second question, the current release of ChainServlet
actually sets the catalog object as a ServletContext (not chain
context) attribute or a request attribute depending if CONFIG_ATTR is
set or not. I guess the original idea may be that the chain context
(i,e ServletWebContext) will encapsulate how catalog is stored so a
command doesn't need to know where it's stored in order to retrieve a
catalog.(The ServeltPathMapper is a command that needs to get a
catalog to further dispatch commands.) But it seems this is broken
(may be there is a problem in the ServletWebContext.)

To fix this, let's first consider how a catalog can be retrieved.
Suppose a command retrieves a catalog from the CatalogFactory (either
the default one or a named one and this is the case when CONFIG_ATTR
is not set), now the problem becomes how it knows the catalog name.
One way is to hard code the catalog name in the command. Another way
is
to retrieve the name from the chain context. I think the later one is
more flexible (especially for a generic command like ServletPathMapper
command), even though it incurs one more step. (This command has a
setCatalogKey method, but I'm not sure how this method can be called.
Since you can't call this method from the containing servlet because
the servlet only knows about the generic command interface.)

The code will look like this (in ServletPathMapper)
	Catalog catalog = null;
        String catalog_name = (String) context.get(getCatalogKey());
	if (catalog_name != null)
        {
            catalog = CatalogFactory.getInstance().getCatalog(catalog_name);
        }
        else
        {
            catalog = CatalogFactory.getInstance().getCatalog();
        } 

In order for this scheme to work, the ChainProcessor needs to set the
name in the context, like this (in ChainProcessor):

	if (attribute == null) {
            // save catalog in CATALOG_DEFAULT, 
	    //	no need to save theCatalog, which can be retrieved by catalogFactory
            //request.setAttribute(CATALOG_DEFAULT, theCatalog);
            context.put(CATALOG_DEFAULT, catalog);
        }

Let's see if this will work when CONFIG_ATTR is set (compatibility
issue). Basically the command needs to know if CONFIG_ATTR is set. If
it's set, it will retrieve the catalog from ServletContext (Or
ServletWebContext, which is a chain context. We may need to fix it to
hide where catalog is stored.) Here is the final code in
ServletPathMapper:
	Catalog catalog = null;
        String catalog_name = (String) context.get(getCatalogKey());
        String attr = (String) context.get(ChainProcessor.CONFIG_ATTR);
        if (attr != null) // find catalog through ServletContext
        {
            catalog = (Catalog) swcontext.getContext().getAttribute(attr);
        }
        else if (catalog_name != null) //find catalog through catalog name
        {
            catalog = CatalogFactory.getInstance().getCatalog(catalog_name);
        }
        else
        {
            catalog = CatalogFactory.getInstance().getCatalog();
        }

(If both CONFIG_ATTR and CATALOG are set, we need to decide which one
take precedence.)

The relevent change in ChainProcessor:

	if (attribute != null) {
            context.put(CONFIG_ATTR, attribute);
        }
        else
        {
            context.put(CATALOG_DEFAULT, catalog);
        }

This approach bypassed fixing the chain context. But it's working. Thanks,

Howard    
 
On Wed, 2 Mar 2005 19:02:05 -0600, Joe Germuska <Joe@germuska.com> wrote:
> At 5:02 PM -0500 3/2/05, Howard Lin wrote:
> >Thanks, I'll file a bug in the Bugzilla. It seems the problem is that
> >in ChainProcessor, there is no need to save the catalog as a request
> >attribute since CatalogFactory already had it,  it only needs to save
> >the catalog name in the context so the next command can retrieve the
> >catalog name and use that to retrieve the catalog. If CONFIG_ATTR is
> >set, ChainProcessor should put that value in the context too so the
> >next command can retrieve value of CONFIG_ATTR and get the catalog
> >through the ServletContext. If this seems the right way to fix it, I
> >can submit patches.
> 
> Again, I haven't used the ChainServlet or its siblings.  I was going
> to argue that, for backwards compatibility, the Catalog itself should
> be put in the request and the context, but then, it seems that no one
> would have ever been able to use it as released, so I'm not sure how
> much we should be worried about compatibility!
> 
> Still, I'm not sure I think it's bad to pass the Catalog object
> instead of its name in those places.  I'm not sure I can think of any
> particular reason to decide either way, although I guess it is one
> less step to retrieve a usable Catalog object than to get its name
> and look it up.
> 
> >  If CONFIG_ATTR is
> >set, ChainProcessor should put that value in the context too so the
> >next command can retrieve value of CONFIG_ATTR and get the catalog
> >through the ServletContext.
> 
> This part I'm not really clear on at all; why would anything get the
> catalog from the ServletContext?  As written, the use of CONFIG_ATTR
> is to put the catalog in the chain Context so that other commands can
> use it to look up yet other commands?  This may not be necessary, as
> in general the generic command implementations that are part of
> commons-chain know how to use CatalogFactory, so they need only be
> configured with a catalog name.  But what type of code would retrieve
> a catalog from the ServletContext?  That's the part which I think is
> obsolete.
> 
> Can you clarify what you suggest doing?
> 
> Thanks
>         Joe
> 
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message