[jboss-dev] JBoss Bootstrap, Embedded & Reloaded

[Carlo de Wolf]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
Carlo