[
https://issues.jboss.org/browse/JBIDE-3120?page=com.atlassian.jira.plugin...
]
Viacheslav Kabanovich commented on JBIDE-3120:
----------------------------------------------
1) In JBoss Tools each CDI extension will be represented by an implementation of interface
ICDIExtension defined in Core plugin (org.jboss.tools.cdi.core).
2) Implementations will be registered in Eclipse extension point
org.jboss.tools.cdi.core.cdiextension defined in Core plugin. Each CDI extension may/will
be implemented as a separate Eclipse feature that may be included or not into product.
Eclipse extension point binds implementation class in JBoss Tools with id, equal to class
name of CDI runtime implementation of CDI extension.
3) One instance of each ICDIExtension implementation is created for a CDI project at build
time and stored in CDIProject object until next build.
Build of CDI project starts with CDIExtensionScanner, that looks into class path for
libraries that contain CDI extension implementations, and builds ICDIExtension instances
for them.
4) ICDIExtension provides features that may be requested at various stages of detecting,
building and using of CDI objects. That is convenient to be implemented as
'ICDIExtension extends IAdaptable' so that each feature may be represented by a
separate interface. To avoid iterating all registered CDI extensions for each feature, it
will be convenient to register in Eclipse extensions all relevant feature ids for CDI
extension.
5) The list of features to be provided by ICDIExtension is yet to be elaborated; and maybe
we will have to modify it while implementing new CDI extensions, but basically it may
contain
- detector of relevant resources;
- scanner of resources;
- processor that applies inner model ('definitions') to CDI model built by core;
here some most common and simple cases can be singled out into separate features to avoid
scanning the entire CDI model, (for example, extension may prevent bean from being added
to the model, that can be decided at the moment when core builder is about to add it to
model by requesting for true/false with context), simple features invoked at exact place
provide better performance than applying each extension to the entire model;
- computing of properties that remain undefined by builder for the sake of performance,
and are defined at request.
Support seam/weld typesafe xml schema
--------------------------------------
Key: JBIDE-3120
URL:
https://issues.jboss.org/browse/JBIDE-3120
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: cdi (jsr-299)
Reporter: Max Rydahl Andersen
Assignee: Viacheslav Kabanovich
Labels: new_and_noteworthy
Fix For: 3.3.x
http://docs.jboss.org/webbeans/reference/1.0/en-US/html/xml.html
"The advantage of this approach is that you can write an XML schema
that prevents spelling errors in your XML document. It's even possible
for a tool to generate the XML schema automatically from the compiled
Java code. Or, an integrated development environment could perform the
same validation without the need for the explicit intermediate
generation step."
1) the RI will have a code->xsd generator for web-beans.xml; could maybe be used for
validation....but requires that all classes can compile
2) we should have xml completions following the naming standard layed out by webbeans
spec
Update: webbeans.xml is no longer part of the spec but it will be important for
extensions to jsr-299 to somehow tell the tooling which annotations/beans they will be
adding into the jsr-299 runtime. Seam 3 will most likely use this suggestion for the spec.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira