oarevalo / BugLogHQ

BugLogHQ is a tool to centralize the handling of automated bug reports from multiple applications. BugLogHQ provides a unified view of error messages sent from any number of applications, allowing the developer to search, graph, forward, and explore the bug reports submitted by the applications.
http://www.bugloghq.com
155 stars 67 forks source link

The ENTRYBEAN argument passed to the logEntry function is not of type rawEntryBean #131

Closed KrunchMuffin closed 8 years ago

KrunchMuffin commented 8 years ago

Ok I am going nuts trying to figure this out. I haven't changed anything, I don't think at least. At first it was this message in the validate method, so I stripped out and left return true since I don't use the APi key. Now I get it in logEntry. All the tests in the Utils pass.

KrunchMuffin commented 8 years ago

I have narrowed this down to something to do with the implementation I have. I have stage and prod on the same server (unfortunately). I have the stage bugloglistener pointing to the prod version. I only want the prod version to be the one that accepts the reports. Errors triggered on prod work fine, but on stage I get that error. What am I doing wrong in the config?

oh, and application names are both different. stage says bugLogHQ_Stage and prod is just bugLogHQ

oarevalo commented 8 years ago

Stage and Prod are full copies of the Buglog code? or are you using the named instance approach? (i.e. only copy the config file)

KrunchMuffin commented 8 years ago

no, i am not using the named instance. was going to start however.

yes, full copies.

oarevalo commented 8 years ago

That might be the problem. BugLog uses the server scope to keep the "listener" instance, so 2 exact copies of the app may lead to some conflict. Using named instances goes around this by assigning unique names to each listener reference on the server scope, thus avoiding any conflict.

KrunchMuffin commented 8 years ago

ahh..ok, let me try that and see what happens.

KrunchMuffin commented 8 years ago

so since I don't need the stage copy, if i remove it and point BL Listener to the prod version, should that not take care of it?

KrunchMuffin commented 8 years ago

ok, looks to be all sorted out now.

removed stage copy have /buglog in admin mappings pointing to prod version using buglog.listener.bugloglistenerWS

seems to be ok.

oarevalo commented 8 years ago

hmm, for example this is how a typical deploy would be:

/bugLog
  ...  (full app, with Production settings)
/dev
  Application.cfc     // extends bugLog.hq.Application
  index.cfm            // cfinclude to /bugLog/hq/index.cfm
  /config
     buglog-config.xml.cfm   // alternate config (differnt dsn, etc)
  listener.cfc     // empty cfc that just  extends bugLog.listeners.bugLogListenerWS
  listener.cfm    // a cfinclude to /bugLog/listeners/bugLogListenerREST.cfm

any app that wants to use the dev instance will go directly to /dev/listener.cfc or /dev/listener.cfm

KrunchMuffin commented 8 years ago

is /dev inside Buglog or same level?

oarevalo commented 8 years ago

same level, but if you have the buglog full app deployed to the root, then /dev/ can also be inside

it doesnt matter where it is, as long as your paths in the includes/extends are adapted properly.

KrunchMuffin commented 8 years ago

ok, if I get some time I will try that. I don't really need to have multiple instances. Thanks.

oarevalo commented 8 years ago

:+1: Please close the issue if everything is working as you expect. Thanks!