| Author |
Message
|
| gilc |
 Posted: Thu Aug 16, 2012 3:49 am Post subject: wmb8 - xsd in shared libraries |
 |
|
Apprentice
Joined: 17 Mar 2011
Posts: 32
|
Hey,
In wmb8 the use of shared libraries seemed like a great solution for our project. Or so we thought....
We have a general xsd (let's call him ESBHeader.xsd) which contains a header for every messsage in the organization and it's located in a library called ESBCommon. Every other library (i.e BlaLib) will have a reference to ESBCommon and in its message declaretions (i.e bla.xsd) it'll use ESBHeader.xsd as so:
| Code: |
<import namespace="http://org.com/esb" schemaLocation="../ESBCommon/ESBHeader.xsd"/> |
So far so good.
The problem is at runtime when trying to use a mapping node (for example) to set some fields in ESBHeader.xsd, we receive an error of:
Schema bla.xsd could not resolve xml schema location
Isn't one of the purposes of the libraries is to be able to share schemas freely? Are we missing something?
Thanks for the help,
~ Gil |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Aug 16, 2012 4:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Are you trying to deploy the shared library to the default application, and then use it from within another application? |
|
| Back to top |
|
|
| gilc |
| Posted: Thu Aug 16, 2012 4:52 am Post subject: |
|
|
Apprentice
Joined: 17 Mar 2011
Posts: 32
|
I'm not using applications at all. Both ESBCommon and BlaLib are libraries.
And I forgot to mention that both are deployed to the same execution group. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 16, 2012 5:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| gilc wrote: |
| I'm not using applications at all. |
The first rule of v8 is that everything is deployed to an application.
So, yes, you are using an application. It's the default application.
| gilc wrote: |
| Both ESBCommon and BlaLib are libraries. |
Is ESBCommon marked as a library reference to BlaLib? Not a project reference, a library reference.
If you deploy *just* BlaLib, does ESBCommon get deployed as well?
| gilc wrote: |
| And I forgot to mention that both are deployed to the same execution group. |
That's good news. You can't access things outside of the current application at all, so trying to cross EG boundaries is twice as impossible. |
|
| Back to top |
|
|
| gilc |
| Posted: Thu Aug 16, 2012 5:36 am Post subject: |
|
|
Apprentice
Joined: 17 Mar 2011
Posts: 32
|
I'll start from the end if you please -
| Quote: |
Is ESBCommon marked as a library reference to BlaLib? Not a project reference, a library reference.
If you deploy *just* BlaLib, does ESBCommon get deployed as well?
|
ESBCommon is a library reference to BlaLib and so when I deploy only BlaLib, ESBCommon is deployed as well.
| Quote: |
The first rule of v8 is that everything is deployed to an application.
|
I read the infocenter from start to end about the new version and its features (yes, I have a lot of time on my hands) and didn't comprehend this critical point :/ (Thank you ESL!)
As for my understanding, Libs are used to share resources and that's exactly what we needed, while applications are stand-alone solutions.
Moreover, when playing a bit with the new version, we found out that if there are 2 applications that are using the same ESBCommon library (with library reference), and there is a change in that library, not only we need to deploy the lib again, but the applications as well (and that's missing the point of all the sharing features, isn't it?)... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 16, 2012 6:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| gilc wrote: |
I'll start from the end if you please -
| Quote: |
Is ESBCommon marked as a library reference to BlaLib? Not a project reference, a library reference.
If you deploy *just* BlaLib, does ESBCommon get deployed as well?
|
ESBCommon is a library reference to BlaLib and so when I deploy only BlaLib, ESBCommon is deployed as well. |
Okay. Then I'd apply FixPack1 and see if that helps.
| gilc wrote: |
| Quote: |
The first rule of v8 is that everything is deployed to an application.
|
I read the infocenter from start to end about the new version and its features (yes, I have a lot of time on my hands) and didn't comprehend this critical point :/ (Thank you ESL!)
As for my understanding, Libs are used to share resources and that's exactly what we needed, while applications are stand-alone solutions.
Moreover, when playing a bit with the new version, we found out that if there are 2 applications that are using the same ESBCommon library (with library reference), and there is a change in that library, not only we need to deploy the lib again, but the applications as well (and that's missing the point of all the sharing features, isn't it?)... |
Yes, this is a bit unclear. The point is that if you deploy things outside of an explicit application, they are still deployed INTO an application - it's just not an explicitly named application.
An application is two things: a Toolkit container and a Runtime container. Anything you deploy to a v8 Broker is deployed into a Runtime application container. You can choose in the Toolkit to create a named application container, and deploy that named container. If you choose NOT to create a named container in the Toolkit, you are still deploying into a Runtime application container.
This means that you can't share resources that are deployed inside a named application with resources that are outside that named application. |
|
| Back to top |
|
|
| gilc |
| Posted: Thu Aug 16, 2012 6:35 am Post subject: |
|
|
Apprentice
Joined: 17 Mar 2011
Posts: 32
|
| Quote: |
| Okay. Then I'd apply FixPack1 and see if that helps |
We are planning on installing the new fixpack next week so hopfully it'll help. I'll update this thread when and if there are news.
And thank you very much for your explaination!! It definitely cleared a few things |
|
| Back to top |
|
|
| gilc |
| Posted: Tue Aug 21, 2012 12:24 am Post subject: |
|
|
Apprentice
Joined: 17 Mar 2011
Posts: 32
|
| We've applied the fixpack 8.0.0.1 and it seems to solve the problem |
|
| Back to top |
|
|
| Ualter |
| Posted: Thu Nov 07, 2013 11:49 am Post subject: Sharing XSD through Libraries-not working on Broker 8.0.0.2 |
|
|
Newbie
Joined: 10 Sep 2013
Posts: 4
|
Hi Gilc,
Did you solve this problem?
We are trying this as well, but in runtime environment is not working properly, just on design time (Toolkit).
I have a XSD call ServiceHeader.xsd that it is on a Library.
On a Application that is referencing this Library, I have a WSDL that it's trying to import this XSD, in this manner:
| Code: |
<xsd:import namespace="xxx/ArqIIB/v1/ServiceHeader"
schemaLocation="../Incubadoralib/ServiceHeader.xsd"/>
|
However, on design time everything it's seems ok, but after the deploy, we could'nt manage to get the WSDL work properly, because the XSDs aren't being found.
That's what we have on the WSDL
| Code: |
<wsdl:types>
<xsd:schema>
<xsd:import namespace="xxx/ConsultarCliente/" schemaLocation="_xxx/Clientes?xsd=xsd0"/>
<xsd:import namespace="_xxx/ServiceHeader" schemaLocation="../Incubadoralib/ServiceHeader.xsd"/>
</xsd:schema>
</wsdl:types>
|
The both resources cannot be found.
Our Broker (runtime) is version 8.0.0.2.
If you can help us with any advice or tips, we appreciate.
Thanks,
Ujr |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Nov 08, 2013 1:08 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
This is a known problem. You need IC94463, which is included in v8.0.0.3.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| Ualter |
| Posted: Fri Nov 08, 2013 4:46 am Post subject: |
|
|
Newbie
Joined: 10 Sep 2013
Posts: 4
|
| kimbert wrote: |
| This is a known problem. You need IC94463, which is included in v8.0.0.3. |
Thank you very much Kimbert. You help us a lot.
So... for now we're going to find another way to achieve this.
Regards,
Ualter |
|
| Back to top |
|
|
|
|
