[ 
https://issues.apache.org/jira/browse/JUDDI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kurt Stam updated JUDDI-108:
----------------------------

    Fix Version/s: 2.0

> 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
>             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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to