-
1. Re: Portable extensions and Alternatives
swd847 Nov 18, 2009 4:57 AM (in response to swd847)Oops, I was thinking of the old deployment types, where did all that stuff go? I'm not going to list all the beans in an xml file. What if I have 100 mock objects?
-
2. Re: Portable extensions and Alternatives
swd847 Nov 18, 2009 5:04 AM (in response to swd847)Hmm, it looks like it would be possible to get something like deployment types back as a portable extension (by simply vetoing the beans that you don't want to install), which answers my original question.
-
3. Re: Portable extensions and Alternatives
gavin.king Nov 18, 2009 5:19 AM (in response to swd847)@Alternative @Stereotype is equivalent to the old deployment type stuff. See refdoc section 13.1.
-
4. Re: Portable extensions and Alternatives
swd847 Nov 18, 2009 5:23 AM (in response to swd847)Ah, I was looking in the wrong section of the spec.
-
5. Re: Portable extensions and Alternatives
nickarls Nov 18, 2009 8:43 PM (in response to swd847)Now that JNDI namespaces are standardized, it would be nice to have an extension that would flip alternatives based on JNDI data so that you could drop the same application into different appservers (with same JNDI key, different data) and it would auto-configure.
-
6. Re: Portable extensions and Alternatives
swd847 Nov 18, 2009 9:09 PM (in response to swd847)As far as I can tell there is no way for a portable extension to change what alternatives are deployed, is that correct Gavin?
It can just veto any beans it does not want installed, which amounts to the same thing really.
-
7. Re: Portable extensions and Alternatives
nickarls Nov 18, 2009 9:12 PM (in response to swd847)Perhaps one could nuke the list of URLs to bean.xml and replace them with a custom one(?)
-
8. Re: Portable extensions and Alternatives
gavin.king Nov 18, 2009 9:13 PM (in response to swd847)That is correct. If people really have a usecase for this, it would be an easy enough thing to add. We're already planning on adding a Module and ProcessModule to the SPI.
-
9. Re: Portable extensions and Alternatives
swd847 Nov 18, 2009 11:05 PM (in response to swd847)A few uses cases
- Automatically install correct framework components depending on the application server. e.g. if seam 3 is going to support @Transactional(REQUIRES_NEW) then the websphere code for this is going to be totally different to the general case, it would be neat if this could just happen automatically.
- Allow for more understandable end user configuration, e.g. from a properties file:
someFeatureEnabled=true useSomeOtherFeature=false
- Allow for configuration from JNDI or system properties.
If this was allowed it makes it much easier to create an app that can just be dropped in without having to open up the archive and change beans.xml.
-
10. Re: Portable extensions and Alternatives
gavin.king Nov 18, 2009 11:57 PM (in response to swd847)I don't really see how layering this stuff over the @Alternative mechanism helps you very much here. Why not just put if ( .. ) { ... } in the code of your portable extension?
-
11. Re: Portable extensions and Alternatives
swd847 Nov 19, 2009 12:16 AM (in response to swd847)I just though that it would be nice to have another way to configure this stuff other than an XML file. Having the ability to enable or disable beans based on system properties or other things can be a lot easier to manage than editing an XML file inside an archive.
e.g. if you have 10 different sites that need different configurations you need to maintain 10 different versions of beans.xml (well probably not because you could use token replacement or something like that, but it is still more difficult to manage).
-
12. Re: Portable extensions and Alternatives
asookazian Nov 19, 2009 12:22 AM (in response to swd847)
Stuart Douglas wrote on Nov 19, 2009 00:16:
I just though that it would be nice to have another way to configure this stuff other than an XML file. Having the ability to enable or disable beans based on system properties or other things can be a lot easier to manage than editing an XML file inside an archive.
e.g. if you have 10 different sites that need different configurations you need to maintain 10 different versions of beans.xml (well probably not because you could use token replacement or something like that, but it is still more difficult to manage).Agree. I'm not down with this possible multiple beans.xml per EAR hard requirement (one per WAR, one per EAR, one per JAR).
-
13. Re: Portable extensions and Alternatives
nickarls Nov 19, 2009 8:41 AM (in response to swd847)Well, BeanDeployment.parseBeansXml() gets all the beans.xml:s from the deployment archive and processes these. If I have an extension that adds a bean.xml from JNDI (and that file only contains an alternative stereotype), isn't this sort of autoconfiguring? Hmmm, can I get to the deployment archivies from an extension during bootstrap, gotta check.
-
14. Re: Portable extensions and Alternatives
nickarls Nov 19, 2009 8:55 AM (in response to swd847)Apparently they get tossed around with the BeforeBeanDiscovery-event