You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by "Kurt Stam (JIRA)" <ju...@ws.apache.org> on 2007/10/02 19:25:50 UTC

[jira] Assigned: (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 ]

Kurt Stam reassigned JUDDI-108:
-------------------------------

    Assignee: Kurt Stam  (was: Steve Viens)

> 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: Kurt Stam
>             Fix For: 2.0
>
>         Attachments: AbstractService.java, juddi.properties
>
>
> 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