Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hmm, ok we currently have a o.a.c.environment.Context which has some functions from the servlet context object and attributes. Currently these attributes are not really used.We already have cocoon.context, couldn't we make things available from there?Mmmh... don't know if it's a good idea, as the Cocoon core currently doesn't rely on custom attributes in the environment objects (unless I'm mistaken). This would complexify things a bit, IMO.
That's what I pointed out above: the Cocoon core currently makes no use of attributes in env-context, session and request. These are for application use, and up to now the Cocoon core has not "polluted" these objects.
And we have o.a.a.context.Context which is a map containing many important information about the application.
Yep. Let's list what's in avalon-context.
The main DefaultContext is initialized with:
- Constants.CONTEXT_ENVIRONMENT_CONTEXT : the environment context (type o.a.c.e.Context)
- Constants.CONTEXT_WORK_DIR : Cocoon's work directory (type File)
- ContextHelper.CONTEXT_ROOT_URL : the servlet context's URL (type String - why not URL?)
- Constants.CONTEXT_UPLOAD_DIR : the upload directory (type File)
- Constants.CONTEXT_CACHE_DIR : the cache directory (type File)
- Constants.CONTEXT_CONFIG_URL : location of cocoon.xconf (type URL, used only to initialize the Cocoon object)
- Constants.CONTEXT_DEFAULT_ENCODING : default form encoding (type String)
- Constants.CONTEXT_CLASS_LOADER : CocoonServlet's classloader (type ClassLoader, used only to initialize the Cocoon object)
- Constants.CONTEXT_CLASSPATH : the classpath used by the XSP engine (type String)
The actual Context seen by applications is a ComponentContext that wraps the above DefaultContext with:
- ContextHelper.CONTEXT_OBJECT_MODEL : the current object model (type Map)
- ContextHelper.CONTEXT_SITEMAP_SERVICE_MANAGER : the current sitemap's service manager
- ComponentContext.OBJECT_MODEL_KEY_PREFIX : prefix to access members of the object model (could be removed, as only used in the implementation of ContextHelper.getRequest()/getResponse())
When in HTTP environment, there's also: - CocoonServlet.CONTEXT_SERVLET_CONFIG : the ServletConfig
When in portlet environment, there's also - CocoonPortlet.CONTEXT_PORTLET_CONFIG: the PortletConfig
For me it seems that two contexts is one too much :)
Makes sense. And migrating some stuff to the env-context may help removing some dependencies on Avalon. But whe have to be very careful about what attributes we want to move from avalon-context to env-context, and be sure they will still make sense in a new container and within blocks.
So, why not combining those somehow. Currently you get the o.a.c.e.Context from the avalon context.
Now, we could for example store all information we currently have in the avalon context into the environment context and using the environment context as the only reference for application information. If you need this context you can get it from the avalon context. The avalon context only contains this single piece of information (of course for compatibility we let everything remain there as well).
The only point I'm not sure about is the object model: should it be in the env-context, since it also contains that env-context? Kind of circular dependency that may be confusing...
What we need actually is some kind of mini-environment that would give access only to the "safe" properties of o.a.c.e.Environment, i.e. mainly the object model and attributes, plus access to the current avalon-context attributes through type-safe getter methods.
Then in flow, cocoon.context works perfect.
Yupp. <rt>And with an IOC type2/3 container we could even totally remove the dependency on avalon-context by simply have a setContext(o.a.c.e.Context) method ;-)</rt>
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
