[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-incubator-dev] Apache Xalan and XML Security
|
A typical solution is to start a thread from your plugin's start method to handle initialization. You just have to make sure that the code path leading to thread's creation cannot block on anything. The thread can set the "stuff initialized" flag when it completes. You then provide API for the rest of your code to wait on initialization prior to trying to access components that need to be initialized.
Oracle
Konstantin Komissarchik | Consulting Member of Technical Staff
Phone: +1 425 201 1795 | Mobile: +1 206 898 0611
Oracle Eclipse Tooling
411 108th Ave NE, Suite 2100 | Bellevue, WA 98004
-----Original Message-----
From: wtp-incubator-dev-bounces@xxxxxxxxxxx [mailto:wtp-incubator-dev-bounces@xxxxxxxxxxx] On Behalf Of info@xxxxxxxxxxxxxxxxx
Sent: Monday, November 10, 2008 1:22 PM
To: wtp-incubator-dev@xxxxxxxxxxx
Subject: Re: [wtp-incubator-dev] Apache Xalan and XML Security
Thanks for the answers. David Carver was right, after adding the
Xerces dependency to the the Apache XML Security plug-in (not my own
one) it worked. One more Orbit plug-in required...
However I've been thinking about David Williams answers. I have chosen
the start() method for the initialization work because this should be
done only once. Where is the correct place for doing that? The
initialized Apache XML Security Plug-in is almost required for any of
my plug-ins operations.
Thanks again. Dominik
Zitat von David M Williams <david_williams@xxxxxxxxxx>:
> I'm not sure of a direct answer to your question, but do notice that
>
> org.eclipse.wst.xml.security.core.XmlSecurityPlugin.start
>
> is, probably, trying to do too much, namely call
>
> org.apache.xml.security.Init.init
>
> I don't know what Init.init does, but, the start method shouldn't really
> do anything.
> (Well, there's some cases it might have to do some small thing, but best
> if it doesn't).
> Not only does the start method need to be quick, it's JavaDoc warns of
> deadlock issues
> because of the way classloaders themselves acquire locks. There's no signs
> of deadlocks
> in this one stack trace, but wonder if the behavior of classloaders is
> altered, by
> trying to do Init.init() in the start method.
>
> None of that says it is the wrong thing to do, and maybe it's required to
> be done there
> for reasons you know about, and there's definitely complicated issues with
> xerces classloading,
> but it would be interesting to move that Init.init() call to somewhere
> else, so the
> start method could finish quickly, and then security initialization take
> place
> after the plugin were started.
>
> HTH
>
>
>
>
>
>
> From:
> Dominik Schadow <info@xxxxxxxxxxxxxxxxx>
> To:
> WTP Incubator <wtp-incubator-dev@xxxxxxxxxxx>
> Date:
> 11/09/2008 10:53 AM
> Subject:
> [wtp-incubator-dev] Apache Xalan and XML Security
>
>
>
> Hi there,
>
> I'm running into a strange problem with XML Security Tools. Apache XML
> Security (org.apache.xml.security, at the moment checked in in WTP
> incubator, not moved to Orbit yet) requires Apache Xalan 2.7.0 or 2.7.1.
> Both Xalan versions are available in Eclipse Orbit. This Xalan plug-in
> has an optional dependency on Apache Xerces (org.apache.xerces, versions
> between 2.9.0 and 3.0.0). And with this dependency, XML Security could
> not be initialized and fails with the following exception (I removed
> some parts of it):
>
>
> !MESSAGE An error occurred while automatically activating bundle
> org.eclipse.wst.xml.security.core (362).
> !STACK 0
> org.osgi.framework.BundleException: Exception in
> org.eclipse.wst.xml.security.core.XmlSecurityPlugin.start() of bundle
> org.eclipse.wst.xml.security.core.
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1028)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:984)
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:265)
> at
> org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111)
> at
> org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:427)
> at
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193)
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368)
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:444)
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397)
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385)
> at
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> Caused by: javax.xml.parsers.FactoryConfigurationError: Provider
> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found
> at
> javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:104)
> at org.apache.xml.security.Init.init(Unknown Source)
> at
> org.eclipse.wst.xml.security.core.XmlSecurityPlugin.start(XmlSecurityPlugin.java:76)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:1009)
> at java.security.AccessController.doPrivileged(Native
> Method)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1003)
> ... 56 more
> Root exception:
> javax.xml.parsers.FactoryConfigurationError: Provider
> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found
> at
> javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:104)
> at org.apache.xml.security.Init.init(Unknown Source)
> at
> org.eclipse.wst.xml.security.core.XmlSecurityPlugin.start(XmlSecurityPlugin.java:76)
> at
> org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:1009)
> at java.security.AccessController.doPrivileged(Native
> Method)
>
> After removing this optional dependency XML Security Tools is working.
> In my environment, Apache Xerces 2.9.0 is available. Any ideas? Why does
> an optional dependency cause such problems?
>
> Thanks, Dominik
> _______________________________________________
> wtp-incubator-dev mailing list
> wtp-incubator-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev
>
>
>
> _______________________________________________
> wtp-incubator-dev mailing list
> wtp-incubator-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev
>
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev
