Re: [webbeans-dev] TCK-Test --> ProducerFieldDefinitionTest#testNonStaticProducerFieldNotInherited
by Pete Muir
Hi Mark,
I suggest you take a look at the link I provided for you - you'll see
that this isn't a coverage report of the RI, but a coverage report of
the TCK to the spec. It also includes the added benefit of which
sentence in the spec a test is validating, along with highlighting to
pull out the specifics where the sentence makes many testable points.
Really, take a look - the answers to many of Gurkan's TCK questions so
far can be found by using it.
On 15 Mar 2009, at 09:33, Mark Struberg wrote:
>
> Pete,
>
> 1st, thanks for your help. We usually don't run the coverage reports
> of the RI because we do not like to look at your code too much. This
> shouldn't get a 1:1 copy of the RI but should proof that the Spec
> (+TCK) is enough to build a whole new JSR-299 implementation.
Agreed - I never suggested you look at the RI ;-)
>
>
> txs and LieGrue,
> strub
>
> --- Pete Muir <pmuir(a)redhat.com> schrieb am So, 15.3.2009:
>
>> Von: Pete Muir <pmuir(a)redhat.com>
>> Betreff: Re: [webbeans-dev] TCK-Test -->
>> ProducerFieldDefinitionTest#testNonStaticProducerFieldNotInherited
>> An: "Gurkan Erdogdu" <gurkanerdogdu(a)yahoo.com>
>> CC: webbeans-dev(a)lists.jboss.org
>> Datum: Sonntag, 15. März 2009, 0:28
>> Yes, this is why it is essential to
>> read the coverage report at the same time to understand what
>> is being tested.
>>
>> On 14 Mar 2009, at 23:25, Gurkan Erdogdu wrote:
>>
>>>
>>> It is very difficult to understand TCK tests that are
>> written by others and it gets so much time. So questions are
>> inevitable.
>>>
>>> In the mean time, Pete thanks for helping and
>> commenting. After that, I will attach jira issues for
>> all other my questions.
>>>
>>> Cheers;
>>>
>>> Gurkan
>>>
>>> From: Pete Muir <pmuir(a)redhat.com>
>>> To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com>
>>> Cc: webbeans-dev(a)lists.jboss.org
>>> Sent: Sunday, March 15, 2009 1:05:44 AM
>>> Subject: Re: [webbeans-dev] TCK-Test -->
>> ProducerFieldDefinitionTest#testNonStaticProducerFieldNotInherited
>>>
>>> No, this is testing that producer fields aren't
>> inherited by default.
>>>
>>> I suggest you read the spec-assertion matched, and
>> reference in the coverage report http://snapshots.jboss.org/maven2/org/jboss/jsr299/tck/jsr299-tck-impl/1....
>>>
>>> This list really isn't the right place to discuss this
>> - please either open JIRA issues or forum topics.
>>>
>>> On 14 Mar 2009, at 22:53, Gurkan Erdogdu wrote:
>>>
>>>> Hi ;
>>>>
>>>> In this test, InfertileChicken is selected for
>> Chicken API type, because DeploymentType precedence is
>> higher than Chicken. So *egg* field is called over
>> InfertileChicken.(Field parent instance API Type = Chicken
>> and Binding Type = @Current)
>>>>
>>>> But test is contradicted to this. Or any other
>> semantic exist?
>>>>
>>>> @AnotherDeploymentType
>>>> class InfertileChicken extends Chicken
>>>> {
>>>>
>>>> }
>>>>
>>>> class Chicken
>>>> {
>>>>
>>>> @Produces @Foo
>>>> private Egg egg = new Egg(this);
>>>>
>>>> }
>>>>
>>>> Thanks;
>>>>
>>>> Gurkan
>>>>
>>>>
>>>> _______________________________________________
>>>> webbeans-dev mailing list
>>>> webbeans-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>
>>> --
>>> Pete Muir
>>> http://www.seamframework.org
>>> http://in.relation.to/Bloggers/Pete
>>>
>>>
>>>
>>
>> --
>> Pete Muir
>> http://www.seamframework.org
>> http://in.relation.to/Bloggers/Pete
>>
>> _______________________________________________
>> webbeans-dev mailing list
>> webbeans-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>
>
>
>
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
15 years, 10 months
Re: [webbeans-dev] TCK-Test --> ProducerFieldDefinitionTest#testNonStaticProducerFieldNotInherited
by Mark Struberg
Pete,
1st, thanks for your help. We usually don't run the coverage reports of the RI because we do not like to look at your code too much. This shouldn't get a 1:1 copy of the RI but should proof that the Spec (+TCK) is enough to build a whole new JSR-299 implementation.
txs and LieGrue,
strub
--- Pete Muir <pmuir(a)redhat.com> schrieb am So, 15.3.2009:
> Von: Pete Muir <pmuir(a)redhat.com>
> Betreff: Re: [webbeans-dev] TCK-Test --> ProducerFieldDefinitionTest#testNonStaticProducerFieldNotInherited
> An: "Gurkan Erdogdu" <gurkanerdogdu(a)yahoo.com>
> CC: webbeans-dev(a)lists.jboss.org
> Datum: Sonntag, 15. März 2009, 0:28
> Yes, this is why it is essential to
> read the coverage report at the same time to understand what
> is being tested.
>
> On 14 Mar 2009, at 23:25, Gurkan Erdogdu wrote:
>
> >
> > It is very difficult to understand TCK tests that are
> written by others and it gets so much time. So questions are
> inevitable.
> >
> > In the mean time, Pete thanks for helping and
> commenting. After that, I will attach jira issues for
> all other my questions.
> >
> > Cheers;
> >
> > Gurkan
> >
> > From: Pete Muir <pmuir(a)redhat.com>
> > To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com>
> > Cc: webbeans-dev(a)lists.jboss.org
> > Sent: Sunday, March 15, 2009 1:05:44 AM
> > Subject: Re: [webbeans-dev] TCK-Test -->
> ProducerFieldDefinitionTest#testNonStaticProducerFieldNotInherited
> >
> > No, this is testing that producer fields aren't
> inherited by default.
> >
> > I suggest you read the spec-assertion matched, and
> reference in the coverage report http://snapshots.jboss.org/maven2/org/jboss/jsr299/tck/jsr299-tck-impl/1....
> >
> > This list really isn't the right place to discuss this
> - please either open JIRA issues or forum topics.
> >
> > On 14 Mar 2009, at 22:53, Gurkan Erdogdu wrote:
> >
> > > Hi ;
> > >
> > > In this test, InfertileChicken is selected for
> Chicken API type, because DeploymentType precedence is
> higher than Chicken. So *egg* field is called over
> InfertileChicken.(Field parent instance API Type = Chicken
> and Binding Type = @Current)
> > >
> > > But test is contradicted to this. Or any other
> semantic exist?
> > >
> > > @AnotherDeploymentType
> > > class InfertileChicken extends Chicken
> > > {
> > >
> > > }
> > >
> > > class Chicken
> > > {
> > >
> > > @Produces @Foo
> > > private Egg egg = new Egg(this);
> > >
> > > }
> > >
> > > Thanks;
> > >
> > > Gurkan
> > >
> > >
> > > _______________________________________________
> > > webbeans-dev mailing list
> > > webbeans-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/webbeans-dev
> >
> > --
> > Pete Muir
> > http://www.seamframework.org
> > http://in.relation.to/Bloggers/Pete
> >
> >
> >
>
> --
> Pete Muir
> http://www.seamframework.org
> http://in.relation.to/Bloggers/Pete
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
15 years, 10 months
Re: [webbeans-dev] TCK-Test --> ProducerFieldDefinitionTest#testNonStaticProducerFieldNotInherited
by Pete Muir
Yes, this is why it is essential to read the coverage report at the
same time to understand what is being tested.
On 14 Mar 2009, at 23:25, Gurkan Erdogdu wrote:
>
> It is very difficult to understand TCK tests that are written by
> others and it gets so much time. So questions are inevitable.
>
> In the mean time, Pete thanks for helping and commenting. After
> that, I will attach jira issues for all other my questions.
>
> Cheers;
>
> Gurkan
>
> From: Pete Muir <pmuir(a)redhat.com>
> To: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com>
> Cc: webbeans-dev(a)lists.jboss.org
> Sent: Sunday, March 15, 2009 1:05:44 AM
> Subject: Re: [webbeans-dev] TCK-Test -->
> ProducerFieldDefinitionTest#testNonStaticProducerFieldNotInherited
>
> No, this is testing that producer fields aren't inherited by default.
>
> I suggest you read the spec-assertion matched, and reference in the
> coverage report http://snapshots.jboss.org/maven2/org/jboss/jsr299/tck/jsr299-tck-impl/1....
>
> This list really isn't the right place to discuss this - please
> either open JIRA issues or forum topics.
>
> On 14 Mar 2009, at 22:53, Gurkan Erdogdu wrote:
>
> > Hi ;
> >
> > In this test, InfertileChicken is selected for Chicken API type,
> because DeploymentType precedence is higher than Chicken. So *egg*
> field is called over InfertileChicken.(Field parent instance API
> Type = Chicken and Binding Type = @Current)
> >
> > But test is contradicted to this. Or any other semantic exist?
> >
> > @AnotherDeploymentType
> > class InfertileChicken extends Chicken
> > {
> >
> > }
> >
> > class Chicken
> > {
> >
> > @Produces @Foo
> > private Egg egg = new Egg(this);
> >
> > }
> >
> > Thanks;
> >
> > Gurkan
> >
> >
> > _______________________________________________
> > webbeans-dev mailing list
> > webbeans-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
> --
> Pete Muir
> http://www.seamframework.org
> http://in.relation.to/Bloggers/Pete
>
>
>
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
15 years, 10 months
[webbeans-dev] TCK-Test --> ProducerFieldDefinitionTest#testNonStaticProducerFieldNotInherited
by Gurkan Erdogdu
Hi ;
In this test, InfertileChicken is selected for Chicken API type, because DeploymentType precedence is higher than Chicken. So *egg* field is called over InfertileChicken.(Field parent instance API Type = Chicken and Binding Type = @Current)
But test is contradicted to this. Or any other semantic exist?
@AnotherDeploymentType
class InfertileChicken extends Chicken
{
}
class Chicken
{
@Produces @Foo
private Egg egg = new Egg(this);
}
Thanks;
Gurkan
15 years, 10 months
[webbeans-dev] TCK-Test Related
by Gurkan Erdogdu
Hi,
I have more couple of questions and observations about TCK tests.
1* Conversation Related Tests : Are conversation related tests not depending on the JSF runtime? Because we are using the JSF semantic in project,
so all ConversationRelated standalone tests are failed.
2* Some of the standalone tests are related with Enterprise Beans. Some of them are grouped using "enterprisebean", but lots of them not. Its great to separate
the all EnterpriseBeans related tests with "enterprisebean" TestNG group. Therefore, we can easily test our non-enterprise beans part.
3* In test ProducerFieldDefinitionTest, there is a class
class FunnelWeaver<T>
{
}
This class is a ParametrizedType with Type variable, so it is not a simple web bean. But tests are dependent on this class. So we are getting
UnSatisfiedDependencyException. Is this correct behaviour?
4* Currently in the TCK Trunk, some of the tests are return "false" assertion, but it does not grouped into "stub".
Thanks;
Gurkan
15 years, 11 months
[webbeans-dev] DependentContextTest - testDestroyingSimpleParentDestroysDependents
by Gurkan Erdogdu
Hi,
In the above test,
@RequestScoped
class Farm
{
@Current Stable stable;
public void open() {};
}
Farm has normal scope, so we do not create its instance before any of its method is called. Therefore we do not inject fields of the Farm. But in the test case, it is assumed to create Farm instance and inject fields. So test fails in our implementation.
Is this normal?
Thanks;
Gurkan
15 years, 11 months
[webbeans-dev] TCK- Event Tests
by Gurkan Erdogdu
Hi;
When @Fires annotation exist in the field of the bean, there is an implicit bean and indeed this bean must be added to the Manager. But then
how to differentiate beans with the same API type (Event class) and Binding Type?
For example;
Class A{
@Fires Event<X> x;
}
Class B{
@Fires Event<Y> y;
}
In the tests using the resolveByType(Event.class, new FiresBinding(){}).
But in this case it throws the AmbigiousDependencyException. How could we resolve this? Or we understood wrongly;
Thanks;
Gurkan
15 years, 11 months
[webbeans-dev] AST processing
by Nicklas Karlsson
Hi,
I'm currently looking at https://jira.jboss.org/jira/browse/WBRI-166
for generating XSD of the packages
Annotation processors can easily be plugged in with -processor (and
in Eclipse) but they aren't run if there aren't any annotations and we
are interested in the whole package. There is the Compiler Tree API
from Sun that can be used for visiting compiled files but there is no
way
of plugging it into the compilation process automagically, is there?
Is there any other way of observing the compilation process?
---
Nik
15 years, 11 months
[webbeans-dev] web-beans.xml in reference guide
by Dan Allen
In the Web Beans reference guide, there are still references to
web-beans.xml. I believe the name of this file was changed to beans.xml.
Should I update the reference guide when I see inconsistencies like this, or
is there a global effort still outstanding?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
15 years, 11 months
