[erlang-questions] Conflict issue

[Michael Truog]

It is trying to load the file app.config which is installed into /usr/local/etc/cloudi/app.config (if the configured prefix is /usr/local/), which is generated from https://github.com/okeuday/CloudI/blob/master/src/rel/files/app.config.in .  Within that file, you should see the only value used for the cloudi_core application is the configuration entry which provides the path to the CloudI configuration (installed at /usr/local/etc/cloudi/cloudi.conf), however, the other values help provide some appropriate defaults for a few other applications.  The error you received means that it couldn't find the configuration file path for the cloudi_core application, so adding that entry should fix the problem.

Best Regards,
Michael

On 05/07/2013 02:01 PM, Lee Sylvester wrote:
> Hi Michael,
>
> I've removed priority_queue, which fixed the issue.  The app now compiles, but when run, I get an error at line 78 of cloudi_app.erl, with the call to get_env.  Can you tell me where the configuration value in that call is pulled from CloudI, so I can ensure the data is passed?
>
> Thanks,
> Lee
>
>  
> On 7 May 2013, at 21:04, Michael Truog <mjtruog@REDACTED <mailto:mjtruog@REDACTED>> wrote:
>
>> The CloudI release should be modified to strip the application of unused modules, so that would help minimize the problem.  I will also remove the priority_queue.erl module from the pqueue application, since that should be the only module conflict with RabbitMQ.  Otherwise, you just end up renaming everything.
>>
>> Best Regards,
>> Michael
>>
>> On 05/07/2013 12:37 PM, Lee Sylvester wrote:
>>>
>>> It seems I've run into the problem again, with both RabbitMQ and CloudI both using pqueue.  This seems like a problem that should plague a lot of people.  Isn't there a preferred way of dealing with this?
>>>
>>> Thanks,
>>> Lee
>>>
>>>
>>>
>>> On 7 May 2013, at 19:49, Alex Shneyderman <a.shneyderman@REDACTED <mailto:a.shneyderman@REDACTED>> wrote:
>>>
>>>
>>>> the safest thing to do is to use jsx for json in your own
>>>> applications. Obviously you will be back to square one if two of your
>>>> deps will depend on mochijson2 but you did not state that this is your
>>>> current problem, so switching to jsx (which is actually a lot more
>>>> enjoyable interface-wise) will take you a long way.
>>>>
>>>> another solution is to rename mochijson2 to say something
>>>> leesylvester_mochijson2 in your application.
>>>>
>>>> cheers.
>>>>
>>>> On Tue, May 7, 2013 at 2:41 PM, Lee Sylvester <lee.sylvester@REDACTED <mailto:lee.sylvester@REDACTED>> wrote:
>>>>> Hi guys,
>>>>>
>>>>> So, I'm compiling CloudI into my app (safest option), but I'm getting a conflict when I compile.  The app I have using Mochijson2, but so does ecouchdb which is part of CloudI.  Thus, when I compile my app (well, actually, it's when I generate a release), I now get the error "{'EXIT',{{badmatch,{error,"Module mochijson2 potentially included by two different applications: ecouchdb and mochijson2."}},".  I've removed the mochijson2.erl file in the ecouchdb app, hoping that would force the compiler to make ecouchdb use the app version of Mochijson2, but that did nothing.  Is there something I can add to my reltool.config to fix this?  I've Googled, but nothing that made sense came up.
>>>>>
>>>>> Thanks,
>>>>> Lee
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> erlang-questions mailing list
>>>>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130507/62eeeb08/attachment.htm>