The problem i am facing is...during the installation of my WMI application (which has obfuscated dlls) below error is shown:
Incorrect usage of [ManagementBind] attribute on a method. 'a' on class 'ak' (ak, Myapp.MyProvider, Version=1.3.0.11, Culture=neutral, PublicKeyToken=213fdfdfdf32dfef) definition. It should be on a static method and there should be one matching parameter for every key defined. "
Please let me know how to resolve this error.
It does not sounds logical to obfuscate everything in your WMI provider. Since the metadata (like the names of methods, parameters and classes) describes how your WMI provider looks at the outside. Do you want the users your WMI provider to have a WMI class named ak? And a WMI method named a? I would rather have a MySomethingProvider with a GetInstances method.
But even if you want your users having to deal with obfuscated names, I think this obfuscation does not go well with how the metadata of a Managed WMI Provider should look.
For example, here the ManagementName attribute points to ID, but I bet that obfuscating it will have given ID another name. That is why they don't match
[ManagementBind]
static public WIN32ServiceHost GetInstance([ManagementName("ID")] int processId)
{
}
[ManagementKey]
public int ID
After obfuscation string in ManagementName is still ID, but now the property ID is called A.
[ManagementBind]
static public WIN32ServiceHost a([ManagementName("ID")] int a)
{
}
[ManagementKey]
public int A
So either don't obfuscate at all or only the parts that are not public or are part of your WMI API.
Related
I am trying to use an AppService in winrt/c++, following the github sample in C++/Cx. I always get the "AppUnavailable" result. I have confirmed I connect to the correct service name and have the correct family package name.
My appxmanifest:
<Extensions>
<uap:Extension Category="windows.appService" EntryPoint="BlankApp5.Inventory">
<uap3:AppService Name="com.microsoft.inventory" uap4:SupportsMultipleInstances="true"/>
</uap:Extension>
</Extensions>
My provider header file (in Mainpage.h):
namespace winrt::BlankApp5::implementation
{
class Inventory : public InventoryT<Inventory> {
public:
virtual void Run(IBackgroundTaskInstance taskInstance);
private:
BackgroundTaskDeferral mDef;
AppServiceConnection appServiceConnection;
};
My MainPage.idl file:
[default_interface]
runtimeclass Inventory : Windows.ApplicationModel.Background.IBackgroundTask
{
void Run(Windows.ApplicationModel.Background.IBackgroundTaskInstance taskInstance);
}
During IDL generation I get the following warning:
[msg]A member name has been qualified with an interface name because name collisions occurred across interface members on a runtime class. [context]"Run" has been renamed as "BlankApp5.IInventory.Run" on runtime class "BlankApp5.Inventory"
I am a bit worried that the Inventory::Run gets stripped by the linker, as it is not used internally in the serviceprovider, but I have no other idea why it doesnt work. The provider and client are in two different solutions and have no references between each other, but I assume this is not needed. The service prodiver has been deployed, but not launched. Launching makes no difference.
You needn't declare the void Run(Windows.ApplicationModel.Background.IBackgroundTaskInstance taskInstance); in your idl file, because you implement IBackgroundTask and a void Run is declared implicitly.
It is possible to automatically generate Sitecore templates just coding models? I'm using Sitecore 8.0 and I saw Glass Mapper Code First approach but I cant find more information about that.
Not sure why there isn't much info about it, but you can definitely model/code first!. I do it alot using the attribute configuration approach like so:
[SitecoreType(true, "{generated guid}")]
public class ExampleModel
{
[SitecoreField("{generated guid}", SitecoreFieldType.SingleLineText)]
public virtual string Title { get; set; }
}
Now how this works. The SitecoreType 'true' value for the first parameter indicates it may be used for codefirst. There is a GlassCodeFirstDataprovider which has an Initialize method, executed in Sitecore's Initialize pipeline. This method will collect all configurations marked for codefirst and create it in the sql dataprovider. The sections and fields are stored in memory. It also takes inheritance into account (base templates).
I think you first need to uncomment some code in the GlassMapperScCustom class you get when you install the project via Nuget. The PostLoad method contains the few lines that execute the Initialize method of each CodeFirstDataprovider.
var dbs = global::Sitecore.Configuration.Factory.GetDatabases();
foreach (var db in dbs)
{
var provider = db.GetDataProviders().FirstOrDefault(x => x is GlassDataProvider) as GlassDataProvider;
if (provider != null)
{
using (new SecurityDisabler())
{
provider.Initialise(db);
}
}
}
Furthermore I would advise to use code first on development only. You can create packages or serialize the templates as usual and deploy them to other environment so you dont need the dataprovider (and potential risks) there.
You can. But it's not going to be Glass related.
Code first is exactly what Sitecore.PathFinder is looking to achieve. There's not a lot of info publicly available on this yet however.
Get started here: https://github.com/JakobChristensen/Sitecore.Pathfinder
I'm getting the following error when I try to save an entity which has a #RelatedToVia attribute:
org.springframework.dao.InvalidDataAccessApiUsageException: Null parameter, startNode=NodeImpl#1, endNode=null, type=DynamicRelationshipType[BPA_PROPOSITION]; nested exception is java.lang.IllegalArgumentException: Null parameter, startNode=NodeImpl#1, endNode=null, type=DynamicRelationshipType[BPA_PROPOSITION]
From the error description above it seems that my RelationshipEntity is missing the end node. However, and this is the worst part of the problem, this is not true because I get this error randomly.
Here is the scenario. I'm creating some really simple tests just to check my class mappings. I manually create the classes necessary for each test case and then I save them. As Spring Data "cascades" the persistence of the entities my only concern is to populate the entity under test with its primitive properties and related entities, save it and then retrieve it back to see if the data is there.
This worked well for my first few classes which do not have #RelatedToVia mappings, but not for the ones which use #RelatedToVia. Here are some excerpts from the code which uses #RelatedToVia.
#NodeEntity
public class BasicProbabilityAssignmentFunction {
#GraphId
private Long id;
#RelatedTo(type = RelTypeConstants.BPA_FRAME, direction = Direction.OUTGOING)
private FrameOfDiscernment frameOfDiscernment;
#RelatedToVia(type = RelTypeConstants.BPA_PROPOSITION, direction = Direction.OUTGOING, elementClass = Belief.class)
private Set<Belief> beliefs;
}
#RelationshipEntity
public class Belief {
#GraphId
private Long id;
#StartNode
private BasicProbabilityAssignmentFunction bpaFunction;
#EndNode
private Proposition proposition;
}
#NodeEntity
public class Proposition {
#GraphId
private Long id;
#RelatedTo(type= RelTypeConstants.PROPOSITION_HYPOTHESIS, direction= Direction.OUTGOING)
private Set<Hypothesis> hypotheses;
#RelatedTo(type = RelTypeConstants.FRAME_PROPOSITION, direction = Direction.INCOMING)
private FrameOfDiscernment frameOfDiscernment;
}
Plus, here is an image of the variables state in debbuging mode just before calling the BasicProbabilityAssignmentFunction repository save. Notice that the Belief entity is fully populated!
And also the code used for test:
//this just creates an instance with its attributes populated
BasicProbabilityAssignmentFunction bpaFunction = BasicMockFactory.createBpaFunction();
//this is where I get the error.
bpaFunction = bpaFunctionRepository.save(bpaFunction);
One further note! I managed to stop getting this error by saving all entities (e.g., Proposition, Hypothesis etc) related to BasicProbabilityAssignmentFunction before saving BasicProbabilityAssignmentFunction itself. Nevertheless, I'm not sure why this solved the problem.
Answering Michael comment: Michael, are you saying that the rel-type should be defined in the Belief class itself (instead of using the type property of the #RelatedToVia annotation) or otherwise I should use template.createRelationshipBetween? I tried to use the #RelationshipEntity type property, but the problem persisted. What worked was saving the relationship #EndNode (Proposition) before the #Startnode (BasicProbabilityAssignmentFunction). By doing this, the Belief relationship is created (saved) without problem when the BasicProbabilityAssignmentFunction is saved.
This problem is already known. Please have a look at the following links:
http://forum.springsource.org/showthread.php?124316-Spring-Data-Neo4j-NullPointerException-with-RelatedToVia
https://jira.springsource.org/browse/DATAGRAPH-216
Is it possible to use JavaLoader to get objects returned by CF-called web services, and JavaLoader-loaded objects to be the same classpath context? I mean, without a lot of difficulty?
// get a web service
ws = createObject("webservice", local.lms.wsurl);
// user created by coldfusion
user = ws.GenerateUserObject();
/* user status created by java loader.
** this api provider requires that you move the stubs
** (generated when hitting the wsdl from CF for the first time)
** to the classpath.
** this is one of the stubs/classes that gets called from that.
*/
UserStatus = javaLoader.create("com.geolearning.geonext.webservices.Status");
// set user status: classpath context clash
user.setStatus(UserStatus.Active);
Error:
Detail: Either there are no methods with the specified method name and
argument types or the setStatus method is overloaded with argument
types that ColdFusion cannot decipher reliably. ColdFusion found 0
methods that match the provided arguments. If this is a Java object
and you verified that the method exists, use the javacast function to
reduce ambiguity.
Message: The setStatus method was not found.
MethodName setStatus
Even though the call, on the surface, matches a method signature on user--setStatus(com.geolearning.geonext.webservices.Status)--the class is on a different classpath context. That's why I get the error above.
Jamie and I worked on this off-line and came up with a creative solution :)
(Apologies for the long answer, but I thought a bit of an explanation was warranted for those who find class loaders as confusing as I do. If you are not interested in the "why" aspect, feel free to jump to the end).
Issue:
The problem is definitely due to multiple class loaders/paths. Apparently CF web services use a dynamic URLClassLoader (just like the JavaLoader). That is how it can load the generated web service classes on-the-fly, even though those classes are not in the core CF "class path".
(Based on my limited understanding...) Class loaders follow a hierarchy. When multiple class loaders are involved, they must observe certain rules or they will not play well together. One of the rules is that child class loaders can only "see" objects loaded by an ancestor (parent, grandparent, etcetera). They cannot see classes loaded by a sibling.
If you examine the object created by the JavaLoader, and the other by createObject, they are indeed siblings ie both children of the CF bootstrap class loader. So the one will not recognize objects loaded by the other, which would explain why the setStatus call failed.
Given that a child can see objects loaded by a parent, the obvious solution is to change how the objects are constructed. Structure the calls so that one of the class loaders ends up as a parent of the other. Curiously that turned out to be trickier than it sounded. I could not find a way to make that happen, despite trying a number of combinations (including using the switchThreadContextClassLoader method).
Solution:
Finally I had a crazy thought: do not load any jars. Just use the web service's loader as the parentClassLoader. It already has everything it needs in its own individual "class path":
// display class path of web service class loader
dynamicLoader = webService.getClass().getClassLoader();
dynamicClassPath = dynamicLoader.getURLS();
WriteDump("CLASS PATH: "& dynamicClassPath[1].toString() );
The JavaLoader will automatically delegate calls for classes it cannot find to parentClassLoader - and bingo - everything works. No more more class loader conflict.
webService = createObject("webservice", webserviceURL, webserviceArgs);
javaLoader = createObject("component", "javaloader.JavaLoader").init(
loadPaths = [] // nothing
, parentClassLoader=webService.getClass().getClassLoader()
);
user = webService.GenerateUserObject();
userStatus = javaLoader.create("com.geolearning.geonext.webservices.Status");
user.setStatus(userStatus.Active);
WriteDump(var=user.getStatus(), label="SUCCESS: user.getStatus()");
I'm using the decorator pattern to implement caching for my Repositories as such:
IFooRepository()
IFooRepository FooRepository()
IFooRepository CachedFooRepository(IFooRepository fooRepository)
The Cached repository checks the cache for the requested object and if it doesn't exist, calls the FooRepository to retrieve and store it. I'm currently registering these types with StructureMap using the following method:
For<IFooRepository>().Use<CachedFooRepository()
.Ctor<IFooRepository>().Use<FooRepository>();
This works fine, but as the number of cached repositories grows, registering each one individually is becoming unwieldy and is error prone. Seeing as I have a common convention, I'm trying to scan my assembly using a custom IRegistrationConvention, but I can't seem to figure out how to pass the FooRepository to the constructor of CachedFooRepository in the void Process(Type type, Registry registry) function.
I've found examples to do something like:
Type interfaceType = type.GetInterface(type.Name.Replace("Cached", "I"));
registry.AddType(interfaceType, type);
or
Type interfaceType = type.GetInterface(type.Name.Replace("Cached", "I"));
registry.For(interfaceType).Use(type);
But neither method will allow me to chain the .Ctor. What am I missing? Any ideas?