Create FXDContent from raw FXD string

Question

Hi,
Just wondering if anyone might know whether it's possible to directly instantiate an FXDContent object using a string which contains FXD?
For example, the string would be "*FXD { content: [Ellipse { centerX: 100.0 ...  }*".
It seems that the only way to create either an FXDContent object or FXDNode is via a load of a (well-formed) URI using FXDLoader.
(Hopefully in my noob-ness i haven't missed something here!)
I would like to be able to use my own subclass of HttpRequest to request FXD, in addition to other business data, from my servlet and manage the response (incl. headers, etc.) and load the FXD manually into an FXDContent object.
This would neatly avoid hitting the servlet once for the business data, and then hitting it again via the FXDLoader.
Just wondering if this would be possible, or if there are workarounds?
[I am using NetBeans 6.9.1 and JavaFX 1.3.1, and i have searched but not found any particularly relevant threads on the forum.]
Thanks in advance,
Steve

Answer 1

I found a way using the BC provider (1.3.6). It goes like this.
import org.bouncycastle.asn1.pkcs.PKCSObjectIdentifiers;
import org.bouncycastle.asn1.x509.AlgorithmIdentifier;
import org.bouncycastle.asn1.x509.SubjectPublicKeyInfo;
    AlgorithmIdentifier algid =
      new AlgorithmIdentifier(PKCSObjectIdentifiers.sha1WithRSAEncryption);
    SubjectPublicKeyInfo spki = new SubjectPublicKeyInfo(algid, rawKeyBytes);
    byte[] x509KeyBytes = spki.getDEREncoded();The x509KeyBytes may now be used to create a PublicKey using the security API.
    KeyFactory keyFactory = KeyFactory.getInstance("RSA");
    Key publicKey = keyFactory.generatePublic(new X509EncodedKeySpec(x509KeyBytes));I would really like to avoid using the BC API directly, and rather use the standard API all the way. So any ideas are certainly welcome!
I noticed a slight difference in the length of the algorithm identifier created this way compared to using the IAIK provider as shown in may original posting, 20 vs 22 bytes respectively. Below the algid + first bytes of the raw key bytes are show hex-encoded.
BC:   30819d300b06092a864886f70d01010503818d00 30818902818100..
IAIK: 30819f300d06092a864886f70d010101050003818d00 30818902818100..As I haven't found a good definition of these bytes I don't what the difference is, but since both keys appear to work equally well I guess I should be happy with that.
Dagbj�rn