[weld-dev] Supporting namespaces in Java EE config files (non-portable feature for JBoss AS)

[Pete Muir]

No, I am talking about things like jboss-web.xml vs web.xml, application.xml vs jboss-app.xml etc. components.xml and pages.xml are stuff from Seam2. I am specifically talking about vendor extensions to specs where vendors introduce their own config files to control the their spec extensions

On 25 Nov 2009, at 16:31, Arbi Sookazian wrote:

> So I take it you're specifically referring to components.xml and pages.xml (and not faces-config.xml)?  If you could fine, but then what happens if the dev wants to port to another integration fwk and eliminate Seam3 (not that anybody would really do that!)  

TBH if someone takes an existing large app that has Seam deeply in it and decides to remove Seam, editing a config file is probably the easiest bit for them ;-) Don't be fooled into thinking that you can delete a few config files, delete some jars and your app magically keeps going

> Instead of deleting Seam-specific xml files, you must edit EE-specific xml files.  But I guess that may not be a big deal.
> 
> It seems cleaner to me and easier to read/understand the configs if you have separate Seam-specific xml files for it...  Of course, it may be easier for users b/c it's less files to worry about...

Exactly. Of course you would still have the option of splitting things out if you are anal about this kind of stuff.

> 
> I would consider Seam to be an extension of JEE, so if you "collapse" data in EE-specific xml files, then that may be considered an intrusion of sorts...

If you think like this, you probably aren't using Seam - this stuff "intrudes" into your app in many places ;-)

> 
> On Wed, Nov 25, 2009 at 6:02 AM, Pete Muir <pmuir at redhat.com> wrote:
> Hi Jason,
> 
> Something that came up during our Seam team meeting was the issue of config files again. We wanted to investigate again why we can't put namespaced elements into existing java ee config files such as application.xml, ejb-jar.xml, web.xml, but instead have to provide our own... Of course, this is non portable, but it would make life easier for users in our opinion.
> 
> Previously we have heard that this would cause us to fail the TCK, but given that this code would never run in the EE TCK, I can't see how.
> 
> Any ideas?
> 
> Pete
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>