http://svgonugu.wordpress.com/2011/01/23/oracle-service-bus-11g-osb-installation/
For OSB 11.1.1.6.0 (64 bits), install OEPE 11.1.1.8 (Eclipse 3.7 Indigo).
Thursday, 29 November 2012
Wednesday, 15 August 2012
Monday, 25 June 2012
Spring Javamail Debug
<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
<property name="host" value="..." />
<property name="port" value="25" />
<property name="username" value="..." />
<property name="password" value="..." />
<property name="javaMailProperties">
<props>
<prop key="mail.debug">true</prop>
</props>
</property>
</bean>
<property name="host" value="..." />
<property name="port" value="25" />
<property name="username" value="..." />
<property name="password" value="..." />
<property name="javaMailProperties">
<props>
<prop key="mail.debug">true</prop>
</props>
</property>
</bean>
Labels:
Spring
Tuesday, 3 April 2012
Wednesday, 28 March 2012
JSF f:event
Must be a ComponentSystemEvent or:
- postAddToView
- preValidate/postValidate
- preRenderView/preRenderComponent
Labels:
JSF
Oracle DB Console and New Hostname
- emca -deconfig dbcontrol db -repos drop
- emca -config dbcontrol db -repos create
Labels:
Database
Friday, 23 March 2012
IE8 Flashing CSS background-image
<meta http-equiv="Page-Enter" content="blendTrans(Duration=.01)" />
<meta http-equiv="Page-Exit" content="blendTrans(Duration=.01)" />
<meta http-equiv="Page-Exit" content="blendTrans(Duration=.01)" />
Labels:
html
Thursday, 15 March 2012
SelectManyCheckbox with POJOs
<h:selectManyCheckbox id="roles" layout="pageDirection" label="Roles"
value="#{userEdit.user.roles}" converter="#{roleConverter}" collectionType="java.util.ArrayList">
<f:selectItems value="#{userEdit.allRoles}" var="rol" itemLabel="#{rol.name}" itemValue="#{rol}" />
</h:selectManyCheckbox></h:selectManyCheckbox>
value="#{userEdit.user.roles}" converter="#{roleConverter}" collectionType="java.util.ArrayList">
<f:selectItems value="#{userEdit.allRoles}" var="rol" itemLabel="#{rol.name}" itemValue="#{rol}" />
</h:selectManyCheckbox></h:selectManyCheckbox>
Labels:
JSF
Monday, 12 March 2012
Loading CSS with background image
- in CSS: url(background.jpg)
- in JBoss Tools HTML Editor: Page Design Options > Include css files
- in JSP: ${pageContext.servletContext.contextPath}/resources/css/style.css
- in JSF: #{request.contextPath}/resources/css/style.css (cannot use #{resource['css:style.css']})
Labels:
html
Friday, 9 March 2012
Wednesday, 7 March 2012
CSS Center with "auto"
- margin-left: auto; margin-right:auto
- margin: 10px auto (1)
- margin: 10px auto 10px (2)
- margin: 10px auto 10px auto (3)
(1) top/bottom + right/left
(2) top + right/left + bottom
(3) top + right + bottom + left
Labels:
html
Friday, 2 March 2012
Tuesday, 28 February 2012
Clean CSS Layout without HTML Table
body {
padding: 0px;
margin: 0px;
}
#header {
position: absolute;
top: 10px;
left: 10px;
right: 10px;
height: 100px;
overflow: hidden;
background-color: yellow;
}
#side {
position: absolute;
top: 120px;
left: 10px;
bottom: 10px;
width: 130px;
background-color: orange;
}
#main {
position: absolute;
top: 120px;
left: 150px;
bottom: 10px;
right: 10px;
background-color: lightgrey;
}
padding: 0px;
margin: 0px;
}
#header {
position: absolute;
top: 10px;
left: 10px;
right: 10px;
height: 100px;
overflow: hidden;
background-color: yellow;
}
#side {
position: absolute;
top: 120px;
left: 10px;
bottom: 10px;
width: 130px;
background-color: orange;
}
#main {
position: absolute;
top: 120px;
left: 150px;
bottom: 10px;
right: 10px;
background-color: lightgrey;
}
Labels:
html
Friday, 24 February 2012
Unified EL
Unified EL 2.2 is part of JSR-245 MR2 (JSP 2.2) and therefore not included in Tomcat 6 nor Jetty 6.
EL 2.2 is part of Tomcat 7 and Jetty 7, but with a few manual steps, you can use EL 2.2 even in current containers.
EL 2.2 is part of Tomcat 7 and Jetty 7, but with a few manual steps, you can use EL 2.2 even in current containers.
Tuesday, 21 February 2012
Eclipse Plug-Ins
- Subclipse
- M2E Maven (including Maven Integration for WTP: m2e-wtp)
- JBoss Tools Richfaces
- PDT (PHP Development Tools)
Labels:
Java
Wednesday, 15 February 2012
Friday, 10 February 2012
Friday, 3 February 2012
Flex & Spring
ChannelSets must be defined explicitly, e.g.:
// Init channel sets using values from service-config.xml
remotingChannelSet = new ChannelSet();
remotingChannelSet.addChannel(ServerConfig.getChannel("my-amf"));
pollingChannelSet = new ChannelSet();
pollingChannelSet.addChannel(ServerConfig.getChannel("my-polling-amf"));
// Init channel sets using values from service-config.xml
remotingChannelSet = new ChannelSet();
remotingChannelSet.addChannel(ServerConfig.getChannel("my-amf"));
pollingChannelSet = new ChannelSet();
pollingChannelSet.addChannel(ServerConfig.getChannel("my-polling-amf"));
Thursday, 26 January 2012
Web Application State Storage
- IDs (hidden fields, URL ...)
- Servlet session (one client)
- JSF Tomahawk saveState
Labels:
JSF
Wednesday, 18 January 2012
Hibernate & Web Applications Issues
- LazyInitializationException I: OpenSessionInView
- LazyInitializationException II (next request, HttpSession/saveState detached object)
- work with IDs (stateless, no session)
- lock(LockMode.NONE)
- programmatically initialize
- FetchType.EAGER
- NonUniqueObjectException (next request, on lock): change statement order
- StaleObjectException: optmistic locking using @Version
- HibernateException: Illegal attempt to associate a collection with two open sessions
- HttpSession object synchronization Filter
Labels:
Hibernate
Monday, 16 January 2012
Certificates
In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic document which uses a digital signature to bind a public key with an identity - information such as the name of a person or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to an individual. In a typical public key infrastructure (PKI) scheme (e.g. X.509) the signature will be of a certificate authority (CA). In a web of trust scheme (e.g. PGP), the signature is of either the user (a self-signed certificate) or other users ("endorsements"). In either case, the signatures on a certificate are attestations by the certificate signer that the identity information and the public key belong together. A self-signed certificate is a certificate where the signer/issuer and subject are the same.
X.509 v3 certificate example (http://tools.ietf.org/html/rfc5280):
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA [...] CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US [...] OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
Signature Value:
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
Where:
VeriSign uses the concept of classes for different types of digital certificates:
In cryptography, PKCS refers to a group of public-key cryptography standards devised and published by RSA Security.
In public key infrastructure systems, a certificate signing request (also CSR or certification request) is a message sent from an applicant to a certificate authority in order to apply for a digital identity certificate. The most common format for CSRs is the PKCS#10 specification and another is the Signed Public Key and Challenge Spkac format generated by some web browsers. The CSR contains information identifying the applicant (such as a distinguished name in the case of an X.509 certificate), and the public key chosen by the applicant. The PKCS#10 standard defines a binary format for encoding CSRs for use with X.509. It is expressed in ASN.1. A CSR may be represented as a Base64 encoded PKCS#10, e.g.:
-----BEGIN CERTIFICATE REQUEST-----
MIIBnTCCAQYCAQAwXTELMAkGA1UEBhMCU0cxETAPBgNVBAoTCE0yQ3J5cHRvMRIw
EAYDVQQDEwlsb2NhbGhvc3QxJzAlBgkqhkiG9w0BCQEWGGFkbWluQHNlcnZlci5l
eGFtcGxlLmRvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr1nYY1Qrll1r
uB/FqlCRrr5nvupdIN+3wF7q915tvEQoc74bnu6b8IbbGRMhzdzmvQ4SzFfVEAuM
MuTHeybPq5th7YDrTNizKKxOBnqE2KYuX9X22A1Kh49soJJFg6kPb9MUgiZBiMlv
tb7K3CHfgw5WagWnLl8Lb+ccvKZZl+8CAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GB
AHpoRp5YS55CZpy+wdigQEwjL/wSluvo+WjtpvP0YoBMJu4VMKeZi405R7o8oEwi
PdlrrliKNknFmHKIaCKTLRcU59ScA6ADEIWUzqmUzP5Cs6jrSRo3NKfg1bd09D1K
9rsQkRc9Urv9mRBIsredGnYECNeRaK5R1yzpOowninXC
-----END CERTIFICATE REQUEST-----
Signature algorithms:
The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP.
Certificate file formats:
X.509 v3 certificate example (http://tools.ietf.org/html/rfc5280):
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA [...] CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US [...] OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
Signature Value:
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
68:9f
Where:
- Version valid values are 1, 2 or 3
- Serial Number is a unique number for each certificate issued by a specific CA
- Issuer and Subject are non-empty distinguished names (DN)
VeriSign uses the concept of classes for different types of digital certificates:
- Class 1 for individuals, intended for email
- Class 2 for organizations, for which proof of identity is required
- Class 3 for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority
- Class 4 for online business transactions between companies
- Class 5 for private organizations or governmental security
In cryptography, PKCS refers to a group of public-key cryptography standards devised and published by RSA Security.
In public key infrastructure systems, a certificate signing request (also CSR or certification request) is a message sent from an applicant to a certificate authority in order to apply for a digital identity certificate. The most common format for CSRs is the PKCS#10 specification and another is the Signed Public Key and Challenge Spkac format generated by some web browsers. The CSR contains information identifying the applicant (such as a distinguished name in the case of an X.509 certificate), and the public key chosen by the applicant. The PKCS#10 standard defines a binary format for encoding CSRs for use with X.509. It is expressed in ASN.1. A CSR may be represented as a Base64 encoded PKCS#10, e.g.:
-----BEGIN CERTIFICATE REQUEST-----
MIIBnTCCAQYCAQAwXTELMAkGA1UEBhMCU0cxETAPBgNVBAoTCE0yQ3J5cHRvMRIw
EAYDVQQDEwlsb2NhbGhvc3QxJzAlBgkqhkiG9w0BCQEWGGFkbWluQHNlcnZlci5l
eGFtcGxlLmRvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr1nYY1Qrll1r
uB/FqlCRrr5nvupdIN+3wF7q915tvEQoc74bnu6b8IbbGRMhzdzmvQ4SzFfVEAuM
MuTHeybPq5th7YDrTNizKKxOBnqE2KYuX9X22A1Kh49soJJFg6kPb9MUgiZBiMlv
tb7K3CHfgw5WagWnLl8Lb+ccvKZZl+8CAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GB
AHpoRp5YS55CZpy+wdigQEwjL/wSluvo+WjtpvP0YoBMJu4VMKeZi405R7o8oEwi
PdlrrliKNknFmHKIaCKTLRcU59ScA6ADEIWUzqmUzP5Cs6jrSRo3NKfg1bd09D1K
9rsQkRc9Urv9mRBIsredGnYECNeRaK5R1yzpOowninXC
-----END CERTIFICATE REQUEST-----
Public key algorithms (with variable number of bits, typically 1024 or 2048):
- RSA (PKCS#1, Rivest, Shamir, Adleman)
- DSA (Digital Signature Algorithm)
- KEA (Key Exchange Algorithm)
- ECDSA (Elliptic Curve mathematical analog of DSA)
- ECDH (Elliptic Curve mathematical analog of Diffie-Hellman)
- Diffie-Hellman
- ...
Signature algorithms:
- RSA with MD2, MD5 or SHA-1 hash functions
- DSA with SHA-1 hash function
- ECDSA with SHA-1 hash function
The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP.
Certificate file formats:
- DER (Distinguished Encoding Rules) is widely used for digital certificates such as X.509. DER is a subset of BER (Basic Encoding Rules) providing for exactly one way to encode an ASN.1 value. DER is intended for situations when a unique encoding is needed, such as in cryptography and ensures that a data structure that needs to be digitally signed produces a unique serialized representation. DER can be seen as a canonical form of BER. DER files may also use the .CER or .CRT extensions
- PEM (Privacy Enhanced Mail): Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----"
- The PKCS #7 format enables the transfer of a certificate and all the certificates in its certification path from one computer to another, or from a computer to removable media. PKCS #7 files typically use the .P7B extension, and are compatible with the X.509 standard. PKCS #7 allows for attributes, such as countersignatures, to be associated with signatures, and attributes such as signing time can be authenticated along with message content
- PKCS #12 defines a file format commonly used to store private keys with accompanying public key certificates, protected with a password-based symmetric key. PFX is a predecessor to PKCS#12. This container format can contain multiple embedded objects, such as multiple certificates. Usually protected/encrypted with a password. Usable as a format for the Java key store and to establish client authentication certificates in Mozilla Firefox
Labels:
Security
Friday, 13 January 2012
Public Key Analogy
An analogy that can be used to understand the advantages of an asymmetric system is to imagine two people, Alice and Bob, sending a secret message through the public mail. In this example, Alice wants to send a secret message to Bob, and expects a secret reply from Bob.
In an asymmetric key system, Bob and Alice have separate padlocks. First, Alice asks Bob to send his open padlock to her through regular mail, keeping his key to himself. When Alice receives it she uses it to lock a box containing her message, and sends the locked box to Bob. Bob can then unlock the box with his key and reads the message from Alice. To reply, Bob must similarly get Alice's open padlock to lock the box before sending it back to her.
The critical advantage in an asymmetric key system is that Bob and Alice never need to send a copy of their keys to each other. This prevents a third party (perhaps, in the example, a corrupt postal worker) from copying a key while it is in transit, allowing said third party to spy on all future messages sent between Alice and Bob. So in the public key scenario, Alice and Bob need not trust the postal service as much. In addition, if Bob were careless and allowed someone else to copy his key, Alice's messages to Bob would be compromised, but Alice's messages to other people would remain secret, since the other people would be providing different padlocks for Alice to use.
In another kind of asymmetric key system, Bob and Alice have separate padlocks. First, Alice puts the secret message in a box, and locks the box using a padlock to which only she has a key. She then sends the box to Bob through regular mail. When Bob receives the box, he adds his own padlock to the box, and sends it back to Alice. When Alice receives the box with the two padlocks, she removes her padlock and sends it back to Bob. When Bob receives the box with only his padlock on it, Bob can then unlock the box with his key and read the message from Alice. Note that, in this scheme, the order of Decryption is the same as the order of encryption; this is only possible if commutative ciphers are used. A commutative cipher is one in which the order of encryption and decryption is interchangeable, just as the order of multiplication is interchangeable; i.e., A*B*C = A*C*B = C*B*A. A simple XOR with the individual keys is such a commutative cipher. For example, let E1() and E2() be two encryption functions and let "M" be the message so if Alice encrypts it using E1() and sends E1(M) to Bob. Bob then again encrypts the message as E2(E1(M)) and sends it to Alice. Now Alice Decrypts E2(E1(M)) using E1(). She'll now get E2(M), meaning when she sends this again to Bob, he will be able to decrypt the message using E2() and get "M". Although none of the keys were ever exchanged, the message "M" may well be a key, e.g., Alice's Public key. This three-pass protocol is typically used during key exchange.
The binding between a public key and its 'owner' must be correct, lest the algorithm function perfectly and yet be entirely insecure in practice. As with most cryptography, the protocols used to establish and verify this binding are critically important. Associating a public key with its owner is typically done by protocols implementing a public key infrastructure; these allow the validity of the association to be formally verified by reference to a trusted third party.
In an asymmetric key system, Bob and Alice have separate padlocks. First, Alice asks Bob to send his open padlock to her through regular mail, keeping his key to himself. When Alice receives it she uses it to lock a box containing her message, and sends the locked box to Bob. Bob can then unlock the box with his key and reads the message from Alice. To reply, Bob must similarly get Alice's open padlock to lock the box before sending it back to her.
The critical advantage in an asymmetric key system is that Bob and Alice never need to send a copy of their keys to each other. This prevents a third party (perhaps, in the example, a corrupt postal worker) from copying a key while it is in transit, allowing said third party to spy on all future messages sent between Alice and Bob. So in the public key scenario, Alice and Bob need not trust the postal service as much. In addition, if Bob were careless and allowed someone else to copy his key, Alice's messages to Bob would be compromised, but Alice's messages to other people would remain secret, since the other people would be providing different padlocks for Alice to use.
In another kind of asymmetric key system, Bob and Alice have separate padlocks. First, Alice puts the secret message in a box, and locks the box using a padlock to which only she has a key. She then sends the box to Bob through regular mail. When Bob receives the box, he adds his own padlock to the box, and sends it back to Alice. When Alice receives the box with the two padlocks, she removes her padlock and sends it back to Bob. When Bob receives the box with only his padlock on it, Bob can then unlock the box with his key and read the message from Alice. Note that, in this scheme, the order of Decryption is the same as the order of encryption; this is only possible if commutative ciphers are used. A commutative cipher is one in which the order of encryption and decryption is interchangeable, just as the order of multiplication is interchangeable; i.e., A*B*C = A*C*B = C*B*A. A simple XOR with the individual keys is such a commutative cipher. For example, let E1() and E2() be two encryption functions and let "M" be the message so if Alice encrypts it using E1() and sends E1(M) to Bob. Bob then again encrypts the message as E2(E1(M)) and sends it to Alice. Now Alice Decrypts E2(E1(M)) using E1(). She'll now get E2(M), meaning when she sends this again to Bob, he will be able to decrypt the message using E2() and get "M". Although none of the keys were ever exchanged, the message "M" may well be a key, e.g., Alice's Public key. This three-pass protocol is typically used during key exchange.
The binding between a public key and its 'owner' must be correct, lest the algorithm function perfectly and yet be entirely insecure in practice. As with most cryptography, the protocols used to establish and verify this binding are critically important. Associating a public key with its owner is typically done by protocols implementing a public key infrastructure; these allow the validity of the association to be formally verified by reference to a trusted third party.
Labels:
Security
Signing with a Digital Signature
Note: Signing data does not alter it; it simply generates a digital signature string you can bundle with the data
Labels:
Security
Wednesday, 11 January 2012
JMX Use Cases
- change configuration on the fly!!!
- notification monitoring (asynchronous)
- value monitoring (ad-hoc or periodic)
Labels:
Java
Monday, 9 January 2012
Spring JAX-WS Client
- wsimport
- Java
- applicationContext.xml
Java:
public class MyBean
{
private StockQuoteSoap stockQuoteService;
public void doSomething()
{
String result = stockQuoteService.getQuote("ADBE");
...
}
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
applicationContext.xml:
<bean id="myBean" class="com.jaxwstest.spring.MyBean">
<property name="stockQuoteService" ref="stockService" />
</bean>
<bean id="stockService" class="org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean">
<property name="serviceInterface" value="com.jaxwstest.client.StockQuoteSoap" />
<property name="wsdlDocumentUrl" value="classpath:com/jaxwstest/spring/stockquote.wsdl" /
<property name="namespaceUri" value="http://www.webserviceX.NET/" /
<property name="serviceName" value="StockQuote" />
<property name="portName" value="StockQuoteSoap" />
</bean>
Labels:
Spring,
Web Services
Friday, 6 January 2012
JAXB Customization / Annotation
- collectionType="indexed": collection properties as array instead of list properties (get/set, get[]/set[], getLength). The arrays returned and taken are not part of the content object's state
- optionalProperty (wrapper/primitive/isSet): binding for optional non-nillable element/attribute of primitive base type (use instead of deprecated "generateIsSetMethod")
- The "definition scope" covers all local attributes that can reference this global attribute declaration. This is useful since it allows the customization to be done once when a global attribute is defined instead of at each local attribute that references the global attribute declaration
- @XmlRootElement: marks an Object so that it can be marshalled. Fields and properties typically map to local elements within a complex type for a class. But a well formed XML document begins with a root element (a global element in the corresponding schema). The @XmlRootElement annotation can be used to associate a global element with a class or an enum type
- @XmlTransient prevents the mapping of a Java program element to XML
- A class usually maps to a complex type. However, using @XmlValue annotation, a class can also be mapped to a simple type (to hold a simple value) or a complexType with simpleContent (to hold a simple value and attributes)
- @XmlSchemaType allows a customized mapping to a XML Schema built in type. This is useful where a Java type can map to more than one schema built in types, e.g. XMLGregorianCalendar which can represent one of the eight schema built-in types
Labels:
Web Services
Tuesday, 3 January 2012
JAXB Notes
- marshall/unmarshall event callbacks (alternative to listener):
- beforeUnmarshal
- afterUnmarshal
- beforeMarshal
- afterMarshal
- javax.xml.bind.Binder: partial binding to a Java representation (updateXML/updateJAXB methods)
- JAXBElement offers support for:
- type substitution (xsi:type)
- element substitution groups (xsd:substitutionGroup)
- wildcards (xsd:any, xsd:anyAttribute)
- Whereas an instance of a Java value class or content interface only represents the value of an element, an instance of JAXBElement represents all element declaration features (qualified name, value, type, nil and scope)
- JAX-WS strips the JAXBElement wrapper off the type of a method parameter
- The original schema is more precise for validation purposes than the one generated from the schema-derived classes
- The default binding rule only generates an "element property" when a property represents an element that is substitutable
- The default bindings for mixed content and wildcard result in a hybrid mixture of strongly typed Java instances with DOM nodes or java.lang.String, representing text info
Labels:
Web Services
Monday, 2 January 2012
JAXB Mapping Overview
XML Schema | Details | Java | Annotation / Customization | Comments |
---|---|---|---|---|
target namespace | - |
| - | Just as the target XML namespace provides a naming context for schema components, the Java package provides a naming context for Java interfaces and classes |
simple type definition | - | property |
| A schema component using a simple type definition (element, attribute ...) typically binds to a Java property. The simple type definition defines the property's:
|
enumeration facet | enum |
| There is no mechanism to derive an enum type name for an anonymous simple type definition, the customization must provide it | |
complex type definition | global (named) |
|
| The attributes and children elements of a complex type definition are represented as properties of the Java class. A complex type definition with simple content binds its content to a property named "value" and annotated with @XmlValue. An element of type "xsd:anyType" is bound to an Object property |
anonymous within global, non-nillable, non-substitution element declaration |
| Same as above, with name and package being derived from the enclosing element declaration | ||
anonymous within local or nillable or substitution element declaration |
| |||
attribute group definition | - | - | - | There is no default mapping for an attribute group definition. When an attribute group is referenced, each attribute in the attribute group definition becomes a part of the attribute uses property of the referencing complex type definition |
model group definition | - |
| - | When a named model group definition is referenced, the JAXB property set representing its content model is aggregated into the Java value class representing the complex type definition that referenced the named model group definition. This binding style results in the same properties occurring within several value classes. However, when a model group definition’s content model contains an XML Schema component that is to be bound to a Java value class, element class or enum type, a single Java representation is created, not one for each complex content that references the named model group definition |
attribute declaration | - | property | - | An attribute declaration is bound to a Java property when it is referenced or declared (see attribute use) |
element declaration | global with anonymous type definition | ObjectFactory elementInstanceFactory |
| - |
global with named type definition | ObjectFactory elementInstanceFactory | - | ||
local within "general content property" | ObjectFactory elementInstanceFactory | - | ||
local | property | @XmlElement | If maxOccurs>1, the property is a list property | |
reference to substitution group head | JAXBElement<? extends T> property | @XmlElementRef | ||
attribute use | - | property |
| - |
"fixed" value constraint | public static final variable | @XmlAttribute and fixedAttributeAsConstantProperty="true" | - | |
attribute wildcard | - | Map<QName, String> getOtherAttributes | @XmlAnyAttribute | - |
redefine | - | - | - | A redefined complex type definition is bound to a Java value class or interface name that prepends "_" to the original class name and extends the original class |
identity constraint | - | - | - | An identity constraint does not represent any data, it represents a constraint that is enforced by validation |
complex type definition content model (particle, model group, wildcard) | complex type definition "mixed" content model | List<Object> general content property named "content" | @XmlMixed | Character information data is inserted as instances of String |
particle with maxOccurs>1 | List<Object> property of value classes |
| Only if the content model has no wildcard, no abstract element, no substitution group head, no "xsd:list" element, no IDREF element, at most one "nillable" element and, most importantly, all elements have different types | |
particle with maxOccurs>1 | List<Object> property of JAXB elements |
| Only "choice" and "sequence" can have maxOccurs>1: the allowed values for "all" minOccurs/maxOccurs are restricted to 0 or 1 by the XSD specification | |
single wilcard particle | Object property named "any" (List<Object> if maxOccurs>1) | @XmlAnyElement | If there is more than one wilcard particle, then fallback to representing the entire content model as a single general content property | |
non-repeating choice particle | simple property | choiceContentProperty="true" | - | |
content model "derived by extension" with naming collisions | List<Object> property named "rest" | - | The colliding properties are represented by a general content property with the default property name "rest" | |
other particles | property | - | If it is not possible to map each element declaration to a unique content property (name collisions ...), fallback to representing the entire content model as a single general content property |
Labels:
Web Services
XSD and Namespaces
- NCName = non-colonized name, QName = qualified name
- a schema is not required to have a namespace. The noNamespaceSchemaLocation attribute provides hints for the locations of schema documents that do not have target namespaces (like schemaLocation)
- import refers to declarations or definitions that are in a different target namespace while include refers to the same target namespace. Only global schema components can be imported
- To validate a traditional XML 1.0 document which does not use namespaces at all, you must provide a schema with no target namespace
- The redefine attribute allows simple and complex types, groups, and attribute groups that
are obtained from external schema files to be redefined in the current
schema
Labels:
Web Services
XSD Types, Element Substitution Groups/References
- The most obvious features offered in XSD that are not available in XML's native Document Type Definitions (DTDs) are namespace awareness and datatypes, that is, the ability to define element and attribute content as containing values such as integers and dates rather than arbitrary text
- Types derived by restriction must repeat all the particle components (element declarations, model groups, and wildcards) of the base type definition that are to be included in the derived type. However, attribute declarations do not need to be repeated in the derived type definition. All derived type elements must be acceptable as base type elements
- A complex type which extends another does so by having additional content model particles at the end of the other definition's content model, or by having additional attribute declarations, or both. Only appending is allowed (no other kinds of extensions)
- Using derived types instead of base types: the xsi:type attribute which is part of the XML Schema instance namespace is used to identify exactly which derived type is intended
- Type-based substitution is similar to a type cast in most programming languages, which many programmers want to avoid, and it adds the extra burden of having to sprinkle xsi:type throughout your instances. As an alternative, you can perform element-based substitution by providing substitution groups in the schema. A substitution group specifies a set of elements that can be swapped wherever a given element, also known as the head of the substitution group, is referenced (i.e. like an interface). An element indicates that it's a member of another element's substitution group through the substitutionGroup attribute
- Declaring an element as abstract requires the use of a substitution group. Declaring a type as abstract requires the use of a type derived from it and identified by the xsi:type attribute
- Attributes preventing type derivation and element substitution: "final" and "block" (element substitution only)
- Most element declarations associate a name with a type definition. Sometimes it is preferable to use an existing element rather than declare a new element. In general, the value of the ref attribute must reference a global element
Labels:
Web Services
XSD Schema Components Details
Component | Details |
---|---|
element and attribute declaration | There is a distinction between "definitions" which create new types and "declarations" which enable elements and attributes with specific names and types to appear in document instances. Global element and attribute declarations cannot contain the "Ref" attribute, they must use the "type" attribute or be followed by an anonymous type definition. No occurence constraints (minOccurs, maxOccurs, use) may appear in the declarations of global elements and attributes. To represent a "null" value with an element that is present, e.g. when being sent to or from a relational database, set the "xsi:nil" attribute to "true" |
simple type definition | Attributes always have simple types. Simple types are built by restriction (facets), list or union. The 12 simple type restriction facets are:
|
complex type definition | Elements that contain subelements/children or carry attributes are said to have complex types,
whereas elements that contain strings/numbers/dates/... but do not contain any subelements are said
to have simple types. Every complex type definition defines its own local (non-global) scope.
Complex type content models:
|
model and attribute group definition | Model and attribute group definitions do not participate in validation as such, but other components may be constructed in whole or part by reference to these groups. Thus, model and attribute group definitions provide a replacement for some uses of XML's parameter entity facility |
identity-constraint definition | Identity-constraint definition components provide for uniqueness and reference constraints with respect to the contents of multiple elements and attributes: unique, key (unique not null), keyref |
notation declaration | Reconstructs XML notation declarations. Notation declarations do not participate in validation as such. They are referenced in the course of validating strings as members of the NOTATION simple type |
model groups | Possible compositors:
|
particles | The minOccurs/maxOccurs attributes apply to "terms": elements, groups or wildcards. The default value for both the minOccurs and the maxOccurs attributes is 1. If both attributes are omitted, the term must appear exactly once |
attribute uses | Attributes can be declared with a "use" attribute to indicate whether the attribute is required, optional, or even prohibited (same usage as minOccurs/maxOccurs for terms). Default attribute values apply when attributes are missing while default element values apply when elements are empty. If an element does not appear in the instance document (i.e. it is missing), the schema processor does not provide the element at all, even if it has a default content |
wildcards | anyType represents the base type from which all simple and complex types are derived. An anyType type does not constrain its content in any way. anyType is the default type when none is specified. An "any" element specifies that any well-formed XML is permissible as content (processContents = skip/lax/strict) |
annotation | Annotations provide for human- and machine-targeted annotations of schema components ("documentation" resp. "appinfo") |
Labels:
Web Services
XSD Schema Components Overview
There are 13 kinds of
components, falling into 3 group:
- primary components:
- element declaration (named) - element
- attribute declaration (named) - attribute
- simple type definition (anonymous or named) - simpleType
- complex type defintion (anonymous or named) - complexType
- secondary components (all named):
- group definition components (re-usable definitions):
- model group definition - group
- attribute group definition - attributeGroup
- identity-constraint definitions - unique, key, keyref
- notation declaration - notation
- helper components (providing small parts of other components):
- model group components (complex types content description):
- model groups - all, choice, sequence
- particles (element, group, any) - minOccurs, maxOccurs
- attribute uses - required, default, fixed
- wildcards - any, anyAttribute (and anyType)
- annotations- documentation, appinfo
Labels:
Web Services
Subscribe to:
Posts (Atom)