問題タブ [jaxp]

次のように JAXP を使用してドキュメントを作成しました。

ここで、ドキュメントの XML を次のように出力しようとすると、次のようになります。

transformer.transform次のエラーで行がバラバラになります：

これをデバッグするにはどうすればよいですか? が null でないことtransformerを確認しました。sourceresult

JSF2.0プロジェクトでSaxon-B9を使用します。しかし、Saxon＆Saxon-domに依存関係を追加した後、起動時に例外が発生し始めました。

2010年9月25日18:05:45com.google.apphosting.utils.jetty.JettyLogger情報情報：com.google.apphosting.utils.jetty.JettyLogger経由でJettyLogger（null）にログを記録2010年9月25日6:05： 45 PM com.google.apphosting.utils.config.AppEngineWebXmlReader readAppEngineWebXml情報：/home/chardex/projects/metabus/trunk/clients/export/target/articats/export_exploded/WEB-INF/appengine-web.xml9月25日正常に処理されました、2010 6:05:45 PM com.google.apphosting.utils.config.AbstractConfigXmlReader readConfigXml情報：正常に処理された/home/chardex/projects/metabus/trunk/clients/export/target/articats/export_exploded/WEB-INF/web .xml2010年9月25日18:05:45com.google.apphosting.utils.jetty.JettyLogger情報情報：jetty-6.1.x2010年9月25日18:05:46com.sun.faces.config.ConfigureListener contextInitialized INFO：コンテキスト用にMojarra2.0.0（RC2 b22）を初期化しています''2010年9月25日18:05:48com.sun.faces.config.ConfigManager初期化情報：失敗した開始からのサニタイズされていないスタックトレース... > com.sun.faces.config.ConfigurationException：java.util.concurrent.ExecutionException：java.lang.NoSuchMethodError：net.sf.saxon.dom.NodeWrapper $ ChildEnumeration.isAtomizing（）Z com.sun.faces.config.ConfigManager.getConfigDocuments（ConfigManager.java:670）at com.sun.faces.config.ConfigManager.initialize（ConfigManager.java:306）at com.sun.faces.config.ConfigureListener.contextInitialized （ConfigureListener.java:219）org.mortbay.jetty.handler.ContextHandler.startContext（ContextHandler.java:548）at org.mortbay.jetty.servlet.Context.startContext（Context.java:136）atorg.mortbay。 jetty.webapp.WebAppContext.startContext（WebAppContext.java:1250）at org.mortbay.jetty.handler.ContextHandler.doStart（ContextHandler.java:517）at org.mortbay.jetty.webapp.WebAppContext.doStart（WebAppContext.java： 467）org.mortbay.component.AbstractLifeCycle.start（AbstractLifeCycle.java:50）at org.mortbay.jetty.handler.HandlerWrapper.doStart（HandlerWrapper.java:130）atorg.mortbay。component.AbstractLifeCycle.start（AbstractLifeCycle.java:50）at org.mortbay.jetty.handler.HandlerWrapper.doStart（HandlerWrapper.java:130）at org.mortbay.jetty.Server.doStart（Server.java:224）at org .mortbay.component.AbstractLifeCycle.start（AbstractLifeCycle.java:50）at com.google.appengine.tools.development.JettyContainerService.startContainer（JettyContainerService.java:185）at com.google.appengine.tools.development.AbstractContainerService.startup （AbstractContainerService.java:147）at com.google.appengine.tools.development.DevAppServerImpl.start（DevAppServerImpl.java:219）at com.google.appengine.tools.development.DevAppServerMain $ StartAction.apply（DevAppServerMain.java:164） ）com.google.appengine.tools.util.Parser $ ParseResult.applyArgs（Parser.java:48）atcom.google.appengine.tools.development。DevAppServerMain。（DevAppServerMain.java:113）at com.google.appengine.tools.development.DevAppServerMain.main（DevAppServerMain.java:89）at sun.reflect.NativeMethodAccessorImpl.invoke0（Native Method）at sun.reflect.NativeMethodAccessorImpl.invoke （NativeMethodAccessorImpl.java:57）at sun.reflect.DelegatingMethodAccessorImpl.invoke（DelegatingMethodAccessorImpl.java:43）at java.lang.reflect.Method.invoke（Method.java:616）atcom.intellij.rt.execution.application。 AppMain.main（AppMain.java:115）原因：java.util.concurrent.ExecutionException：java.lang.NoSuchMethodError：net.sf.saxon.dom.NodeWrapper $ ChildEnumeration.isAtomizing（）Zatjava.util.concurrent。 FutureTask $ Sync.innerGet（FutureTask.java:252）at java.util.concurrent.FutureTask.get（FutureTask.java:111）atcom.sun.faces.config。ConfigManager.getConfigDocuments（ConfigManager.java:668）... 25 more原因：java.lang.NoSuchMethodError：net.sf.saxon.dom.NodeWrapper $ ChildEnumeration.isAtomizing（）Z at net.sf.saxon.dom.NodeWrapper $ ChildEnumeration。（NodeWrapper.java:1079）at net.sf.saxon.dom.NodeWrapper.iterateAxis（NodeWrapper.java:722）at net.sf.saxon.instruct.ApplyTemplates.defaultAction（ApplyTemplates.java:375）at net .sf.saxon.instruct.ApplyTemplates.applyTemplates（ApplyTemplates.java:333）at net.sf.saxon.Controller.transformDocument（Controller.java:1807）at net.sf.saxon.Controller.transform（Controller.java:1621 ）com.sun.faces.config.ConfigManager $ ParseTask.getDocument（ConfigManager.java:906）at com.sun.faces.config.ConfigManager $ ParseTask.call（ConfigManager.java:831）atcom.sun.faces。構成。ConfigManager $ ParseTask.call（ConfigManager.java:787）at java.util.concurrent.FutureTask $ Sync.innerRun（FutureTask.java:334）at java.util.concurrent.FutureTask.run（FutureTask.java:166）at com .sun.faces.config.ConfigManager.getConfigDocuments（ConfigManager.java:656）... 25more2010年9月25日18:05:48com.google.apphosting.utils.jetty.JettyLoggerwarnwarn

しかし、私はまだライブラリを使用しておらず、JSFがライブラリの使用を開始する理由を理解していません。ファイルjavax.xml.transform.TransformerFactoryをsaxonjarから削除しようとしましたが、役に立ちませんでした。

次のクラスを使用してXSDXML検証を実行します。

問題は、バリデーターによって返されるXSDエラーメッセージが常に英語であるということです。JAXP APIを使用してロケール対応の検証を呼び出すことは可能ですか？

古いバージョンの XML 仕様 (http://www.w3.org/1999/XMLSchema) で構築された XML スキーマがあります。スキーマを使用して XML メッセージを解析しようとしています (以下を参照)。デフォルトでは、Xerces 1.1 パーサーはアプリ ドメインのルート ディレクトリでスキーマを検索します。スキーマを Web ディレクトリのパブリックな場所に移動しようとしています。Xerces 1.1 ライブラリを使用する解析プログラムで、スキーマの場所として URL を指定できないようです。

そこで、JAXP DocumentBuilderFactory とその setSchema() メソッドを使用するようにプログラムをアップグレードしようとしました。これは、私が提供したスキーマ URL を使用してスキーマを見つけるようですが、スキーマが (おそらく) 仕様の新しいバージョンに準拠していないため、解析エラーが発生します (たとえば、Ticket 要素がないためエラーが発生します)。そのメンバーを xs:Sequence 内にラップします)。

現時点では、メッセージを送信するアプリを外部の顧客に強制的に書き直すことはできないため、スキーマをアップグレードできません。

JAXP を使用して、古い学校のバージョンのスキーマ仕様を使用して正常に解析/検証する方法を誰か教えてもらえますか? あるいは、Xerces 1.1 DOMParser に (ファイルの場所ではなく) URL で定義されたスキーマを使用するように指示する方法はありますか?

スキーマがどのように見えるかのサンプルを次に示します。

XML ドキュメントは次のようになります。

ありがとう！

当店では、複数のコア製品とお客様固有の実装を構築するプラットフォームを開発しています。プラットフォームは5年前から存在しており、現在、再考/再プラットフォーム化を試みています。プラットフォームの所有者として、以下は私が順守することを計画しているいくつかの重要な原則です

• JavaEE仕様に可能な限り近づける
• サードパーティライブラリへの依存を制限または排除する
• コントラクトをプラットフォームコンポーネントを明示的にし、可能であればosgi準拠のバンドルとして作成します
• 標準に準拠している（Java EE以外のものの場合）

そのため、変換はJAXPとXSLTに大きく依存しています。異なるベンダーのアプリサーバーと、同じベンダーの異なるバージョンのアプリサーバーにデプロイしているときに、XSLTスタイルシートで頻繁に問題が発生しました。ほとんどの場合、問題は

1. XSLTでパーサー-impl固有のものを使用する
2. パーサーの実装をアプリ内にバンドルします
3. XSLT 2.0 /XPath2.0とJAXP1.3などの使用

以下で助けが必要です

1. JAXP1.4はonltyXSLT1.0およびXpath1.0をサポートしているため、XSLTの1.0への準拠をどこで確認できますか？
2. XSLT 1.0でサポートされている機能などのリストはありますか（XSLTおよびXPathのjavadocに似たものを探しています）

javax.xml.soap.MessageFactoryを再利用できますか?
いえ

msgFactory をキャッシュして、必要に応じて新しい SOAPMessages を作成するために再利用できますか?
またmsgFactory.createMessage();、コードで msgFactory を再利用してもよい場合、同期する必要がありますか?

更新:
また、単一のスレッドコードで、毎回 MessageFactory の新しいインスタンスを作成しないように、msgFactory を保存して SOAPMessages を何度も作成できますか?

ここで難問に直面しています。

私が開発したアプリケーションの 1 つは、JAXPのDocumentBuilderFactoryクラスの正しくない実装をロードしています。この動作は、別のチーム/会社によって構築された別のアプリケーションの別のクラスが原因であると後で推測されました。上記のクラスは、以下のような静的ブロックを含めることにより、ロード時に優先 DocumentBuilderFactory クラスを変更しました。

DocumentBuilderFactory.newInstanceメソッドの Javadoc を見れば、newInstance メソッドが呼び出されたときに、上記のコードがすべてのアプリケーションに返されるパーサーの実装を変更していたことは明らかです。

この問題を修正するパッチが適用されましたが、この質問をするようになりました-どのクラスが実行時に System.setProperty 呼び出しを実行しているかをどのように判断しますか?

サーバーにデプロイされたすべてのアプリケーションのすべてのソースにアクセスできなかったという非常に単純な理由で、犯人を釘付けにする変更された System クラスを使用して、OpenJDK のカスタム ビルドを作成しました。しかし、これが可能になったのは、本番環境が完全に複製されたからです。したがって、質問は次のように解釈することもでき ます。実稼働環境で、実行時に System.setProperty 呼び出しを実行しているクラスをどのように判断するのですか?

JAXP、具体的にはSAXParserFactoryを呼び出す必要のあるアプレットがあります。これで、Javadocからわかるように、これは、ここに記載されているサービスプロバイダーメカニズムを内部的に使用します。

具体的には、呼び出されたアプリケーションJARのいずれにもファイルが見つからない場合META-INF/services/javax.xml.parsers.SAXParserFactory、アプリケーションコードベースからファイルをフェッチしようとします。アプレットを次のように展開した場合：

次に、 http：//www.example.com/myapp/META-INF/services/javax.xml.parsers.SAXParserFactoryにHTTPリクエストを送信しようとします。

特に、アプレットが署名されていて、この追加のHTTP呼び出しが署名されていないコードに関する警告をトリガーするため、そうしないほうがいいです。

さて、明らかな解決策は、META-INF / servicesファイルをアプリケーションJARに配置することですが、それでもユーザーのJREのデフォルトのJAXP実装を使用するにはどうすればよいですか？または、アプレットランタイムを説得して、JARファイルのみcodebaseを検索し、そのファイルを検索しないようにする方法はありますか？

注：JAXP-RIの独自のコピーをデプロイすることもできることは知っていますが、それはアプレットとしてはかなり重いものです。

xml 解析を行う関数があります。関数をスレッドセーフにしたいだけでなく、可能な限り最適化 (ブロッキングを少なく) したいと考えています。
短いコードでは、次のようなものです。

しかし、各呼び出しで新しい DocumentBuilderFactory または DocumentBuilder を作成したくありません。
ファクトリとパーサーを再利用したいのですが、それらがスレッドセーフかどうかわかりません。では、最も最適なアプローチは何ですか?
1) DocumentBuilderFactory をクラス フィールドにキャッシュし、factory.newDocumentBuilder(); を同期します。各スレッドが DocumentBuilder の独自のインスタンスを持つようにします。
2) DocumentBuilderFactoryとDocumentBuilder をキャッシュし、parser.parse(is); を同期します。スレッドごと
に (2) が最適だと思いますが、安全に実行できますか? また、同期によるブロックを回避できますか? できるだけ速くしたいと思います。

ありがとう？

PHP用のJAXBのようなフレームワークはありますか?

JAXB として、オブジェクトから XML ファイルを作成するフレームワークが必要です。このフレームワークは、必要に応じてその構造 (子オブジェクト、リストなど) を考慮して、オブジェクトを XML にマップする方法を認識している必要があります。

また、リバース エンジニアリングを行う必要があります。つまり、(有効な) XML ファイルを元のオブジェクトに変換します。

つまり、フレームワークはオブジェクトをマーシャリングし、XML ファイルをアンマーシャリングできなければなりません。

JAXB の素晴らしさは知っていますが、現在取り組んでいるこのプロジェクトで Java を使用できないのは本当に残念です。