I have a class marked as CollectionDataContract which has a enum member. When I place an object of this class in Appfabric, I am through. When I get it back from App fabric, it does not deserialize the enum member. But I am not sure if the enum has been missed out in Serialization part itself.
Please do help.
If you need more information let me know.
Thanks.
[CollectionDataContract]
public partial class RuleConditionList : List<IRuleCondition>, IRuleCondition
{
public LogicalOperator Operator;
}
where LogicalOperator is an enum
I think there is a problem when serializing/deserializing your object. AppFabric uses the NetDataContractSerializer class for serialization before storing the items in the cache.
You can use the NetDataContractSerializer on any type which are marked with the DataContractAttribute or SerializableAttribute, or types that implement the ISerializable interface.
So depending and your object, there should be something wrong like a private type, a private field, a missing attibute, ...
Edit
You should add DataMember to your field.
[DataMember]
public LogicalOperator Operator;
Any data member in a class marked with Collection data contract cannot be serialized by NetdataContractSerializer which is the serailization technique used by App fabric for storing data.
To make things work we have two options:
Make a wrapper for RuleConditionList
Instead of Inheriting from List, make it as a property and change the attribute as DataContract.
Related
I have autowired a class as #Autowired(required=true) private CookieDao ewp;
I am trying to use the ewp to call a function ewp.getCookieEntry(id, name );
How do I access the contents of ewp. Since it is a object I get classname#hashcode but after .toString() , I just get the classname.
If ewp is autowired, then is it the same as CookieDao ewp = new CookieDao();? If not, then what is it called and how can I extract it's values?
I believe that you need to annotate your CookieDao with #Repository to the autowired work just fine, for more information have a looks into this answer : Understanding Spring #Autowired usage
There seems be some things missing in the Spring-LDAP ODM annotations. This is a question by way of a feature request, if there is a better way to contribute such requests, please say so.
I'd like to mark an #Attribute as read-only, so it will populate the bean from LDAP for reference, but not persist it back to ldap. I'd suggest adding an attribute read-only to #Attribute, defaulting to false, for the usual case. The default attributes of * misses all the operational attributes, some of which are very useful, and transfers more data than is required, slowing down the ldap query with attributes which will never be used.
An example of this; it would be very useful, for literally read only, such as entryUUID, etag, etc., which you cannot use if you wish to persist only some fields back to ldap, as the bean fails to persist to ldap with an exception when you save the bean. But also would be usefule for general fields which you want to structurally prevent the user from ever updating.
You can get around this by not annotating read-only fields, and then manually populating the read only fields with a separate call. Very messy and kills the query speed.
Also on a related topic, query() coudl have a default list of attributes, which you have already annotated in your classes, something like :
public static String[] getBeanAttributes(Class<?> beanClass) {
ArrayList<String> attrsObj = new ArrayList<>();
for (Field field : beanClass.getDeclaredFields()) {
if (field.isAnnotationPresent(Attribute.class)) {
Attribute attr = field.getAnnotation(Attribute.class);
attrsObj.add(attr.name());
}
}
String[] attrs = attrsObj.toArray(new String[attrsObj.size()]);
return attrs;
}
Above just returns a simple String[] of your declared attributes, to pass to query.attributes() - now i realize that as a static member, query() is built before the bean class is known, but at least there could be a helper function like the above, or a method signature for query attributes() that took a bean Class signature as an argument.
I created LDAP-312 on Jira. Thanks.
I have class A that derives from System.Data.Objects.DataClasses.EntityObject.
When I try to serialize using
var a = new A();
DataContractJsonSerializer serializer = new DataContractJsonSerializer(a.GetType());
serializer.WriteObject(Response.OutputStream, a);
I get error
TestController+A._Id' is not marked with OptionalFieldAttribute, thus indicating that it must be serialized. However, 'TestController+A' derives from a class marked with DataContractAttribute and an IsReference setting of 'True'. It is not possible to have required data members on IsReference classes. Either decorate 'TestController+A._Id' with OptionalFieldAttribute, or disable the IsReference setting on the appropriate parent class.
Even if I decorate the field with OptionalFieldAttribute I get
The type 'TestController+A' cannot be serialized to JSON because its IsReference setting is 'True'. The JSON format does not support references because there is no standardized format for representing references. To enable serialization, disable the IsReference setting on the type or an appropriate parent class of the type.
I cannot modify EntityObject class. I thought to create A_Bag class exactly as A class and fill it and serialize it instead of A, but I think there's more elegant way to do it.
Can you suggest how I can do it?
I think you can use a "data contract surrogate" here (used via the IDataContractSurrogate interface.)
The data contract surrogate is an advanced feature built upon the Data Contract model you're already using. It lets you do type customization and substitution in situations where you want to change how a type is serialized, deserialized, or (if you're dealing with XML) projected into schema.
In your case, the use of IDataContractSurrogate lets you do custom JSON serialization and deserialization on a per-type or per-object basis. An IDataContractSurrogate would provide the methods needed to substitute one type for another by the DataContractSJsonerializer during serialization and deserialization, and you may want to provide a different "special" intermediary type for your scenario.
Hope this helps!
JSON.Net supports serialization of objects marked with IsReference=true.
There is a detailed walkthrough here:
http://dotnet.learningtree.com/2012/04/03/working-with-the-entity-framework-and-the-web-api/
I want sharepoint to "persist" a List of object
I wrote a class SPAlert wich inherit from SPPersistedObject :
public class SMSAlert: SPPersistedObject
{
[Persisted]
private DateTime _scheduledTime;
[Persisted]
private Guid _listId;
[Persisted]
private Guid _siteID;
}
Then I wrote a class wich inherit from SPJobDefinition an add a List of my previous object:
public sealed class MyCustomJob: SPJobDefinition
{
[Persisted]
private List<SMSAlert> _SMSAlerts;
}
The problem is :
when I call the Update method of y MyCustomJob:
myCustomJob.Update();
It throw an exception :
message :
An object in the SharePoint
administrative framework, depends on
other objects which do not exist.
Ensure that all of the objects
dependencies are created and retry
this operation.
stack
at
Microsoft.SharePoint.Administration.SPConfigurationDatabase.StoreObject(SPPersistedObject
obj, Boolean storeClassIfNecessary,
Boolean ensure) at
Microsoft.SharePoint.Administration.SPConfigurationDatabase.PutObject(SPPersistedObject
obj, Boolean ensure) at
Microsoft.SharePoint.Administration.SPPersistedObject.Update()
at
Microsoft.SharePoint.Administration.SPJobDefinition.Update()
at
Sigi.Common.AlertBySMS.SmsAlertHandler.ScheduleJob(SPWeb
web, SPAlertHandlerParams ahp)
inner exception
An object in the SharePoint
administrative framework depends on
other objects which do not exist.
The INSERT statement conflicted with
the FOREIGN KEY constraint
"FK_Dependencies1_Objects".
The conflict occurred in database
"SharePoint_Config, table
"dbo.Objects", column 'Id'. The
statement has been terminated.
Can anyone help me with that??
Ensure that your class is marked with a unique GUID, using [System.Runtime.InteropServices.Guid("GUID")] and ensure that the persisted object's class has a default constructor. Hope this help.
Both the above suggestions are very important, adding a Guid attribute and ensuring you have a default constructor. Not only for your persisted SMSAlert object, but make sure you have these for your SPJobDefinition as well.
Additionally, if you create collections of SPPersistedObject you have to ensure that each object in the collection is also updated. A better alternative is to make SMSAlert an SPAutoSerializingObject. Collections of SPAutoSerializingObject, as the name implies, are automatically serialized.
For more information on persisted objects see this extremely useful post:
http://www.chaholl.com/archive/2011/01/30/the-skinny-on-sppersistedobject-and-the-hierarchical-object-store-in.aspx
Did you specify the default constructor for SMSAlert?
After the previous question "What are the important rules in Object Model Design", now I want to ask this:
Is there any way to have dynamic properties for class instances?
Suppose that we have this schematic object model:
So, each object could have lots of properties due to the set of implemented Interfaces, and then become relatively heavy object. Creating all the possible -and of course reasonable- object can be a way for solving this problem (i.e. Pipe_Designed v.s. Pipe_Designed_NeedInspection), but I have a large number of interfaces by now, that make it difficult.
I wonder if there is a way to have dynamic properties, something like the following dialog to allow the end user to select available functionalities for his/hers new object.
What you want is Properties pattern. Check out long and boring but clever article from Steve Yegge on this
I think maybe you're putting too many roles into the "Road" and "Pipe" classes, because your need for dynamic properties seems to derive from various states/phases of the artifacts in your model. I would consider making an explicit model using associations to different classes instead of putting everything in the "Road" or "Pipe" class using interfaces.
If you mean the number of public properties, use explicit interface implementation.
If you mean fields (and object space for sparse objects): you can always use a property bag for the property implementation.
For a C# example:
string IDesigned.ApprovedBy {
get {return GetValue<string>("ApprovedBy");}
set {SetValue("ApprovedBy", value);}
}
with a dictionary for the values:
readonly Dictionary<string, object> propValues =
new Dictionary<string, object>();
protected T GetValue<T>(string name)
{
object val;
if(!propValues.TryGetValue(name, out val)) return default(T);
return (T)val;
}
protected void SetValue<T>(string name, T value)
{
propValues[name] = value;
}
Note that SetValue would also be a good place for any notifications - for example, INotifyPropertyChanged in .NET to implement the observer pattern. Many other architectures have something similar. You can do the same with object keys (like how EventHandlerList works), but string keys are simpler to understand ;-p
This only then takes as much space as the properties that are actively being used.
A final option is to encapsulate the various facets;
class Foo {
public bool IsDesigned {get {return Design != null;}}
public IDesigned Design {get;set;}
// etc
}
Here Foo doesn't implement any of the interfaces, but provides access to them as properties.