[
https://issues.apache.org/jira/browse/JS2-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma closed JS2-794.
-------------------------
Resolution: Won't Fix
Fix Version/s: (was: 2.2)
I reviewed this proposal long time ago.
Problem with this is that it would either:
a) require separate schema definitions for each component (making it hard to
understand/remember)
b) have a global schema across all components, but that would result in
circular dependencies between all the components
Finally, such a schema won't help a bit for integrators/end users providing
their own extensions/customizations of certain component beans,
and those should be the real target users of an easier to use spring
configuration definition.
We've already move ahead with another, spring "filtering", solution which
allows us to provide multiple possible/common configurations before hand by us
(the developers)
but allow easy filtering on category which beans will be used/activated or not
at runtime.
> Use xbean-spring to provide a component-specific schema for spring bean
> configuration
> -------------------------------------------------------------------------------------
>
> Key: JS2-794
> URL: https://issues.apache.org/jira/browse/JS2-794
> Project: Jetspeed 2
> Issue Type: Improvement
> Components: Other
> Affects Versions: 2.2
> Reporter: David Jencks
> Assignee: David Jencks
> Attachments: JS2-794.patch
>
>
> I suggested that using xbean-spring to generate a component-specific schema
> for spring configuration would make configuring jetspeed easier, and this
> idea got some agreement on the dev list. I've done a little work in this
> direction but don't know if it actually works since 2.2 doesn't seem to build
> a functioning portal at the moment. I'm opening this issue to track work on
> this idea. So far I've added a schema generation project and added the
> javadoc "annotations" to get components into the schema for components
> mentioned in the administration and security-* spring config files.
> Committiing everything except the spring config files poses very little risk
> to functionality since the xbean context falls back to the normal spring
> context behavior when you aren't using the generated schema. Committing the
> spring config file changes might be riskier until we can more easily tell if
> they work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
