[JBoss JIRA] Created: (SEAMMAIL-17) Test cases fails and errors
by Marek Smigielski (JIRA)
Test cases fails and errors
---------------------------
Key: SEAMMAIL-17
URL: https://issues.jboss.org/browse/SEAMMAIL-17
Project: Seam Mail
Issue Type: Bug
Reporter: Marek Smigielski
1.testTextMailMessage
junit.framework.AssertionFailedError: Didn't receive the expected amount of messages. Expected 1 got 0
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at org.jboss.seam.mail.MailMessageTest.testTextMailMessage(MailMessageTest.java:131)
2. template.html.vm resource not mapped correctly
3. testVelocityTextMailMessage
junit.framework.AssertionFailedError: Didn't receive the expected amount of messages. Expected 1 got 0
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at org.jboss.seam.mail.VelocityMailMessageTest.testVelocityTextMailMessage(VelocityMailMessageTest.java:133)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (SEAMCONFIG-49) Support fields of the class Properties: replacing and modifying (regression from seam 2)
by Geoffrey De Smet (JIRA)
Support fields of the class Properties: replacing and modifying (regression from seam 2)
----------------------------------------------------------------------------------------
Key: SEAMCONFIG-49
URL: https://issues.jboss.org/browse/SEAMCONFIG-49
Project: Seam Config
Issue Type: Feature Request
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
In seam 2 you could do something like this:
{code}
<component name="repositoryConfiguration">
<property name="setupProperties">
<key>org.drools.repository.configurator</key><value>org.drools.repository.jackrabbit.JackrabbitRepositoryConfigurator</value>
<!-- the root directory for the repo storage the directory must exist. -->
<!-- <key>repository.root.directory</key><value>/opt/yourpath</value> -->
</property>
</component>
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (SEAM-94) Shaded jars like seam-solder instead of seam-solder-api and seam-solder-impl result in the same classes twice in the classpath (possibly different versions)
by Geoffrey De Smet (JIRA)
Shaded jars like seam-solder instead of seam-solder-api and seam-solder-impl result in the same classes twice in the classpath (possibly different versions)
------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: SEAM-94
URL: https://issues.jboss.org/browse/SEAM-94
Project: Seam 3 Distribution
Issue Type: Bug
Reporter: Geoffrey De Smet
Shaded jars (like seam-solder) are highly problematic in itself, see WELD-935.
Trying to avoid the shaded jars, is impossible, as this example shows:
{code}
$ mvn dependency:tree
...
[INFO] +- org.jboss.seam.solder:seam-solder-api:jar:3.0.0.Final:compile ===========> my compile dependency on solder-api (the non-shaded jar)
[INFO] +- org.jboss.seam.solder:seam-solder-impl:jar:3.0.0.Final:runtime ==========> my runtime dependency on solder-impl (the non-shaded jar)
[INFO] +- org.jboss.seam.security:seam-security-api:jar:3.0.0.Final:compile
...
[INFO] +- org.jboss.seam.security:seam-security-impl:jar:3.0.0.Final:compile
[INFO] | +- org.jboss.seam.solder:seam-solder:jar:3.0.0.Final:compile ============> transitive dependency on solder (the shaded jar) which shades the classes of solder-api
{code}
Now suppose I depend on solder-api 3.0..Final instead (still with seam-security-impl 3.0.0.Final): I 'd have 2 different versions of solder in my classpath.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (SEAMSERVLET-42) Seam Servlet broken in multi-war ear deployment
by Jozef Hartinger (JIRA)
Seam Servlet broken in multi-war ear deployment
-----------------------------------------------
Key: SEAMSERVLET-42
URL: https://issues.jboss.org/browse/SEAMSERVLET-42
Project: Seam Servlet
Issue Type: Bug
Affects Versions: 3.0.0.Final
Reporter: Jozef Hartinger
Fix For: 3.0.1.Beta1
The Servlet specification requires a java library to be bundled within the WEB-INF/lib folder for its web-fragment.xml to be read. Therefore, if multiple web applications using Seam Servlet are bundled within an EAR, they all have to package Seam Servlet within their WEB-INF/lib folders.
The CDI specification is not clear in defining the application scope in an EAR (See https://issues.jboss.org/browse/CDI-129 for details.)
JBoss AS 7 implements the application scope as per-ear.
This results in conflicts between multiple instances of Seam Servlet. Therefore, when the ear is deployed, the deployment fails with AmbiguousResolutionException like the following one:
15:14:42,467 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.unit."test.ear".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.ear".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [HttpServletRequest] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.servlet.http.CookieParamProducer.request]. Possible dependencies [[Producer Method [HttpServletRequest] with qualifiers [@Any @Default] declared as [[method] @Produces @Typed @RequestScoped protected org.jboss.seam.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()], Producer Method [HttpServletRequest] with qualifiers [@Any @Default] declared as [[method] @Produces @Typed @RequestScoped protected org.jboss.seam.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()]]]
at org.jboss.as.weld.services.WeldService.start(WeldService.java:96)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [HttpServletRequest] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.servlet.http.CookieParamProducer.request]. Possible dependencies [[Producer Method [HttpServletRequest] with qualifiers [@Any @Default] declared as [[method] @Produces @Typed @RequestScoped protected org.jboss.seam.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()], Producer Method [HttpServletRequest] with qualifiers [@Any @Default] declared as [[method] @Produces @Typed @RequestScoped protected org.jboss.seam.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()]]]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:274)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:129)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:351)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:336)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:404)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)
... 5 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months