-
1. Re: JIRA updated
dan.j.allen Mar 4, 2010 12:29 PM (in response to pmuir)Excellent. I'm excited to get to alpha1, so I say let's move forward.
The only change that I would suggest before alpha1 is to rename the container artifactIds as follows, just so that they are right to start with:
- arquillian-jbossas-remote-60
- arquillian-jbossas-remote-51
- arquillian-jbossas-embedded-60
- arquillian-glassfish-embedded-v3
Or should the prefix be "container-"?
Also, shouldn't the groupId be org.jboss.arquillian.container rather than just org.jboss.arquillian? My concern is that container is not represented in either the groupId or the artifactId, so it is sort of ambiguous.
-
2. Re: JIRA updated
aslak Mar 4, 2010 12:42 PM (in response to dan.j.allen)we should do this before alpha-1, just so we don't start alpha-2 with a big refactoring.
I suggest:
groupid: org.jboss.arquillian.container
artifactid: jbossas-remote-60, jbossas-remote-51, jbossas-embedded-60, glassfish-embedded-v3
And we move the container-* folders down a level to contianer/jboss-as...
I can get on this tomorrow morning if accepted .. ?
-
3. Re: JIRA updated
dan.j.allen Mar 4, 2010 2:17 PM (in response to aslak)+1
Except that I think we should go ahead and keep the "arquillian-" prefix on the artifactId because, remember, that becomes the name of the JAR file and it is customary to qualify the JAR w/ the project name...at least that's what I'm seeing when I look at other JBoss projects.
So:
groupId: org.jboss.arquillian.container
artifactId: arquillian-jbossas-remote-60, arquillian-jbossas-remote-51, arquillian-jbossas-embedded-60, arquillian-glassfish-embedded-v3
-
4. Re: JIRA updated
aslak Mar 4, 2010 3:19 PM (in response to dan.j.allen)excellent point!
https://jira.jboss.org/jira/browse/ARQ-78
One little problem tho, all the articles use the old names.
Using Arquillian to test a possible bug in Weld - http://community.jboss.org/message/527086
Testing a JMX Portable Extension for CDI - http://community.jboss.org/message/529016
Seam 3 JMS Module Testing with Arquillian - http://community.jboss.org/wiki/Seam3JMSModuleTestingwithArquillian
With admin rights I guess we can just edit them ? -
5. Re: JIRA updated
aslak Mar 5, 2010 6:32 AM (in response to dan.j.allen)Project structure reorg:
Type Directory GroupId ArtifactId api/spi/impl ./ org.jboss.arquillian arquillian-* packager ./packagers org.jboss.arquillian.packager arquillian-packager-*
container ./containers org.jboss.arquillian.container arquillian-container-* testenricher ./testenrichers org.jboss.arquillian.testenricher arquillian-testenricher-* protocol ./protocols org.jboss.arquillian.protocol arquillian-protocol-* https://jira.jboss.org/jira/browse/ARQ-81
-
6. Re: JIRA updated
dan.j.allen Mar 5, 2010 7:49 AM (in response to aslak)Nice work.
I've got a few nit pick items. Perhaps you just haven't gotten to the last two yet.
- I would recommend renaming packagers/java-ee to packagers/javaee since that's how Snoracle abbreviates it (see http://java.sun.com/javaee/)
- The JBoss AS containers should be prefixed jbossas (to be consistent w/ http://jboss.org/jbossas)
- GlassFish still needs the v3 qualifier
This is a nice step forwards towards looking sharp!
-
7. Re: JIRA updated
aslak Mar 5, 2010 8:18 AM (in response to dan.j.allen)Thank you.. we should probably do the same for openejb and weld containers?
https://jira.jboss.org/jira/browse/ARQ-82
-
8. Re: JIRA updated
dan.j.allen Mar 5, 2010 9:13 AM (in response to aslak)I would say yes for openejb. I'm not sure about weld, though. Maybe Pete can chime in.
The motivation for adding the major version number is that different major versions of application servers tend to have completely different deployment APIs. There is no real standard there. What works for JBoss AS 6 may not work for JBoss AS 7. (Btw, I'm not sure we need 51 and 60, rather just 5 and 6). Again, I'd like to hear what Pete has to say. The idea is to minimize the artifacts, but w/o causing conflicts.
With weld, we are trying to standardize the bootstrap API, so it is much less likely to change (meaning we wouldn't need two separate implementations).
-
9. Re: JIRA updated
pmuir Apr 16, 2010 10:44 AM (in response to dan.j.allen)Sorry, to respond so late.
Unfortunately JBoss AS has a habit of changing it's deployment API between every release, minor major, so I guess we need to do both 51 and 60.
With Weld, Aslak, what deployment/bootstrap API are you using?
-
10. Re: JIRA updated
aslak Apr 16, 2010 6:05 PM (in response to pmuir){code:java}
WeldBootstrap bootstrap = new WeldBootstrap();bootstrap.startContainer(Environments.SE, deployment, new ConcurrentHashMapBeanStore()).startInitialization().deployBeans().validateBeans().endInitialization();WeldManager manager = bootstrap.getManager(beanArchive);{code}
-
11. Re: JIRA updated
dan.j.allen Apr 17, 2010 12:20 AM (in response to aslak)Hmm, that could be simplified if Weld#initialize() were overloaded to accept a deployment and WeldContainer#getBeanManager() returned a WeldManager. With these changes in place, the bootstrap code would be simplified to:
WeldContainer weld = new Weld().initialize(deployment); WeldManager manager = weld.getBeanManager(); ... weld.shutdown();
Should we create an issue for this change in both Weld SE and Arquillian?
-
12. Re: JIRA updated
aslak Apr 17, 2010 2:37 PM (in response to dan.j.allen)Yea i noticed the same when I creating the Weld Container. I made the patch already, but never spoke to Peter Royle about it.
{code:java}
Index: src/main/java/org/jboss/weld/environment/se/Weld.java===================================================================--- src/main/java/org/jboss/weld/environment/se/Weld.java (revision 6123)+++ src/main/java/org/jboss/weld/environment/se/Weld.java (working copy)@@ -20,6 +20,7 @@import org.jboss.weld.bootstrap.api.Bootstrap;import org.jboss.weld.bootstrap.api.Environments;import org.jboss.weld.bootstrap.spi.BeanDeploymentArchive;+import org.jboss.weld.bootstrap.spi.Deployment;import org.jboss.weld.context.api.BeanStore;import org.jboss.weld.context.api.helpers.ConcurrentHashMapBeanStore;import org.jboss.weld.environment.se.beans.InstanceManager;@@ -68,12 +69,20 @@@PostConstructpublic WeldContainer initialize(){+ return initialize(+ new SEWeldDeployment() { }+ );+ }- SEWeldDeployment deployment = new SEWeldDeployment()- {- };+ /**+ * Boots Weld and creates and returns a WeldContainer instance, through which+ * beans and events can be accesed.+ */+ @PostConstruct+ public WeldContainer initialize(Deployment deployment)+ {bootstrap.startContainer(Environments.SE, deployment, this.applicationBeanStore);- final BeanDeploymentArchive mainBeanDepArch = deployment.getBeanDeploymentArchives().get(0);+ final BeanDeploymentArchive mainBeanDepArch = deployment.getBeanDeploymentArchives().iterator().next();this.manager = bootstrap.getManager(mainBeanDepArch);bootstrap.startInitialization();bootstrap.deployBeans();@@ -84,7 +93,6 @@InstanceManager instanceManager = WeldManagerUtils.getInstanceByType(manager, InstanceManager.class);return new WeldContainer(instanceManager, manager);-}/**{code}
I think the issue that I had with it was that the API didn't really match.
Deployment != BeanManager
It would be a odd limitation in the Weld SE API to only support the first BeanDeploymentArchive
{code:java}
final BeanDeploymentArchive mainBeanDepArch = deployment.getBeanDeploymentArchives().get(0);
{code}
So I ended up copying how Weld SE did it instead..
-
13. Re: JIRA updated
pmuir Apr 19, 2010 4:54 AM (in response to aslak)I don't think this is a suitable change to Weld SE - a standard Java SE container has no notion of non-homogenous deployments that I know of, so specifying the deployment structure is uncessary. I also don't think leaking WeldManager onto the Weld SE SPI is a good idea - this is part of the Weld SPI (for container integration) and so shouldn't be used by most containers
The current approach is definitely the one we intended you to take!
-
14. Re: JIRA updated
pmuir Apr 19, 2010 5:42 AM (in response to pmuir)Talking to Aslak on IRC, we reached the following conclusions:
- Current support should be rebadged Weld SE container
- Should add support for a Weld "EE mocks" container that mocks out the EE SPI (like the current TestContainer)
- TestContainer and mocks should be moved into this module when the Weld core tests + TCK is converted to Arqullian (from weld-core-tests)