1

Does the Core Service create logs on the server where it is hosted? Looking at just the fault exception it's hard to determine the right issue.

For example, below a simple Copy method is giving null exception. _Client is being initialized properly.

RepositoryLocalObjectData objData= _Client.Copy(TCMUriOfPageToCopy, 
                                                LocationFolderToCopy, 
                                                true, 
                                                _ReadOption);

As shown in image

enter image description here

  • 1
    No callstack = no answer. Check all the parameters for null – Andrey Marchuk Jul 21 '15 at 15:13
  • Hi Andrey, I verified parameters are identifiable Object in CMS using core service. Added the stack trace snap. – Chakresh Singh Jul 21 '15 at 15:22
  • Can you check if there's an error in Event viewer of CM server? BTW, it's better to insert text rather than screenshots. – Andrey Marchuk Jul 21 '15 at 15:23
  • I tried to copy the page manually in CMS and getting the same sort of error (80040356) Object reference not set to an instance of an object. Object reference not set to an instance of an object. Object reference not set to an instance of an object. <br/> I will try to copy some different page. – Chakresh Singh Jul 21 '15 at 15:29
  • 1
    Do you have an event system? – Andrey Marchuk Jul 21 '15 at 15:30
1

To answer your basic question, the logs are created where you want them to be created from the consumer application which is using the CoreService. You can create in log files on the servers where your consumer application is hosted using log4net or you can create eventsource and write it to any event log(Tridion or any other).

Also, if the code also invokes event system or any other Tridion module, then the respective logging will also be available via that system.

Like, if you create a page using CoreService and if you have event system code on page creation, that module will get executed and you will see logs for the same as well (depends on where you are logging from the same) or if you publish a page via CoreService, you will see templating logs as well, just as an example. So, based on your use case, you will have to look for different avenues, but the primary source will be the consumer application as that is where you expect to catch exceptions (if any) or log appropriately to figure out success or failure.

| improve this answer | |
1

I fully expect there to be a possibility to enable some form of debug logging for the Core Service. I also fully expect this to be an internal use feature only (that is: internal to SDL R&D) as one would only ever need to debug the core service itself if the product was broken.

The fact that the NullPointerException happens on the side of the core service itself doesn't mean the core service is at fault; one of the parameters you passed contains invalid data (not a valid folder tcmuri, not a valid item tcmuri, invalid readoptions) or the core service client itself is no longer in a valid state (it may have been closed by another thread, server application got recycled, etc).

If you really are interested in logs generated by CoreService then there are two types of logging you can enable (they're not enabled by default):

WCF tracing
Uncomment the comment out nodes below <system.diagnostics><sources>; this will cause WCF to dump heaps of information about requests and responses.

The location of the logfile is configured in the <sharedListeners> node in the initializeData property of the child <add> node.

Application logging
Under <loggingConfiguration><specialSources> find the <allEvents> node. Set it's switchValue property to "All". Change the <listener> child node's Name property from "Tridion Event Log" to "Log File"

The default file location for the log file is "C:\Program Files (x86)\Tridion\log\TcmServiceHost.log"; you can change this in the <loggingConfiguration><listeners><add name="Log File"> node by changing the fileName property.

Note that by default the application logs all informational and higher level messages to the event log.

Also note that if you connect to Core Service via HTTP/HTTPS instead of Net.TCP then the configuration file to modify is webservices\web.config as opposed to bin\TcmServiceHost.exe.config as explained in the answer here

| improve this answer | |
  • There's indeed core service logging and it's not internal. Feel free to turn it on in the app.config of you CoreService. It has commented out example, but be aware that it will affect performance a lot. In this case, message from CM event viewer should be enough to see the problem. I would be very surprised if core service would throw null ref, even with completely wrong parameters. – Andrey Marchuk Jul 22 '15 at 7:05
  • My point is: if you think the solution is to debug core service itself than you don't understand the problem well enough (or you should create a ticket for SDL support but that's an edge case). – Bjørn van Dommelen Jul 22 '15 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.