Web beans questions and comments

[swd847]

I have been looking through the final draft and I have to say it looks very good, I do have a few questions however:

1) Is the application scope shared between wars or is it similar to seam where it is per-war? From reading the spec I think it is shared, but I just wanted to double check.

2) In a multi war environment is it possible to scope bean definitions to a single war? e.g. a common request in seam is to have a different authenticator component depending on the war.

3)Looking at the portable extensions stuff it looks like a portable extesion will not have to do its own scanning because it can take advantage of the ProcessAnnotatedType event, is this correct? If this is the case, would it not also be good to have events for other general resources such as xml files? The use case I am thining of in particular is writing a portable extension to read legacy seam2 components.xml files, if would be a shame to have to do the scanning twice.

Thanks,

Stuart

[pmuir]

Stuart Douglas wrote on Jun 24, 2009 08:18:


1) Is the application scope shared between wars or is it similar to seam where it is per-war? From reading the spec I think it is shared, but I just wanted to double check.

It's shared (at least that is how I read the spec and implemented it).

2) In a multi war environment is it possible to scope bean definitions to a single war? e.g. a common request in seam is to have a different authenticator component depending on the war.

Yes, see section 5.1.

3)Looking at the portable extensions stuff it looks like a portable extesion will not have to do its own scanning because it can take advantage of the ProcessAnnotatedType event, is this correct? If this is the case, would it not also be good to have events for other general resources such as xml files? The use case I am thining of in particular is writing a portable extension to read legacy seam2 components.xml files, if would be a shame to have to do the scanning twice.

CDI doesn't define any scanning semantics for deployment descriptors. This is perhaps something for the EE platform, or a future release of the spec.

TBH, I'm not sure the same arguments apply, loading XML files using the classloader is relatively cheap compared to class scanning.

[pmuir]

Pete Muir wrote on Jun 24, 2009 14:38:


TBH, I'm not sure the same arguments apply, loading XML files using the classloader is relatively cheap compared to class scanning.

Yeah, this is definitely the case, remember that the only XML file that CDI touches is beans.xml, whilst it scans most classes. Definitely one for EE.

[gavin.king]

Stuart Douglas wrote on Jun 24, 2009 08:18:


I have been looking through the final draft and I have to say it looks very good, I do have a few questions however:

1) Is the application scope shared between wars or is it similar to seam where it is per-war? From reading the spec I think it is shared, but I just wanted to double check.

Yes. In a war deployment it is war-level. In an ear deployment it is ear-level. I will clarify that in the spec.

2) In a multi war environment is it possible to scope bean definitions to a single war?

Yes, that is possible.

3)Looking at the portable extensions stuff it looks like a portable extesion will not have to do its own scanning because it can take advantage of the ProcessAnnotatedType event, is this correct?

Right, that's the idea :-)

If this is the case, would it not also be good to have events for other general resources such as xml files? The use case I am thining of in particular is writing a portable extension to read legacy seam2 components.xml files, if would be a shame to have to do the scanning twice.

I think it's already easy enough for extensions to load resources like XML files. I don't think this needs to be in the SPI.

[swd847]

Thanks for the info, but now I have another question.

Say I want to load beans from some kind of xml format and have them scoped to the war module, to do this would I have to create a child of the target class using javassist that I then explicitly load using the appropriate web applications class loader, and have my implementation of Bean return this generated class in the getBeanClass() method?

[gavin.king]

No, two different Beans, or even two different AnnotatedTypes can have the same underlying Class.

[swd847]

Even two different beans that are scoped to different modules?

[pmuir]

Assuming the EE classloader allows this (which it does in certain circumstances) then this wouldn't be a problem.