Hi Alex,
> I've run into a snag where I've set an attribute on the
> context to pass along environment information to parts of
> my application. When I pass the attribute via the context
> in the constructor, the constructor can get access to the
> attribute but later on the getContext() method's return
> doesn't have that attribute. I assume that is because the
> "parent" context's attributes aren't available to the
> "current" context.
You report an issue similar to Chuck. The idea is indeed to isolate the
parent component's attributes and parameters from the contained
applications.
[...]
> In the createRoot(), the getContext() call is return a
> different instance.
True, it returns a wrapper context that has its own attributes and
parameters. The parent dispatcher is reused and enhanced to provide URI
templating support and support for the war:// scheme.
> Should the attributes of the parent be available?
>
> If not, how is one suppose to pass along contextual configuration
> information to parts of your application.
Just like this:
Application myApp = new MyApplication(getContext());
myApp.getContext().getAttributes().put("att1", value1);
myApp.getContext().getParameters().add("param1", "value1");
> In my case, each Application instance is loaded from specific
> jar files and given a number of environment objects via attirbutes
> on the Context instance. Should I be doing this differently?
If you want to ensure the portability of your Application and preserve its
"self-contained" aspect, you shouldn't rely on environment attributes. When
we add support for WAR packaging in 1.1, we will provide a way to declare
parameters to be set on the Application, but not for Attributes. Instead,
each application should initialize its own attribute objects based on
environment parameters for example.
> A similar use case would be the "JDBC data source" in that if
> the application creates the data source, how does should it pass that
> along to arbitrary resources that use the data source?
Application attributes are definitely available for this kind of usage. You
should just set them inside your Application rather that externally inside
the Component code.
> It also isn't clear what the difference between parameters
> and attributes of are in the context.
Parameters are series/list of Parameter instances (name/value String pairs)
that are primarily intended for configuration purpose, like Java properties.
The "attributes"
property is a map of objects whose primarily purpose is to share contextual
objects
among all Restlets and Resources of an Application. I've clarified the
Javadocs
regarding those differences.
> Finally, in some situations (like my agent example where I load an
> jar file containing the application), I want to provide access to
> certain objects via, say, attributes but I don't want the Application
> instance to be able to change that object. Since getAttributes() and
> getParameters() return modifiable collections, that gets a bit
> complicated.
>
> I've now resorted to:
>
> Context agentContext = new Context() {
> Map<String,Object> attrs =
> Collections.unmodifiableMap(getContext().getAttributes());
> public Map<String,Object> getAttributes() {
> return attrs;
> }
> public Uniform getDispatcher() {
> return getContext().getDispatcher();
> }
> public Logger getLogger() {
> return getContext().getLogger();
> }
> public Series<Parameter> getParameters() {
> return getContext().getParameters();
> }
> };
>
> but that seems like it might be useless if the context is
> shadowed somehow.
This makes sense and the attributes set by your application (in the
constructor or in the createRoot() method) should be fully available to
attached Restlets and Resources. The "shadowing" only takes place between
the parent component and the contained applications.
Changes to Javadocs committed to SVN.
Best regards,
Jerome
