JBoss development, A new message was posted in the thread "Deprecating VFSDeployer": http://community.jboss.org/message/521641#521641 Author : Carlo de Wolf Profile : http://community.jboss.org/people/wolfc Message: -------------------------------------------------------------- In relation to the upgrade to VFS 3, why don't we deprecate VFSDeployer?   Right now we stand a chance that we'll get multiple deployer versions because version 1 needs to integrate with VFS 2 and version 2 on top of VFS 3. But most (if not all) of those deployers actually don't have any need for real file access.   For example:EjbAnnotationMetaDataDeployer [1] actually needs to use the results of the annotation scanner to work. DummiesSerializedMetaDataDeployer [2] only needs an InputStream on the underlying file. (Also note that parsing deployer is a counter-intuitive name, because it's actually an file or I/O deployer.)   In essence we could create an IODeployer in which we plug a DeploymentUnitIOManager and then have two implementations: VFS2DeploymentUnitIOManager and VFS3DeploymentUnitIOManager. Where it not that most deployers operate on a higher level abstraction anyway (classes or annotations etc.).   In short we need a blueprint which makes all deployers VFS independent. Thus instead of deprecating a lot of deployer components, we just refactor them properly and do not create an O(x) maintenance burden, but an O(2). :-)   [1] http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/de... [2] http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/reloaded/trun... -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521641#521641