[JBoss JIRA] Created: (WELD-919) Conversation propagation token that negates the "cid" parameter
by Nicklas Karlsson (JIRA)
Conversation propagation token that negates the "cid" parameter
---------------------------------------------------------------
Key: WELD-919
URL: https://issues.jboss.org/browse/WELD-919
Project: Weld
Issue Type: Feature Request
Components: Conversations
Affects Versions: 1.1.1.Final
Reporter: Nicklas Karlsson
A method that negates the propagation of the cid parameter by the ConversationAwareViewHandler so that a non-transient is not resumed even if there is a cid parameter in the request. Stripping it out on a per-component-basis is tricky.
Suggested implementation: change the last line in WeldPhaseListener.getConversationId to
return facesContext.getExternalContext().getRequestParameterMap().containsKey("nocid") ? null : cid;
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Updated: (WELD-912) Specializing beans in different bean archives does not work
by Ales Justin (JIRA)
[ https://issues.jboss.org/browse/WELD-912?page=com.atlassian.jira.plugin.s... ]
Ales Justin updated WELD-912:
-----------------------------
Fix Version/s: 1.2.0.Beta1
(was: 1.1.2.Final)
A more complex fix needs to be done to bootstrap order.
> Specializing beans in different bean archives does not work
> -----------------------------------------------------------
>
> Key: WELD-912
> URL: https://issues.jboss.org/browse/WELD-912
> Project: Weld
> Issue Type: Bug
> Components: Bootstrap and Metamodel API
> Affects Versions: 1.1.1.Final
> Reporter: Nicklas Karlsson
> Fix For: 1.2.0.Beta1
>
> Attachments: test.zip
>
>
> @Specializing a bean that is deployed in a different bean archive fails with the following exception:
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000047 Specializing bean must extend another bean: Managed Bean [class fi.affecto.test.MyApplicationBundles] with qualifiers [@Any @Default]
> at org.jboss.weld.bean.ManagedBean.specialize(ManagedBean.java:545)
> at org.jboss.weld.bean.AbstractBean.initialize(AbstractBean.java:124)
> at org.jboss.weld.bean.AbstractClassBean.initialize(AbstractClassBean.java:202)
> at org.jboss.weld.bean.ManagedBean.initialize(ManagedBean.java:372)
> at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:113)
> at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:216)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370)
> at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)
> at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)
> ... 4 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (WELD-524) org.jboss.weld.environment.se.discovery.URLScanner does not work with resources inside OSGI bundles
by Morten Christensen (JIRA)
org.jboss.weld.environment.se.discovery.URLScanner does not work with resources inside OSGI bundles
----------------------------------------------------------------------------------------------------
Key: WELD-524
URL: https://jira.jboss.org/jira/browse/WELD-524
Project: Weld
Issue Type: Bug
Environment: JavaSE 6 + Weld SE
Reporter: Morten Christensen
Priority: Blocker
The class org.jboss.weld.environment.se.discovery.URLScanner does no work with resources inside OSGI bundles. So if one try to start WeldSe inside an OSGI bundle and get around the classloader bug in WeldSE by tempoarily setting the ContextClassLoader you will get an NullPointerException.
The problem is OSGI resource url related. For a OSGI bundle you will f.x. get "bundleresource://4.fwk1362875764:1/META-INF/beans.xml" from bundleClassLoader.getResources("META-INF/beans.xml" but this is not a valid filename as URLScanner assumes so one will get this exception:
java.lang.NullPointerException
at org.jboss.weld.environment.se.discovery.URLScanner.handleDirectory(URLScanner.java:177)
at org.jboss.weld.environment.se.discovery.URLScanner.handleDirectory(URLScanner.java:183)
at org.jboss.weld.environment.se.discovery.URLScanner.handleDirectory(URLScanner.java:160)
at org.jboss.weld.environment.se.discovery.URLScanner.handle(URLScanner.java:122)
at org.jboss.weld.environment.se.discovery.URLScanner.scanResources(URLScanner.java:107)
at org.jboss.weld.environment.se.discovery.SEWeldDiscovery.scan(SEWeldDiscovery.java:71)
at org.jboss.weld.environment.se.discovery.SEWeldDiscovery.<init>(SEWeldDiscovery.java:45)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] Created: (WELD-376) Callouts poorly formatted in HTML docs
by Pete Muir (JIRA)
Callouts poorly formatted in HTML docs
--------------------------------------
Key: WELD-376
URL: https://jira.jboss.org/jira/browse/WELD-376
Project: Weld
Issue Type: Task
Components: Documentation
Affects Versions: 1.0.0.GA
Reporter: Jozef Hartinger
Fix For: 1.0.1.CR1
Global problems
- a significant number of links is missing the value of href attribute (these links point nowhere)
- JBoss AS 5.2.x have become obsolete recently (changed to 6.0.0.M1) - the documentation references this obsolete version. i.e. Chapters 6, section 18.1
- there is a number of unnecessary blank pages in the PDF version
- Section 2.1.2. Scope - there is a missing *want* in the Note in the sentence: "If you don't the bean to live in the session indefinitely..."
- Section 6.2 Deploying to JBoss AS - there is a missing space in the sentence "Create a new file namedlocal.build.properties ..."
- Section 6.2 Deploying to JBoss AS - is not finished - there is a TODO at the very end of the section
- Secion 7.1. The numberguess example in depth - the numbers which mark an important line of a code sample (1), (2), etc... are broken in the second sample of the section (web.xml). They are placed on wrong places (wrong line, beggining of the line instead of end) and they are followed by "ml_plain">" in the HTML version.
Besides, I would emphasize more the benefit of the typesafe resolution i.e. in section 1.2 - (that all the unsatisfied and ambiguous dependencies are discovered at the deployment time - you do not need to click anything to find out that the you set some dependencies wrong - more formal verification) - I don't say it is not there already. I just had a feeling that it is not stated explicitly enough.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months