9:10 a.m.
Max and I discovered a way to change the permission scheme for a
project to correctly reflect the project. The main change you will see
is that:
* even if you are a member of the committers group, you no longer have
committer privileges on the project - if I forgot to add you to the
list of project committers, then please ping me
* the assignee list is now limited to the list of project committers :-)
This has been done for all WB projects.
7:40 a.m.
New subject: [webbeans-dev] wb-ri-int deployers tests
Just a simple update on what I've been doing with WBINT.
Due to the two issues:
(a) WBINT-15; does auto CL isolation really work?
(b) WBINT-16; wrapped WB war in ear doesn't work
I first checked (b), which confirmed a bug in how we did dynamic
classpath addition.
In order to do proper CL testing, I needed to move tests + support code
under org.jboss.test.deployers packages, since that's how our MC
BootstrapTest knows which classes to exclude.
e.g. the test can of course get a hold of test classes,
but that doesn't mean that they should leak into the deployments we test
Since we add WB Bootstrap bean into top level deployment,
that top level needs to see wb-core.jar (which is what wasn't happening
with WBINT-16).
Hence the split into 2 URLIntegrationDeployers:
(1) one that adds wb-core.jar to top level if any beans.xml is found
(2) another that adds faces/ to any web deployment + beans.xml is found
in metadata locations
For (a) I added new CLIsolationTestCase, which actually proved that the
automatic CL isolation worked properly.
Or, at least the deployers we have, are kicking in as they should.
But this is still an issue to be tested in a real JBossAS env -
something Shelly is working on.
-Ales
8:47 a.m.
New subject: [webbeans-dev] wb-ri-int deployers tests
On 15 Jul 2009, at 13:40, Ales Justin wrote:
Since we add WB Bootstrap bean into top level deployment,
that top level needs to see wb-core.jar (which is what wasn't
happening with WBINT-16).
NB we have https://jira.jboss.org/jira/browse/WBINT-17 which removes
the need for adding the jar into the deployment (it can just be a
library jar) which should mean that non-isolated CL will work
(assuming we also do https://jira.jboss.org/jira/browse/WBINT-18).
3:24 a.m.
New subject: [webbeans-dev] wb-ri-int deployers tests
> Since we add WB Bootstrap bean into top level deployment,
> that top level needs to see wb-core.jar (which is what wasn't
> happening with WBINT-16).
NB we have https://jira.jboss.org/jira/browse/WBINT-17 which removes the
need for adding the jar into the deployment (it can just be a library
jar) which should mean that non-isolated CL will work (assuming we also
do https://jira.jboss.org/jira/browse/WBINT-18).
The original idea was to add this dynamically depending on the version
of WB.
But since most of WB libs is already shared - part of wb.deployer folder
- I guess this is really no longer needed/useful.
Although I think we should re-visit this, once we do proper CL versioning,
so the users could actually run different versions on WB in single AS
instance.
9:31 a.m.
New subject: [webbeans-dev] wb-ri-int deployers tests
On 20 Jul 2009, at 09:24, Ales Justin wrote:
>> Since we add WB Bootstrap bean into top level deployment,
>> that top level needs to see wb-core.jar (which is what wasn't
>> happening with WBINT-16).
> NB we have https://jira.jboss.org/jira/browse/WBINT-17 which
> removes the need for adding the jar into the deployment (it can
> just be a library jar) which should mean that non-isolated CL will
> work (assuming we also do https://jira.jboss.org/jira/browse/WBINT-18)
> .
The original idea was to add this dynamically depending on the
version of WB.
I don't think this is useful as WB is a core part of EE6, so we will
always have only one "supported" [1] version of WB.
[1] which we run the TCK against etc.
I'm not convinced that encouraging people to use X versions of WB in
AS is a good idea really ;-) People should be coding against a 299
version, which remains stable. Only case is if we have people relying
on buggy behaviour....
But since most of WB libs is already shared - part of wb.deployer
folder - I guess this is really no longer needed/useful.
Although I think we should re-visit this, once we do proper CL
versioning,
so the users could actually run different versions on WB in single
AS instance.
1:06 p.m.
New subject: [webbeans-dev] wb-ri-int deployers tests
On Mon, Jul 20, 2009 at 10:31 AM, Pete Muir <pmuir(a)redhat.com> wrote:
On 20 Jul 2009, at 09:24, Ales Justin wrote:
>>> Since we add WB Bootstrap bean into top level deployment,
>>> that top level needs to see wb-core.jar (which is what wasn't
>>> happening with WBINT-16).
>> NB we have https://jira.jboss.org/jira/browse/WBINT-17 which
>> removes the need for adding the jar into the deployment (it can
>> just be a library jar) which should mean that non-isolated CL will
>> work (assuming we also do https://jira.jboss.org/jira/browse/WBINT-18)
>> .
>
> The original idea was to add this dynamically depending on the
> version of WB.
I don't think this is useful as WB is a core part of EE6, so we will
always have only one "supported" [1] version of WB.
[1] which we run the TCK against etc.
I'm not convinced that encouraging people to use X versions of WB in
AS is a good idea really ;-) People should be coding against a 299
version, which remains stable. Only case is if we have people relying
on buggy behaviour....
Even then you would likely replace the official version with an older
version, as opposed to running two at the same time.
Btw, if you were to allow for multiple versions of WB, then you would also
open the door to multiple versions of EJB. As Pete said, part of the value
proposition of the AS is to have a single, sanctioned versions of these APIs
and implementations present.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
1:10 p.m.
New subject: [webbeans-dev] wb-ri-int deployers tests
Yeah, I don't entirely get Ales' use case for this either ;-)
I can see it would make more sense with some of the Seam 3 modules
where we aren't enforcing compatibility quite so much.
On 20 Jul 2009, at 19:06, Dan Allen wrote:
On Mon, Jul 20, 2009 at 10:31 AM, Pete Muir <pmuir(a)redhat.com>
wrote:
On 20 Jul 2009, at 09:24, Ales Justin wrote:
>>> Since we add WB Bootstrap bean into top level deployment,
>>> that top level needs to see wb-core.jar (which is what wasn't
>>> happening with WBINT-16).
>> NB we have https://jira.jboss.org/jira/browse/WBINT-17 which
>> removes the need for adding the jar into the deployment (it can
>> just be a library jar) which should mean that non-isolated CL will
>> work (assuming we also do https://jira.jboss.org/jira/browse/WBINT-18)
>> .
>
> The original idea was to add this dynamically depending on the
> version of WB.
I don't think this is useful as WB is a core part of EE6, so we will
always have only one "supported" [1] version of WB.
[1] which we run the TCK against etc.
I'm not convinced that encouraging people to use X versions of WB in
AS is a good idea really ;-) People should be coding against a 299
version, which remains stable. Only case is if we have people relying
on buggy behaviour....
Even then you would likely replace the official version with an
older version, as opposed to running two at the same time.
Btw, if you were to allow for multiple versions of WB, then you
would also open the door to multiple versions of EJB. As Pete said,
part of the value proposition of the AS is to have a single,
sanctioned versions of these APIs and implementations present.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
9:49 a.m.
New subject: [webbeans-dev] wb-ri-int deployers tests
Yeah, I don't entirely get Ales' use case for this either ;-)
:-)
I had Seam or Spring lib/frmwrk in mind, where you probably don't wanna
force the user to use a certain version.
In this case I guess it's different, as you two said, WB compares to EJB,
hence there is no need for multiple co-existing versions.
I can see it would make more sense with some of the Seam 3 modules
where
we aren't enforcing compatibility quite so much.
Yeah, we could see if this makes sense there.
5635
days inactive
5647
days old
7 comments
3 participants
participants (3)
-
Ales Justin -
Dan Allen -
Pete Muir