[JBoss JIRA] (ARQ-1279) Create PortletArchive as Shrinkwrap archive type for portlets
by Ken Finnigan (JIRA)
Ken Finnigan created ARQ-1279:
---------------------------------
Summary: Create PortletArchive as Shrinkwrap archive type for portlets
Key: ARQ-1279
URL: https://issues.jboss.org/browse/ARQ-1279
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Extension - Portal
Reporter: Ken Finnigan
Assignee: Ken Finnigan
Fix For: portal_1.0.0.next
Create a PortletArchive implementation of WebArchive that provides specific methods for setting the portlet.xml descriptor in the archive.
Also look at providing helper methods for declaration of portlets in portlet.xml descriptor of the archive
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ARQ-1278) Warp: allow to verify application startup
by Lukáš Fryč (JIRA)
Lukáš Fryč created ARQ-1278:
-------------------------------
Summary: Warp: allow to verify application startup
Key: ARQ-1278
URL: https://issues.jboss.org/browse/ARQ-1278
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Extension - Warp
Reporter: Lukáš Fryč
Fix For: warp_1.next
We could register inspections for application startup events like CDI/JSF container initialization.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ARQ-841) Should not scan for classes in Archive if it contains no beans.xml
by Karim de Fombelle (JIRA)
[ https://issues.jboss.org/browse/ARQ-841?page=com.atlassian.jira.plugin.sy... ]
Karim de Fombelle edited comment on ARQ-841 at 1/21/13 3:30 AM:
----------------------------------------------------------------
Similar issue observed with Arquillian 1.0.3.Final / arquillian-weld-se-embedded-1.1 1.0.0.CR5 / weld-core 1.1.10.Final / Shrinkwrap 2.0.0-alpha-1
Arquillian performs micro deployment in a CDI container, according the container adapter and the container found in the developer classpath.
The deployed content is built in a test class in the method annotated with @Deployment
CDI specification (JSR-299) mentions that the container will scan for "managed bean" only _bean archives_, and those archives must contain a META-INF/bean.xml file
{quote} 12.1. Bean archives
Bean classes of enabled beans must be deployed in bean archives.
• A library jar, EJB jar, application client jar or rar archive is a bean archive if it has a file named beans.xml in the
META-INF directory.
(...)
The container searches for beans in all bean archives in the application classpath
{quote}
However, as illustrated in the test class below, without adding any descriptor, the content of the archive is scanned and beans are managed.
The injection below is successful whereas it is expected the test throws an "UnsatisfiedResolutionException."
Test case below:
{code}
@RunWith(Arquillian.class)
public class BeanXmlArquillianTest {
//~ ----------------------------------------------------------------------------------------------------------------
//~ Instance fields
//~ ----------------------------------------------------------------------------------------------------------------
@Inject
private Bean1 testBean;
//~ ----------------------------------------------------------------------------------------------------------------
//~ Methods
//~ ----------------------------------------------------------------------------------------------------------------
@Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class);
//.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");//sounds useless
}
@Test
public void testBeanInjected() {
assertNotNull(testBean);//test is green whereas it should not be
}
}
{code}
And bean:
{code}
public class Bean1{
}
{code}
The pom is attached.
was (Author: kdefombelle):
Similar issue observed with Arquillian 1.0.3.Final / arquillian-weld-se-embedded-1.1 1.0.0.CR5 / weld-core 1.1.10.Final / Shrinkwrap 2.0.0-alpha-1
Arquillian performs micro deployment in a CDI container, according the container adapter and the container found in the developer classpath.
The deployed content is built in a test class in the method annotated with @Deployment
CDI specification (JSR-299) mentions that the container will scan for "managed bean" only _bean archives_, and those archives must contain a META-INF/bean.xml file
{quote} 12.1. Bean archives
Bean classes of enabled beans must be deployed in bean archives.
• A library jar, EJB jar, application client jar or rar archive is a bean archive if it has a file named beans.xml in the
META-INF directory.
(...)
The container searches for beans in all bean archives in the application classpath
{quote}
However, as illustrated in the test class below, without adding any descriptor, the content of the archive is scanned and beans are managed.
The injection below is successful whereas it is expected the test throws an "UnsatisfiedResolutionException."
Test case below:
{code}
@RunWith(Arquillian.class)
public class BeanXmlArquillianTest {
//~ ----------------------------------------------------------------------------------------------------------------
//~ Instance fields
//~ ----------------------------------------------------------------------------------------------------------------
@Inject
private Bean1 testBean;
//~ ----------------------------------------------------------------------------------------------------------------
//~ Methods
//~ ----------------------------------------------------------------------------------------------------------------
@Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class);
//.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");//sounds useless
}
@Test
public void testBeanInjected() {
assertNotNull(testBean);
}
}
{code}
And bean:
{code}
public class Bean1{
}
{code}
The pom is attached.
> Should not scan for classes in Archive if it contains no beans.xml
> ------------------------------------------------------------------
>
> Key: ARQ-841
> URL: https://issues.jboss.org/browse/ARQ-841
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Weld Containers
> Affects Versions: weld_1.0.0.CR3
> Reporter: Aslak Knutsen
> Labels: starter
> Fix For: weld_1.1.0.next
>
> Attachments: pom.xml
>
>
> A deployment with no beans.xml should not result in Beans being registered in the Weld Container.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ARQ-841) Should not scan for classes in Archive if it contains no beans.xml
by Karim de Fombelle (JIRA)
[ https://issues.jboss.org/browse/ARQ-841?page=com.atlassian.jira.plugin.sy... ]
Karim de Fombelle edited comment on ARQ-841 at 1/21/13 3:30 AM:
----------------------------------------------------------------
Similar issue observed with Arquillian 1.0.3.Final / arquillian-weld-se-embedded-1.1 1.0.0.CR5 / weld-core 1.1.10.Final / Shrinkwrap 2.0.0-alpha-1
Arquillian performs micro deployment in a CDI container, according the container adapter and the container found in the developer classpath.
The deployed content is built in a test class in the method annotated with @Deployment
CDI specification (JSR-299) mentions that the container will scan for "managed bean" only _bean archives_, and those archives must contain a META-INF/bean.xml file
{quote} 12.1. Bean archives
Bean classes of enabled beans must be deployed in bean archives.
• A library jar, EJB jar, application client jar or rar archive is a bean archive if it has a file named beans.xml in the
META-INF directory.
(...)
The container searches for beans in all bean archives in the application classpath
{quote}
However, as illustrated in the test class below, without adding any descriptor, the content of the archive is scanned and beans are managed.
The injection below is successful whereas it is expected the test throws an "UnsatisfiedResolutionException."
Test case below:
{code}
@RunWith(Arquillian.class)
public class BeanXmlArquillianTest {
//~ ----------------------------------------------------------------------------------------------------------------
//~ Instance fields
//~ ----------------------------------------------------------------------------------------------------------------
@Inject
private Bean1 testBean;
//~ ----------------------------------------------------------------------------------------------------------------
//~ Methods
//~ ----------------------------------------------------------------------------------------------------------------
@Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class);
//.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");//sounds useless
}
@Test
public void testBeanInjected() {
assertNotNull(testBean);
}
}
{code}
And bean:
{code}
public class Bean1{
}
{code}
The pom is attached.
was (Author: kdefombelle):
Similar issue observed with Arquillian 1.0.3.Final / arquillian-weld-se-embedded-1.1 1.0.0.CR5 / weld-core 1.1.10.Final / Shrinkwrap 2.0.0-alpha-1
Arquillian performs micro deployment in a CDI container, according the container adapter and the container found in the developer classpath.
The deployed content is built in a test class in the method annotated with @Deployment
CDI specification (JSR-299) mentions that the container will scan for "managed bean" only _bean archives_, and those archives must contain a META-INF/bean.xml file
{quote} 12.1. Bean archives
Bean classes of enabled beans must be deployed in bean archives.
• A library jar, EJB jar, application client jar or rar archive is a bean archive if it has a file named beans.xml in the
META-INF directory.
(...)
The container searches for beans in all bean archives in the application classpath
{quote}
However, as illustrated in the test class below, without adding any descriptor, the content of the archive is scanned and beans are managed.
The injection below is successful whereas it is expected the test throws an "UnsatisfiedResolutionException."
Test case below:
{code}
@RunWith(Arquillian.class)
public class BeanXmlArquillianTest {
//~ ----------------------------------------------------------------------------------------------------------------
//~ Instance fields
//~ ----------------------------------------------------------------------------------------------------------------
@Inject
private Bean1 testBean;
//~ ----------------------------------------------------------------------------------------------------------------
//~ Methods
//~ ----------------------------------------------------------------------------------------------------------------
@Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class);
//.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");//sounds useless
}
@Test
public void testBeanInjected() {
assertNotNull(testBean);
}
}
{code}
And bean:
{code}
package org.jboss.arquillian.junit;
public class Bean1{
}
{code}
The pom is attached.
> Should not scan for classes in Archive if it contains no beans.xml
> ------------------------------------------------------------------
>
> Key: ARQ-841
> URL: https://issues.jboss.org/browse/ARQ-841
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Weld Containers
> Affects Versions: weld_1.0.0.CR3
> Reporter: Aslak Knutsen
> Labels: starter
> Fix For: weld_1.1.0.next
>
> Attachments: pom.xml
>
>
> A deployment with no beans.xml should not result in Beans being registered in the Weld Container.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ARQ-841) Should not scan for classes in Archive if it contains no beans.xml
by Karim de Fombelle (JIRA)
[ https://issues.jboss.org/browse/ARQ-841?page=com.atlassian.jira.plugin.sy... ]
Karim de Fombelle edited comment on ARQ-841 at 1/21/13 3:29 AM:
----------------------------------------------------------------
Similar issue observed with Arquillian 1.0.3.Final / arquillian-weld-se-embedded-1.1 1.0.0.CR5 / weld-core 1.1.10.Final / Shrinkwrap 2.0.0-alpha-1
Arquillian performs micro deployment in a CDI container, according the container adapter and the container found in the developer classpath.
The deployed content is built in a test class in the method annotated with @Deployment
CDI specification (JSR-299) mentions that the container will scan for "managed bean" only _bean archives_, and those archives must contain a META-INF/bean.xml file
{quote} 12.1. Bean archives
Bean classes of enabled beans must be deployed in bean archives.
• A library jar, EJB jar, application client jar or rar archive is a bean archive if it has a file named beans.xml in the
META-INF directory.
(...)
The container searches for beans in all bean archives in the application classpath
{quote}
However, as illustrated in the test class below, without adding any descriptor, the content of the archive is scanned and beans are managed.
The injection below is successful whereas it is expected the test throws an "UnsatisfiedResolutionException."
Test case below:
{code}
@RunWith(Arquillian.class)
public class BeanXmlArquillianTest {
//~ ----------------------------------------------------------------------------------------------------------------
//~ Instance fields
//~ ----------------------------------------------------------------------------------------------------------------
@Inject
private Bean1 testBean;
//~ ----------------------------------------------------------------------------------------------------------------
//~ Methods
//~ ----------------------------------------------------------------------------------------------------------------
@Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class);
//.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");//sounds useless
}
@Test
public void testBeanInjected() {
assertNotNull(testBean);
}
}
{code}
And bean:
{code}
package org.jboss.arquillian.junit;
public class Bean1{
}
{code}
The pom is attached.
was (Author: kdefombelle):
Similar issue observed with Arquillian 1.0.3.Final / arquillian-weld-se-embedded-1.1 1.0.0.CR5 / weld-core 1.1.10.Final / Shrinkwrap 2.0.0-alpha-1
Arquillian performs micro deployment in a CDI container, according the container adapter and the container found in the developer classpath.
The deployed content is built in a test class in the method annotated with @Deployment
CDI specification (JSR-299) mentions that the container will scan for "managed bean" only _bean archives_, and those archives must contain a META-INF/bean.xml file
{quote} 12.1. Bean archives
Bean classes of enabled beans must be deployed in bean archives.
• A library jar, EJB jar, application client jar or rar archive is a bean archive if it has a file named beans.xml in the
META-INF directory.
(...)
The container searches for beans in all bean archives in the application classpath
{quote}
However, as illustrated in the test class below, without adding any descriptor, the content of the archive is scanned and beans are managed.
The injection below is successful whereas it is expected the test throws an "UnsatisfiedResolutionException."
Test case below:
{code}
@RunWith(Arquillian.class)
public class ArquillianBeanXmlTest {
@Inject
private TestBean testBean;
@Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap.create(JavaArchive.class)
.addClass(TestBean.class);
//.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");//sounds useless
}
//test is successful whereas it is expected to fail
@Test
public void testBeanInjected() {
assertNotNull(testBean);
}
}
{code}
And bean:
{code}
package org.jboss.arquillian.junit;
public class TestBean {
}
{code}
The pom is attached.
> Should not scan for classes in Archive if it contains no beans.xml
> ------------------------------------------------------------------
>
> Key: ARQ-841
> URL: https://issues.jboss.org/browse/ARQ-841
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Weld Containers
> Affects Versions: weld_1.0.0.CR3
> Reporter: Aslak Knutsen
> Labels: starter
> Fix For: weld_1.1.0.next
>
> Attachments: pom.xml
>
>
> A deployment with no beans.xml should not result in Beans being registered in the Weld Container.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (ARQ-1109) WarpDispatcherServlet - set the ApplicationContext through constructor
by Jakub Narloch (JIRA)
[ https://issues.jboss.org/browse/ARQ-1109?page=com.atlassian.jira.plugin.s... ]
Jakub Narloch commented on ARQ-1109:
------------------------------------
I'm afraid that the closest we can get without droping Spring 2.5.x support is to introduce alternative aproach of capturing the execution context through custom HandlerInterceptor. It can basicly do (almost) the same as the WarpDispatcherServlet.
> WarpDispatcherServlet - set the ApplicationContext through constructor
> ----------------------------------------------------------------------
>
> Key: ARQ-1109
> URL: https://issues.jboss.org/browse/ARQ-1109
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Spring
> Affects Versions: spring_1.0.0.Beta1
> Reporter: Jakub Narloch
> Assignee: Jakub Narloch
> Fix For: spring_1.0.0.next
>
>
> WarpDispatcherServlet relies on Spring 2.5.6 which by default loads the application context from xml file. In Spring 3 there were introduced change that allows to set the context through constructor. Basicly the idea is to allow configuring the WarpDispatcherServlet with custom application context but in the same time keep it's compatibility with Spring 2.5
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months