Am 05.11.2003 um 03:08 schrieb Adrian Brock:
On Wed, 2003-11-05 at 01:53, Juha Lindfors wrote:On Wed, 5 Nov 2003, Holger Baxmann - bitwind wrote:Bill Burke wrote:LETS TAKE THESE DISCUSSIONS TO JBOSS-DEV PLEASE!!!!!
Yes, IMO, migration should be a separate distinct tool/step. We
should not be maintaining past versions of deployment descriptors in
4.0, 3.2, or 3.0. Anybody know what other vendors do?
Bill
Scott M Stark wrote:That is a possibility that Bill suggested before, but it excludes the possibility of supporting hot deploy with migration, something we can do. They will be exposed to xsl if there is a problem with the migration. Maybe migration should be a separate step.
Juha Lindfors wrote:
Migration yes. But for that XSL would work just as well, you just
run the
script to convert between the descriptors, right? The admin is never
actually exposed to reading or modifying the XSLT... ?
When does JBoss.org have the meta-model of the whole stuff defined in XSD and throuw the ugly DTD's away? Then one is able to appy XSLT on the XSD's and all migration things belonging to the meta-level are handled by the meta-level.
EJB 2.1 & J2EE 1.4 IIRC
Why don't we start different threads for different issues? This thread start out as discussing making management easier.
e.g. Joe Windows Admin wants a GUI Wizard entitled "Configure datasource" preferably one that does not ask if he writing letter :-) How does Joe hates-GUIs programmer (i.e. me) maintain that wizard and other management interfaces when I add configuration options to the jdbc rars or db specifc plugins?
The datasource is a good/pathological example because it also includes "advanced" configurations like the CMP mappings, jbossmq persistence config and the pad=true xid for Oracle. Showing disparate metadata needs to be combined in the management view/tool.
But this is exactly the use-case for a xsd-xslt. JBoss.org is providing a wholesale XML based on a wholesale XSD and joe average is xslt'ing it to fit his needs. Or bax is able to customize the build-test-deploy-configure cycle for his client without trial-and-error-sometime-look-into-the-source crap.
Why not generating the gui out of the xsd? Why not using the jdbc metadata for datasource config by changing the appropriate xml schema description, naturally on the fly at invocation time? What about a metadata interceptor? ;-)
Same content - different semantics.
bax
Regards, Adrian
-- Juha
IMHO
bax
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development-- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Director of Support Back Office JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
