researching in the JCVM specification while trying to decompile a capfile, the following question came to my mind:
The Descriptor Component (6.13) says:
The Descriptor Component provides sufficient information to parse and verify all
elements of the CAP file. It references, and therefore describes, elements in the
Constant Pool Component (Section 6.7, “Constant Pool Component” on page 6-14),
Class Component (Section 6.8, “Class Component” on page 6-21), Method
Component (Section 6.9, “Method Component” on page 6-35), and Static Field
Component (Section 6.10, “Static Field Component” on page 6-41). No components
in the CAP file reference the Descriptor Component.
The Component Model (6.1) says:
A complete
CAP file must contain all of the required components specified in this chapter. Three
components are optional: the Applet Component (Section 6.5, “Applet Component”
on page 6-12), Export Component (Section 6.12, “Export Component” on page 6-47),
and Debug Component (Section 6.14, “Debug Component” on page 6-57).
Yet it says in Installation (6.2):
COMPONENT_Descriptor (optional)
And I havent observed the Descriptor component in the Global Platform Load for Load commands! So the question arises what the descriptor is actually used for and why it is not neccesary for the applet to work on-card?
In contrary, JCVM spec 3.0.1 and greater don't list the descriptzor compnent as optional.
And I havent observed the Descriptor component in the Global Platform
Load for Load commands! So the question arises what the descriptor is
actually used for and why it is not neccesary for the applet to work
on-card?
The Descriptor.cap component provides the information for parsing and verification of other elements in the CAP file. So, the Descriptor.cap component is needed for byte code verification (BCV), which is done off-card and has no importance for card operations. It references and points to information for different CAP file components, but no component (mandatory ones) points to Descriptor component. So, there is no need to load this component on the card. Hence, you don't see it in Global Platform [Load] commands.
As defined in the below JCVM spec 3.0.5 specification.
The Descriptor Component provides sufficient information to parse and verify all elements of the CAP
file. It references, and therefore describes, elements in the Constant Pool Component (6.8 Constant Pool
Component), Class Component (6.9 Class Component), Method Component (6.10 Method Component),
and Static Field Component (6.11 Static Field Component). No components in the CAP file reference the
Descriptor Component.
In contrary, JCVM spec 3.0.1 and greater don't list the descriptzor
compnent as optional.
They describe Descriptor.cap as optional in the installation order of CAP file component in the following JCVM spec 3.0.5 (Section 6.3). Although not the same specification, but its hard to say why they miss to mention this in the specification you mentioned.
https://docs.oracle.com/javacard/3.0.5/JCVMS/JCVMS.pdf
Related
Regarding the <composite:interface> tag for JSF composite components, what is the use of the "expert" property of the (interface tag](https://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/cc/interface.html)?
The description is awfully vague and I found no references to its use or documentation online.
What is its purpose and usage?
I've scanned the Mojarra source code. It's ultimately set in java.beans.FeatureDescriptor class.
But it's in turn not really anywhere used.
With this I conclude that it's just unused inherited logic. The same applies to dislayName, shortDescription, hidden and preferred attributes. Only the name and componentType are actually concretely used.
The unused attributes are at most only used by tooling such as IDEs like Eclipse and Netbeans so that they can parse and show the right labels and tooltips here and there when working with (custom) composite components.
Indeed, very less has been written/shed on the component tree itself, that seems to be source for a whole lot of problems when one takes on understanding JSF.
One of the quote I recently read on a social networking site-
LIBRARY - Because not everything on the Internet is true.
Neither the above nor its opposite holds true either.
This is a screenshot from Anghel Leonard's book- Mastering Java Server Faces 2.2
I think this is plainly wrong. The author seems to be confused on whether its the component tree that gets saved OR the states of the components in the view(tree of UI components)
Considering this thread by BalusC-
When the form is submitted and the view is restored, the JSF
component tree is just rebuilt from scratch and all binding attributes
will just be re-evaluated like described in above paragraph. After the
component tree is recreated, JSF will restore the JSF view state into
the component tree.
Don't forget to read the comments.
Nonetheless, I would love to clarify the above note. Is my understanding perfectly correct?
... only if the component tree was previously saved ...
This is indeed not specific enough. How it really should read is:
... only if the non-transient state of the component tree was previously saved ...
In a JSF page, I use EL to locate an image which placed in /resource/images/ folder.
<h:graphicImage value="#{resource['images:logo.gif']}"
How can EL locate the image?
Maybe a specification defines the rule, but I don't know which specification.
I try to find it in the JSR-000344 JavaServer Faces 2.2 ，the JSR-000342 Java Platform, Enterprise Edition 7, the JSR-000341 Expression Language 3.0, but not found.
In the JSF 2.0 specification, it's first mentioned in chapter 2.6.2:
2.6.2 Rendering Resources
Resources such as images, stylesheets and scripts use the resource handling mechanism as outlined in Section 2.6.1
“Packaging Resources”. So, for example:
<h:graphicImage name=”Planets.gif” library=”images”/>
<h:graphicImage value=”#{resource[‘images:Planets.gif’]}”/>
These entries render exactly the same markup. In addition to using the name and library attributes, stylesheet and
script resources can be “relocated” to other parts of the view. For example, we could specify that a script resource be
rendered within an HTML “head”, “body” or “form” element in the page.
and then in chapter 5.6.2.5:
5.6.2.5 Resource ELResolver
This resolver is a means by which Resource instances are encoded into a faces request such that a subsequent faces
resource request from the browser can be satisfied using the ResourceHandler as described in Section 2.6 “Resource
Handling”.
ELResolver method implementation requirements
If base and property are not null, and base is an
instance of ResourceHandler (as will be the case
with an expression such as #{resource[‘ajax.js’]},
perform the following. (Note: This is possible due
to the ImplicitObjectELResolver returning the
ResourceHandler, see Section 5.6.2.1 “Implicit
Object ELResolver for Facelets and Programmatic
Access”)
If property does not contain a colon
character ‘:’, treat property as the
resourceName and pass property to
ResourceHandler.createResource(resourceName).
If property contains a single colon
character ‘:’, treat the content before the ‘:’ as
the libraryName and the content after the ‘:’
as the resourceName and pass both to
ResourceHandler.createResource(resourceName, libraryName)
If property contains more than one colon
character ‘:’, throw a localized
ELException, including property.
If one of the above steps results in the creation
of a non-null Resource instance, call
ELContext.setPropertyResolved(true) and return the
result of calling the getRequestPath() method on
the Resource instance.
It's also mentioned in same chapters in JSF 2.1 and 2.2 specification.
Unrelated to the concrete problem, images is a really bad example of a resource library name. Don't take over that from the spec example.
See also:
How to reference CSS / JS / image resource in Facelets template?
What is the JSF resource library for and how should it be used?
Short Version:
If two JSF library jar files both include a custom renderer for the same family and type, is there any way from within the library itself (i.e. not from the containing app) of specifying which one should be used? Something like assigning a priority, with higher ones used in preference to lower ones?
Longer Version:
I'm using Primefaces in a project and trying to override the provided head renderer with my own:
<render-kit>
<renderer>
<component-family>javax.faces.Output</component-family>
<renderer-type>javax.faces.Head</renderer-type>
<renderer-class>com.example.MyHeadRenderer</renderer-class>
</renderer>
</render-kit>
If I put that into the WEB-INF/faces-config.xml of the war file then it's all good, and my renderer gets used.
However, if I try to deploy my code as part of a library jar (my-utils.jar), with the renderer defined in META-INF/faces-config.xml, then the Primefaces one is used. This contains exactly the same definition, so I'm guessing it just depends on the order they get loaded. Indeed, renaming my library to "xx-comps.jar" works, so it would appear that JSF is loading faces-config.xml files from all jar files in alphabetical order, with later entries just overwriting earlier ones.
Is there any way of forcing the selection to my library?
So far, I have these options:
Put my renderer directly into the WEB-INF/faces-config.xml of the war.
Build a custom Primefaces jar with that one renderer definition
removed.
Rename my library and rely on some (undocumented as far as I can
see) behaviour from the JSF loader.
Add a custom renderkit which extends the standard one, and reference
that from my war WEB-INF/faces-config.xml.
The first three all work but are not ideal, as (1) and (2) require changes outside my library, and (3) just looks dodgy as hell....
The fourth is just an idea as I've never written a render kit before so not aware of the effort involved. No idea if it is practical or would work, but it is better than (1) because at least the application only references a single render kit, and does not need to be updated if/when new renderers are added. Happy to put more effort into researching this approach if it seems a reasonable solution.
Also, I'd ideally prefer to use annotations rather than XML:
#FacesRenderer(componentFamily = "javax.faces.Output", rendererType = "javax.faces.Head")
public class MyHeadRenderer extends Renderer {
...
}
Thanks
You can specify the ordering via <ordering> in faces-config.xml of the JAR.
E.g. if you want your utility library to be loaded after all others, then just do so:
<ordering>
<after>
<others />
</after>
</ordering>
If you want to force an explicit ordering, then hook on specifically PrimeFaces, which has a <name>primefaces</name> in its faces-config.xml:
<ordering>
<after>
<name>primefaces</name>
</after>
</ordering>
I' working on a library control for Xpages and need some help in creating.
I would create a control which reads a configuration file and creates controls in a table, controls like Editboxes, checkboxgroups and so on.
so and now to my questions:
could I initiate controls from the Exlib or must I implement them all by my self?
if I could use them from the Exlib could anyone explain me how?
I hope its clear what i mean if not please ask me for further informations.
When creating your own components, if you're closely replicating some behavior that is already in an extension library component, I highly recommend you extend that component and just add what's needed to accommodate your different functionality. This makes things much easier and you don't have to code around every little scenario that the component might be placed in.
But, if you are developing a component that is nothing like any of the extension library or core components then just ensure your component extends UIComponent or UIComponentBase. If going this route, you'll also need to create your own renderer which extends Renderer. This is what will build the on-screen representation of your component. Again, if there's already something in the core components or extension library components that closely mimics what you need then make your renderer extend that renderer. Also, don't forget to include the renderer definition in the faces-config file and the component definition in the xsp-config file or your component won't work.
As for initiating controls from the extlib.... I assume you mean can you inject them onto the page at runtime. If so the answer is absolutely yes. To add an input text field to the page where there is a container (i.e. panel, div, span, whatever) with an ID of "someContainer"
XspInputText input = new XspInputText();
input.setValue("someValue");
input.setId("someID");
UIComponent container = FacesContext.getCurrentInstance().getViewRoot().findComponent("someContainer");
container.getChildren().add(input);
To see the api for all of the core and extension library components take a look at the XPages Controls Documentation. For a more complete tutorial on creating your own components take a look at my blog for creating a custom component inside an nsf, the steps are pretty much the same for putting them into a library:
Part 1,
Part 2 and there is an example database in the Part 2 post.