David M. Lloyd wrote:
On 04/07/2009 11:37 AM, Carlo de Wolf wrote:
> So to rephrase:
> A functional requirement of Embedded is that we want to be able to
> easily configure a data source as per given pseudo code. (Other
> deployable elements to follow.)
> This would require changes in jboss-deployers and jboss-metadata. No
> change is needed in jboss-embedded, jboss-reloaded and/or
> jboss-bootstrap.
I don't think it would (or should) require changes to these modules at
all. It should be an additional Embedded configuration API which
*consumes* the various underlying metadata. This would have the added
advantage of being able to configure lots of unrelated things using
one simple API like Emmanuel's original suggestion. There's no reason
that the users of Embedded should have to know all about the different
metadata layouts of the various components, any more than the average
AS user should have to know.
I could say here: looking forward to your patches.
:-P
In reality Embedded will never know about all the metadata that can be
deployed. Primarily because this is directly related to the profile you
boot up. It's like Embedded having another PersistenceMetaData class
because that one is easier than the original.
That'll never fly, what if I don't boot up JPA? If PersistenceMetaData
needs to be simplified it needs to happen in JPA deployers / metadata or
a new JPA simplified-metadata component.
Guys, modularization is one thing but it's critical that we think
about the API that the end-user will actually end up using. If it's
not easy to use, nobody will use it, period. That equals failure in
my book. I for one would rather use an API like Emmanuel suggested
than all the dozens of different metadata classes and the ugly MC
deployer API.
I agree and am happy to say that most of these components are in
active
use by EJB 3 and JCA for unit testing.
I also agree that we got ugly APIs, so if possible that should be addressed.
- DML
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development Carlo