I'm saying that users are including jboss.xml, weblogic.xml, sun-j2ee-ri.xml, ... DDs in the deployment build because they want a one deployment unit works with all servers package.
> > This is not going to work as many users already have stated they > > create deployment units that contain all app server DDs and even > > proprietary descriptors for their own use. > > I don't think it would cause problems because I don't check if there > are "foe" DDs but if the archives misses necessary JBoss specific > DDs. That is how I think the test would work: > > JAR archvies: > - check if "jboss.xml" is there if not then it is treated as "foe" > This condition is true for many of our current ejb jars in the testsuite. > WAR archives: > - check if "jboss-web.xml" is there > - if not then check if another "foe" deployment descriptor is available > (I know this is weak and we have to go over it if this and check if > for the supported "foe"s this is true or if they can contain data > which > would not required a "jboss-web.xml" file). If FOUND then treat is > as "foe" > A jboss-web.xml descriptor is required even less frequently. > EAR archives: I don't know if there are vendor specific DDs but I guess > we don't need currently to make a mapping because we don't have a > JBoss specific DD for EARs. > Supporting third party deployment packages is to me a pure filtering service that should not affect our core deployment processing. Its a big enough mess in there as it is without this added in. _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
