We have a central logging component which I am now trying to use in a WebJob that I am developing. I am basically following this example. My Activator is identical, I have the bindingModule that has my Bind statements in it. One thing I have done differently here is to use the method versions:
Kernel.Bind(typeof(IExternalSystemLogger)).To(typeof(ExternalSystemLogger));
instead of the generic versions in the example. I currently have constructor injection implemented but I have also set up the parameter injection as per the example. Which ever way I try to do this I end up with the error:
Error indexing method 'Functions.ProcessQueueMessage' ---> System.InvalidOperationException: Cannot bind parameter
or
a null reference exception (with parameter injection). Further into the error I am told that
Make sure the parameter Type is supported by the binding
which is the part that I am finding it difficult to resolve. I have looked at the available method calls on the config object available in WebJob.program but none seems to work. What is it I need to call so that I am correctly resolving my type when I am using a QueueTrigger or BlobTrigger?
Related
In my AutoMapper scenario, I have a string property on my source type but a Uri property on the destination. Occasionally, this conversion is expected to fail when the source data is bad:
UriFormatException: Invalid URI: The hostname could not be parsed.
at Uri.ctor(String uriString)
When this happens, I would like AutoMapper to set the problematic property to null on the destination & continue on with the process of mapping the other elements. Known solutions to this are:
Writing a custom converter (with try/catch) just for that element
Using BeforeMap() as described here
But I feel that if I have to take those extra steps, AutoMapper hasn't fulfilled its promise as a time-saving tool. Isn't there some global 'continue-on-error' flag that I can set? Note that I am less concerned about Uris in particular than I am about the lack of configurable error handling.
No special setup needed to repro this--just a vanilla CreateMap() call that registers two classes with differently typed properties.
I am facing an odd problem with Freemarker and the classloader that I did not use to have on 6.2.
Basically, there is a minor logic on the top of the template that uses Oauth. This use to work fine and I can't see a problem with it. I tried placing a variation of the Scribe everywhere I could, and even deleting the one that comes inside the ROOT.
What is odd is that the code successfully calls some methods before the exception is thrown, I guess then it is not a classloader problem but an issue with the unwrap operation. Did something change with regards to that functionality?
Code:
${callbackParameters.add(TrueNTHOAuthConstants.REDIRECT, portalUtil.getCurrentCompleteURL(request))}
<#assign trueNTHConnectLoginURL = trueNTHConnect.getAuthorizationUrl(companyId,1, callbackParameters) /> (Exception at this line)
FreeMarker template error:
No compatible overloaded variation was found; can't convert (unwrap) the 3rd argument to the desired Java type.
The FTL type of the argument values were: number (wrapper: f.t.SimpleNumber), number (wrapper: f.t.SimpleNumber), extended_hash+string (org.scribe.model.ParameterList wrapped into f.e.b.StringModel).
**The matching overload was searched among these members**:
com.sun.proxy.$Proxy799.getAuthorizationUrl(long),
com.sun.proxy.$Proxy799.getAuthorizationUrl(long, int, org.scribe.model.ParameterList, org.scribe.model.ParameterList),
com.sun.proxy.$Proxy799.getAuthorizationUrl(long, int, org.scribe.model.ParameterList)
I have just mentioned the classloader as I had to deal with several ClassNotFoundException or class definition not found to get to this point. This was somehow expected (unpredictable behavior) due to the library replication..
It's possible that you have two different classes loaded with org.scribe.model.ParameterList name. So trueNTHConnect uses another version of the problematic class than the methods called before it. The JVM will see them as totally different incompatible classes, hence there's no matching overload.
There's a sure way to find it out: debug or modify FreeMarker at the places where the class names are printed so that it prints the identity hash of the Class objects too.
I has one method to call another #Cacheable method like this:
public ItemDO findMethod2(long itemId) {
this.findMethod1(itemId);
...
}
#Cacheable(value = "Item", key="#itemId", unless="#result == null")
public ItemDO findMethod1(long itemId) {
...
}
The cache works well if I call the findMethod1() directly. However, when I call findMethod2() the the cache on findMethod1() is totally ignored.
Could it be the trick made by JVM which inline the findMethod1() into findMethod2()?
Does anyone come across similar issue?
Thanks!
It's no JVM trick, i.e. findMethod1() is not being inlined inside findMethod2() or anything of that nature.
The problem is your code is bypassing the "Proxy" that Spring is creating around your application class (containing findMethod1()) for the #Cacheable annotation.
Like Spring's Transactional annotations and underlying infrastructure, given an interface, by default Spring will create a JDK Dynamic Proxy (AOP style) to "intercept" the method call and apply the "advice" (as determined by the type of annotation, in this case, caching). However, once the target object is invoked from the interceptor (Proxy) acting on behalf of the target object to apply the advice, the Thread is now executing in the context of the target object so any subsequent method invocations from within the target object are occurring directly on the target object itself.
It looks a little something like this...
caller -> Proxy -> findMethod2() -> findMethod1()
Ideally what you want is this...
caller -> Proxy -> findMethod2() -> Proxy -> findMethod1()
However, the Thread is already executing in the context of the "target" object once inside findMethod2(), so you end up with the first call stack.
The Spring doc explains it better here.
The document goes on to point out solutions to this problem, the most favorable is refactoring your code to ensure the caller is going through the Proxy interceptor for the 2nd method invocation (i.e. findMethod1()).
I also gather another solution to this problem would be to use full-blown AspectJ, using a compiler and byte-code weaver during your application build process to modify the actual target object so that subsequent invocations from within the target object intercept and apply the advice accordingly.
See the Spring docs on the trade-offs between Spring AOP and full AspectJ, as well as how to use full AspectJ in your Spring applications.
Hope this helps.
Cheers!
Other solution I find handy is using #Resource and then invoking the target (method1 in your case) using that resource reference with https://stackoverflow.com/a/48867068/2488286
I have a Core Data "List" entity that has an ordered relationship to ListItems.
Core Data itself, generates a method in the .h,
- (void)removeListItemsAtIndexes:(NSIndexSet *)indexes;
However, when I attempt to invoke that method, at runtime the app crashes stating its an unrecognized selector.
Is this method really not implemented? Why would Core Data declare it if its not implemented? Am I supposed to do something else to make this work?
Thanks
You should look at this post:
problems-with-nsorderedset
it's lion app, but i think the problem is same.
I have an EDMX model with a generated context.
Now i generated a Self Tracking Entities library is separate project and referenced this from the EDMX model.
Also set the correct namespace in the context to the same namespace as the entities.
Now working with this all works except when i try to create a WCF data service with this context.
So just create new ObjectContext and working with it directly works fine.
But having referenced the context + model lib and the entities lib i get the following error when loading the service
The server encountered an error processing the request. The exception message is 'Value cannot be null. Parameter name: key'. See server logs for more details. The exception stack trace is:
Now i found that this could happen when using data service with external entity lib and fix was overriding the createcontext
with code
Collapse
System.Data.Metadata.Edm.ItemCollection itemCollection;
if (!context.MetadataWorkspace.TryGetItemCollection
(System.Data.Metadata.Edm.DataSpace.CSSpace, out itemCollection))
{
var tracestring = context.CreateQuery<ClientDataStoreContainer>("ClientDataStoreContainer.DataSet").ToTraceString();
}
return context;
Now the error is gone but i get the next one and that is:
Object mapping could not be found for Type with identity 'ClientDataStoreEntities.Data'.
This error occurs on the .toTraceString in the createcontext
the ssdl file has the defined type
Collapse
<EntitySetMapping Name="DataSet">
<EntityTypeMapping TypeName="IsTypeOf(ClientDataStoreEntities.Data)">
So it has to load the ClientDataStoreEntities.Data type which is the namespace and type of the STE library that i have generated from the model.
EDIT: with
var tracestring = context.CreateQuery<Data>("ClientDataStoreContainer.DataSet").ToTraceString();
It does seem to load all types , however now the service does not have any methods that i can call.
there should be 2 DataSet and PublishedDataSet but:
<service xml:base="http://localhost:1377/WcfDataService1.svc/">
−
<workspace>
<atom:title>Default</atom:title>
</workspace>
</service>
is what i get.
I ran into the same issue (the first one you mention). I have worked around using the suggestion by Julie Lerman in this thread. The other suggestion didn't work for me although I will experiment with them more since Julie's solution may have performance implications since it's executed (and has some cost) for every query.
MSDN Fail to work with POCO ModelContainer which entities are located in other assembly
Edit: Sorry, just realized you utilized the other solution mentioned in this thread.