You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by "Patrick Leamon (JIRA)" <ju...@ws.apache.org> on 2007/07/16 18:17:04 UTC
[jira] Updated: (JUDDI-108) Add ability to configure MessageFactory
from juddi.properties
[ https://issues.apache.org/jira/browse/JUDDI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Leamon updated JUDDI-108:
---------------------------------
Attachment: AbstractService.java
org.apache.juddi.registry.AbstractService.java
- added loadFactoryFromConfig() method called from line 92
- new private constant for configuration property name
> Add ability to configure MessageFactory from juddi.properties
> -------------------------------------------------------------
>
> Key: JUDDI-108
> URL: https://issues.apache.org/jira/browse/JUDDI-108
> Project: jUDDI
> Issue Type: New Feature
> Components: Feature Requests Section
> Affects Versions: 0.9rc4
> Environment: Weblogic 9.2
> Reporter: Patrick Leamon
> Assignee: Steve Viens
> Attachments: AbstractService.java
>
>
> I've been trying to deploy the jUDDI war onto weblogic, and have had a few errors on the way. Weblogic has it's own web services implementations which initially conflict with those required by jUDDI. See http://static.springframework.org/spring-ws/site/faq.html#saaj-weblogic9 for details. Most of these incompatibilities can be worked around by using weblogic's '<prefer-web-inf-classes>' deployment descriptor option.
> The one section I haven't been able to consistently work around is the MessageFactory implementation. The implementation appears to be selected based on the system property: 'javax.xml.soap.MessageFactory'. This can be set on application server startup and Weblogic will use it's value correctly until any of it's UDDI tools are used. Once one of these tools are used (e.g. UDDI explorer), it overwrites the current value with it's own message factory implementation. Weblogic's message factory leaves jUDDI in a non-functioning state.
> In order to work around this (and possibly other scenarios), I'm proposing a patch which will allow the MessageFactory implementation to be specified in juddi.properties. This would be an optional property. The implementation specified in properties would take precedence over the instance returned by javax.xml.soap.MessageFactory.newInstance(); but there will be appropriate fall-backs.
> I'm open to any other proposals.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org