[JBoss JIRA] Created: (WELD-718) register Weld Servlet listener in web fragment
by Dan Allen (JIRA)
register Weld Servlet listener in web fragment
----------------------------------------------
Key: WELD-718
URL: https://jira.jboss.org/browse/WELD-718
Project: Weld
Issue Type: Feature Request
Components: Servlet Container Support
Affects Versions: 1.1.0.Beta1
Reporter: Dan Allen
Priority: Minor
Instead of making the developer add the Weld Servle listener in their web.xml when using weld-servlet, might we consider registering it for them automatically but including it in a web.xml fragment or TLD that's bundled in weld-servlet.jar? The benefit of using the TLD is that it would work in pre-Servlet 3.0 environments.
META-INF/web-fragment.xml
<web-fragment xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd"
version="3.0">
<listener>
<listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
</listener>
</web-fragment>
META-INF/weld.tld
<taglib xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_0.xsd"
version="2.0">
<description>
An empty tag library that registers a listener to bootstrap Weld in a Servlet container.
</description>
<tlib-version>1.0</tlib-version>
<short-name>w</short-name>
<uri>http://jboss.org/weld</uri>
<!--
This ServletContextListener initializes the runtime environment of the CDI
Reference Implementation (Weld) when a web application including it is
initialized by the container.
-->
<listener>
<listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
</listener>
</taglib>
Btw, we are already including other automatic configurations, such as a JSF phase listener and view handler (META-INF/faces-config.xml).
If we require ordering, that leans more to web-fragment.xml as a solution, since it's possible to have ordering control. There is no guarantee as to when a listener will load that's defined in a TLD (the advantage is only for non-Servlet 3.0 containers). Given that Weld is a new programming model and likely to be used with newer containers, then I'd say we should go with web-fragment.xml.
(Worse case scenario is we introduce a classifier for weld-servlet that will be for pre-Servlet 3.0 environments. Something like org.jboss.weld.servlet:weld-servlet:1.1:pre-servlet-3)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] Created: (WELD-793) Make bootstrap more granular
by Pete Muir (JIRA)
Make bootstrap more granular
----------------------------
Key: WELD-793
URL: https://issues.jboss.org/browse/WELD-793
Project: Weld
Issue Type: Feature Request
Affects Versions: 1.1.0.CR1
Reporter: Pete Muir
Priority: Blocker
Fix For: 1.2.0.Beta1
Currently the bootstrap is fairly coarse grained, not allowing the container to "skip" parts of bootstrap if it can provide the information externally.
The primary goal here is to allow the container to skip the the bootstrap up until after all ProcessAnnotatedType events have been sent, and the modified class metadata has been built. My proposal for this is to introduce a new method to bootstrap that passes in a map of BDA->AnnotatedType that Weld can use to boot.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (WELD-1095) Document unsafe instantiators
by Jozef Hartinger (JIRA)
Jozef Hartinger created WELD-1095:
-------------------------------------
Summary: Document unsafe instantiators
Key: WELD-1095
URL: https://issues.jboss.org/browse/WELD-1095
Project: Weld
Issue Type: Feature Request
Components: Reflection layer
Affects Versions: 1.1.6.Final
Reporter: Jozef Hartinger
Assignee: Ales Justin
Priority: Minor
Fix For: 1.2.0.Beta1
WELD-56 has been resolved a while ago however the docs still say:
{quote}
A future release of Weld will likely support a non-standard workaround for this limitation, using non-portable JVM APIs:
Sun, IcedTea, Mac: Unsafe.allocateInstance() (The most efficient)
IBM, JRockit: ReflectionFactory.newConstructorForSerialization()
But we didn't get around to implementing this yet.
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (WELD-1113) Specializing beans in different bean archives is still broken
by Mark Struberg (JIRA)
Mark Struberg created WELD-1113:
-----------------------------------
Summary: Specializing beans in different bean archives is still broken
Key: WELD-1113
URL: https://issues.jboss.org/browse/WELD-1113
Project: Weld
Issue Type: Bug
Reporter: Mark Struberg
This is a follow up on WELD-912.
It appears that this is still broken!
I tried it first on glassfish-3.1.1. with an upgraded weld-osgi-bundle.1.1.7.Final.
I get the following error reported:
remote failure: Error occurred during deployment: Exception while loading the app : WELD-000047 Specializing bean must extend another bean: Managed Bean [class at.ac.tuwien.tiss.core.fe.codi.TissCodiWindowContextConfig] with qualifiers [@Any @Default]. Please see server.log for more details.
But my class extends the parent class:
public class TissCodiWindowContextConfig extends WindowContextConfig { ..
The TissCodiWindowContextConfig is in my project jar, the parent class in codi-jsf.jar, both in my WEB-INF/lib folders of my webapp.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years