[weld-issues] [JBoss JIRA] Commented: (CDITCK-215) ProcessSessionBeanTest testProcessSessionBeanEvent count
[
https://issues.jboss.org/browse/CDITCK-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607939#comment-12607939
]
David Blevins commented on CDITCK-215:
--
Ok, I see what you're talking about. This is cool.
{code}
public class Example {
{
// will compile
Red red = new Red();
Color color = red;
// will not compile
Circle circle = new Circle();
Shape shape = circle;
}
public static class Foo {}
public static class Color {}
public static class Red extends Color {}
public static class Shape {}
public static class Circle extends Shape {}
}
{code}
> ProcessSessionBeanTest testProcessSessionBeanEvent count
>
>
> Key: CDITCK-215
> URL: https://issues.jboss.org/browse/CDITCK-215
> Project: CDI TCK
> Issue Type: Bug
> Security Level: Public(Everyone can see)
>Affects Versions: 1.0.4.Final
>Reporter: David Blevins
>Assignee: Pete Muir
>
> [Side note maybe there should be versions for 1.0.4.SP1 and 1.0.4.SP2]
> Test:
> org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent
> Not sure if this is an issue or not, so filling this as a bug and not a
> challenge. The test essentially has two observer methods and is asserting
> that only one of them are called.
> public void observeElephantSessionBean(@Observes
> ProcessSessionBean event)
> {
> ProcessBeanObserver.elephantProcessSessionBean = event;
> }
> public void observeElephantBean(@Observes ProcessBean event)
> {
> ProcessBeanObserver.elephantProcessBeanCount++;
> }
> Specifically the test asserts that observeElephantSessionBean is called and
> that observeElephantBean is not called.
> Currently we call both because ProcessSessionBean is assignable to
> ProcessBean and the generics are the same.
> Is there a part of the spec that mandates only the most specific observer
> method is called?
> The only thing I can find is in 10.4 which says pretty clearly:
> There may be arbitrarily many observer methods with the same event
> parameter type and qualifiers.
> A bean (or extension) may declare multiple observer methods.
> Well I guess it's not that clear as it says essentially "this may happen"
> rather than "this may happen...and when it does the behavior is...[all are
> invoked || only the most specific is invoked]"
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (CDITCK-213) Interceptor classes in TCK do not follow the Interceptor spec
[ https://issues.jboss.org/browse/CDITCK-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607797#comment-12607797 ] Pete Muir commented on CDITCK-213: -- Hi Bob, Sorry for that, should be fixed now. Thanks! > Interceptor classes in TCK do not follow the Interceptor spec > - > > Key: CDITCK-213 > URL: https://issues.jboss.org/browse/CDITCK-213 > Project: CDI TCK > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tests >Affects Versions: 1.0.4.Final >Reporter: Bob Nettleton > Fix For: 1.0.5.CR1 > > > There are some interceptor-related suites in the CDI TCK that are not > portable in some situations. The interceptor classes listed here: > org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.MissileInterceptor > org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.MissileInterceptor > org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.MissileInterceptor > These interceptor classes do not have a public, no-args constructor, which is > required by the Interceptor 1.1 specification. This means that the tests may > not be portable to all environments, since application servers may choose to > treat this as an error condition. > The following tests are affected by this issue: > org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.SessionBeanInterceptorOrderTest.testInterceptorsDeclaredUsingInterceptorsCalledBeforeInterceptorBinding > org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest.testNonContextualSessionBeanReferenceIsIntercepted > org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.SessionBeanInterceptorDefinitionTest.testSessionBeanIsIntercepted > I request that these tests be excluded from the 1.0.4 suite, and that the > interceptors be fixed for subsequent versions of the test suite. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Updated: (WELD-888) Interceptors not resolvable from a WAR-module which is part of an EAR-deployment
[ https://issues.jboss.org/browse/WELD-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SBS JIRA Integration updated WELD-888: -- JBoss Forum Reference: http://community.jboss.org/message/570912#570912 > Interceptors not resolvable from a WAR-module which is part of an > EAR-deployment > > > Key: WELD-888 > URL: https://issues.jboss.org/browse/WELD-888 > Project: Weld > Issue Type: Bug > Components: Interceptors and Decorators >Affects Versions: 1.1.1.Final > Environment: - Weld 1.1.1. Final on JBoss 6.0 GA and JBoss 6.1 > nightly > - tested and confirmed on Vista 32 and Linux 64 >Reporter: Jan Groth > Attachments: probear-jar.zip, probear.zip > > > It seems like CDI interceptors cannot be accessed from inside a WAR-module of > an EAR deployment if the interceptor is defined inside a dependent JAR which > is located in the EAR/lib directory. > BUT: > - Managed beans and producers from the same JAR work without problems. > - Moving the dependency from EAR/lib to WAR/WEB-INF/lib makes the interceptor > work without problems. > I consider that a serious problem, because this is a substantial restriction > for enterprise applications. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (CDITCK-215) ProcessSessionBeanTest testProcessSessionBeanEvent count
[
https://issues.jboss.org/browse/CDITCK-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607788#comment-12607788
]
Pete Muir commented on CDITCK-215:
--
Gurkan, I don't quite understand your comment.
Regardless, an Event is fired that has the following types:
ProcessSessionBean, ProcessManagedBean, ProcessBean,
Object.
We have an observer, ProcessBean.
As the resolution rules tell us, first we look for identical raw types, which
leaves with ProcessBean as the observer, and ProcessBean as
the event type. Now we must apply the rule I pasted - that Object must be
assignable to Elephant (which it isn't). Therefore this observer does not match.
> ProcessSessionBeanTest testProcessSessionBeanEvent count
>
>
> Key: CDITCK-215
> URL: https://issues.jboss.org/browse/CDITCK-215
> Project: CDI TCK
> Issue Type: Bug
> Security Level: Public(Everyone can see)
>Affects Versions: 1.0.4.Final
>Reporter: David Blevins
>
> [Side note maybe there should be versions for 1.0.4.SP1 and 1.0.4.SP2]
> Test:
> org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent
> Not sure if this is an issue or not, so filling this as a bug and not a
> challenge. The test essentially has two observer methods and is asserting
> that only one of them are called.
> public void observeElephantSessionBean(@Observes
> ProcessSessionBean event)
> {
> ProcessBeanObserver.elephantProcessSessionBean = event;
> }
> public void observeElephantBean(@Observes ProcessBean event)
> {
> ProcessBeanObserver.elephantProcessBeanCount++;
> }
> Specifically the test asserts that observeElephantSessionBean is called and
> that observeElephantBean is not called.
> Currently we call both because ProcessSessionBean is assignable to
> ProcessBean and the generics are the same.
> Is there a part of the spec that mandates only the most specific observer
> method is called?
> The only thing I can find is in 10.4 which says pretty clearly:
> There may be arbitrarily many observer methods with the same event
> parameter type and qualifiers.
> A bean (or extension) may declare multiple observer methods.
> Well I guess it's not that clear as it says essentially "this may happen"
> rather than "this may happen...and when it does the behavior is...[all are
> invoked || only the most specific is invoked]"
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Closed: (CDITCK-215) ProcessSessionBeanTest testProcessSessionBeanEvent count
[
https://issues.jboss.org/browse/CDITCK-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Muir closed CDITCK-215.
Assignee: Pete Muir
Resolution: Rejected
Closing as rejected as the test is correct.
> ProcessSessionBeanTest testProcessSessionBeanEvent count
>
>
> Key: CDITCK-215
> URL: https://issues.jboss.org/browse/CDITCK-215
> Project: CDI TCK
> Issue Type: Bug
> Security Level: Public(Everyone can see)
>Affects Versions: 1.0.4.Final
>Reporter: David Blevins
>Assignee: Pete Muir
>
> [Side note maybe there should be versions for 1.0.4.SP1 and 1.0.4.SP2]
> Test:
> org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent
> Not sure if this is an issue or not, so filling this as a bug and not a
> challenge. The test essentially has two observer methods and is asserting
> that only one of them are called.
> public void observeElephantSessionBean(@Observes
> ProcessSessionBean event)
> {
> ProcessBeanObserver.elephantProcessSessionBean = event;
> }
> public void observeElephantBean(@Observes ProcessBean event)
> {
> ProcessBeanObserver.elephantProcessBeanCount++;
> }
> Specifically the test asserts that observeElephantSessionBean is called and
> that observeElephantBean is not called.
> Currently we call both because ProcessSessionBean is assignable to
> ProcessBean and the generics are the same.
> Is there a part of the spec that mandates only the most specific observer
> method is called?
> The only thing I can find is in 10.4 which says pretty clearly:
> There may be arbitrarily many observer methods with the same event
> parameter type and qualifiers.
> A bean (or extension) may declare multiple observer methods.
> Well I guess it's not that clear as it says essentially "this may happen"
> rather than "this may happen...and when it does the behavior is...[all are
> invoked || only the most specific is invoked]"
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (CDITCK-216) No Support for standalone EJBContainer
[
https://issues.jboss.org/browse/CDITCK-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607779#comment-12607779
]
Pete Muir commented on CDITCK-216:
--
David, correct, we will address this in CDI 1.1
> No Support for standalone EJBContainer
> --
>
> Key: CDITCK-216
> URL: https://issues.jboss.org/browse/CDITCK-216
> Project: CDI TCK
> Issue Type: Bug
> Security Level: Public(Everyone can see)
>Reporter: David Blevins
> Fix For: 1.0.4.Final
>
>
> Actually pertains to [1.0.4.SP2]
> The ContainerEventTest has an ejb-jar.xml file that defines a stateful
> session bean which is otherwise not annotated and discoverable. The harness
> is not including this ejb-jar.xml in the 'deploy(InputStream archive, String
> name)' call on the Containers implement. The contents are as follows:
> {code}
> 2 Wed Jun 08 20:54:02 PDT 2011 META-INF/MANIFEST.MF
> 0 Wed Jun 08 20:54:02 PDT 2011 META-INF/beans.xml
>237 Wed Jun 08 20:54:02 PDT 2011 META-INF/jboss-test-harness.properties
>243 Wed Jun 08 20:54:02 PDT 2011
> META-INF/services/javax.enterprise.inject.spi.Extension
> 9369 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/AbstractJSR299Test.class
>860 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/api/JSR299Configuration.class
>824 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/DeploymentFailure.class
> 2712 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/ForwardingBean.class
> 3199 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/JSR299ConfigurationImpl.class
> 2690 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/JSR299PropertiesBasedConfigurationBuilder.class
> 1995 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/MockCreationalContext.class
> 3914 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/OldSPIBridge.class
> 2331 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/WebProfileMethodSelector.class
>497 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/AnyLiteral.class
>521 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/DefaultLiteral.class
>482 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/InjectLiteral.class
>572 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/NamedLiteral.class
>497 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/NewLiteral.class
>524 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/RetentionLiteral.class
>506 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/TargetLiteral.class
>557 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Beans.class
>684 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Contexts.class
>800 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/EL.class
>398 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Managers.class
>421 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Cheese.class
> 8613 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ContainerEventTest.class
>412 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Cow.class
>151 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/CowLocal.class
>834 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Farm.class
>405 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Food.class
>415 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Milk.class
> 3580 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ProcessAnnotatedTypeObserver.class
> 5054 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ProcessBeanObserver.class
> 6331 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ProcessInjectionTargetObserver.class
>697 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Sheep.class
>786 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/SheepInterceptor.class
>235 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/SheepLocal.class
>528 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Tame.class
> {code}
> Here's the toString() value of the harness Configuration in case that helps.
> Possibly there's some flag I need.
> {code}
> JSR 299 TCK Configuration
> -
> Beans: org.apache.openejb.tck.cdi.embedded.BeansImpl@61e090ee
> Containers: org.apache.openejb.tck.cdi.embedded.ContainersImpl@5e4b2b75
>
[weld-issues] [JBoss JIRA] Updated: (CDITCK-216) No Support for standalone EJBContainer
[
https://issues.jboss.org/browse/CDITCK-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Blevins updated CDITCK-216:
-
Summary: No Support for standalone EJBContainer (was: ContainerEventTest
and missing ejb-jar.xml file)
> No Support for standalone EJBContainer
> --
>
> Key: CDITCK-216
> URL: https://issues.jboss.org/browse/CDITCK-216
> Project: CDI TCK
> Issue Type: Bug
> Security Level: Public(Everyone can see)
>Reporter: David Blevins
> Fix For: 1.0.4.Final
>
>
> Actually pertains to [1.0.4.SP2]
> The ContainerEventTest has an ejb-jar.xml file that defines a stateful
> session bean which is otherwise not annotated and discoverable. The harness
> is not including this ejb-jar.xml in the 'deploy(InputStream archive, String
> name)' call on the Containers implement. The contents are as follows:
> {code}
> 2 Wed Jun 08 20:54:02 PDT 2011 META-INF/MANIFEST.MF
> 0 Wed Jun 08 20:54:02 PDT 2011 META-INF/beans.xml
>237 Wed Jun 08 20:54:02 PDT 2011 META-INF/jboss-test-harness.properties
>243 Wed Jun 08 20:54:02 PDT 2011
> META-INF/services/javax.enterprise.inject.spi.Extension
> 9369 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/AbstractJSR299Test.class
>860 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/api/JSR299Configuration.class
>824 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/DeploymentFailure.class
> 2712 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/ForwardingBean.class
> 3199 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/JSR299ConfigurationImpl.class
> 2690 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/JSR299PropertiesBasedConfigurationBuilder.class
> 1995 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/MockCreationalContext.class
> 3914 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/OldSPIBridge.class
> 2331 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/WebProfileMethodSelector.class
>497 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/AnyLiteral.class
>521 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/DefaultLiteral.class
>482 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/InjectLiteral.class
>572 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/NamedLiteral.class
>497 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/NewLiteral.class
>524 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/RetentionLiteral.class
>506 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/TargetLiteral.class
>557 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Beans.class
>684 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Contexts.class
>800 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/EL.class
>398 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Managers.class
>421 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Cheese.class
> 8613 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ContainerEventTest.class
>412 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Cow.class
>151 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/CowLocal.class
>834 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Farm.class
>405 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Food.class
>415 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Milk.class
> 3580 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ProcessAnnotatedTypeObserver.class
> 5054 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ProcessBeanObserver.class
> 6331 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ProcessInjectionTargetObserver.class
>697 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Sheep.class
>786 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/SheepInterceptor.class
>235 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/SheepLocal.class
>528 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Tame.class
> {code}
> Here's the toString() value of the harness Configuration in case that helps.
> Possibly there's some flag I need.
> {code}
> JSR 299 TCK Configuration
> -
> Beans: org.apache.openejb.tck.cdi.embedded.BeansImpl@61e090ee
> Containers: org.apache.openejb.tck.cdi.embedded.ContainersImpl@5e4b
[weld-issues] [JBoss JIRA] Resolved: (CDITCK-216) No Support for standalone EJBContainer
[
https://issues.jboss.org/browse/CDITCK-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Blevins resolved CDITCK-216.
--
Resolution: Won't Fix
Worked around it. Retitled and closing as "Won't Fix" as I'm assuming if any
change happens to support any Containers implementations using the embedded
EJBContainer API it would happen in CDI 1.1.
Work around was basically:
{code}
public boolean deploy(InputStream archive, String testClassNameAsArchive) {
final testClassName = testClassNameAsArchive.replace(".jar","");
// load testClass
// Grab @PersistenceXml and @EjbJarXml
// Add them to the archive
// do everything else as normal
}
{code}
> No Support for standalone EJBContainer
> --
>
> Key: CDITCK-216
> URL: https://issues.jboss.org/browse/CDITCK-216
> Project: CDI TCK
> Issue Type: Bug
> Security Level: Public(Everyone can see)
>Reporter: David Blevins
> Fix For: 1.0.4.Final
>
>
> Actually pertains to [1.0.4.SP2]
> The ContainerEventTest has an ejb-jar.xml file that defines a stateful
> session bean which is otherwise not annotated and discoverable. The harness
> is not including this ejb-jar.xml in the 'deploy(InputStream archive, String
> name)' call on the Containers implement. The contents are as follows:
> {code}
> 2 Wed Jun 08 20:54:02 PDT 2011 META-INF/MANIFEST.MF
> 0 Wed Jun 08 20:54:02 PDT 2011 META-INF/beans.xml
>237 Wed Jun 08 20:54:02 PDT 2011 META-INF/jboss-test-harness.properties
>243 Wed Jun 08 20:54:02 PDT 2011
> META-INF/services/javax.enterprise.inject.spi.Extension
> 9369 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/AbstractJSR299Test.class
>860 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/api/JSR299Configuration.class
>824 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/DeploymentFailure.class
> 2712 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/ForwardingBean.class
> 3199 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/JSR299ConfigurationImpl.class
> 2690 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/JSR299PropertiesBasedConfigurationBuilder.class
> 1995 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/MockCreationalContext.class
> 3914 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/OldSPIBridge.class
> 2331 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/impl/WebProfileMethodSelector.class
>497 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/AnyLiteral.class
>521 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/DefaultLiteral.class
>482 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/InjectLiteral.class
>572 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/NamedLiteral.class
>497 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/NewLiteral.class
>524 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/RetentionLiteral.class
>506 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/literals/TargetLiteral.class
>557 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Beans.class
>684 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Contexts.class
>800 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/EL.class
>398 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Managers.class
>421 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Cheese.class
> 8613 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ContainerEventTest.class
>412 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Cow.class
>151 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/CowLocal.class
>834 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Farm.class
>405 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Food.class
>415 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Milk.class
> 3580 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ProcessAnnotatedTypeObserver.class
> 5054 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ProcessBeanObserver.class
> 6331 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/ProcessInjectionTargetObserver.class
>697 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/Sheep.class
>786 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/SheepInterceptor.class
>235 Wed Jun 08 20:54:02 PDT 2011
> org/jboss/jsr299/tck/tests/extensions/container/event/
