In my API'm using softDeletable. This makes JMSSerialize throw the exception: EntityNotFoundException.

Example: A post with an author. I soft-delete the author and request the post.

The expected json is:

"author": null

I tried to fix this problem and submit a PR but I couldn't fix it.

Any clues on how to do it?

Related:
http://stackoverflow.com/q/11057504/842697
https://github.com/l3pp4rd/DoctrineExtensions/issues/505#issuecomment-13351451

My really poor solution:

I can prevent the Exception with this:

try{
    $object->__load();
} catch (\Doctrine\ORM\EntityNotFoundException $e) {
    return;
}

at DoctrineProxySubscriber.php#L51.

The result is:

"author": {}

And I really don't know the collateral problems of this.

When I try to serialize an array that contains one empty object into json, it fails with the error:

PHPUnit_Framework_Error_Warning : json_encode(): recursion detected
#0 [internal function]: PHPUnit_Util_ErrorHandler::handleError(2, 'json_encode(): ...', '...', 29, Array)
#1 ...\www\vendor\jms\serializer\src\JMS\Serializer\JsonSerializationVisitor.php(29): json_encode(Object(ArrayObject), 0)

Here's the test:

public function testSerializeArrayWithEmptyObject()
{
    $this->assertEquals('[{}]', $this->serialize(array(new Author(null))));
}

Looks like it's related to schmittjoh/JMSSerializerBundle#271

Hi,

I have a case where I'd like to specify properties/entities at runtime. Doing this using the groups tactic will result in a unwanted high maintenance situation. As a lot of groups need to be defined for many possible combinations. Unless groups is abused and a group is defined for every property. I guess that it's not only wanted, but also not the idea behind groups.

I would settle for a builder approach, something that the SerializationContext class might embrace. An idea is to introduce a certain profile/definition:

// Accept requirements from the request
$serializationProfile = SerializationProfile::create( $request->getParams() );

// Last-minute override
$serializationProfile->getRelation('orders')->exclude(array('profit'));

// just for demonstration
$serializationProfile->only(array('id', 'username', 'e-mail'));

// The actual serialization
$serializer->serialize($model, 'json', $serializationProfile);

This way it's trivial for a client to specify fields and optionally what resources to embed. Example:

/user/42?embed=address,orders.product&orders.product.properties=id,name

This should:

• Include all the "addresses" this user has
• Include all the "orders" this user has
• Include the product id and name for each product in the order

Hello,
I was sending some JSON like

    {"success":true,"message":"OK","data":{"id":15,"foo":23,"campaign":"ASDF","campaign_id":1}}

and got this:

Warning: array_key_exists() expects parameter 2 to be array, string given in /srv/www/vendor/jms/serializer/src/JMS/Serializer/GenericDeserializationVisitor.php line 165

When I stop sending "campaign", only "campaign_id" it seems to work.

It might very well be that I missed something, or using it wrong, but this patch might be useful anyway :)

--- vendor/jms/serializer/src/JMS/Serializer/GenericDeserializationVisitor.php.old  2013-03-28 16:02:37.909925723 +0100
+++ vendor/jms/serializer/src/JMS/Serializer/GenericDeserializationVisitor.php  2013-03-28 16:01:37.640657807 +0100
@@ -161,7 +161,7 @@
     public function visitProperty(PropertyMetadata $metadata, $data)
     {
         $name = $this->namingStrategy->translateName($metadata);
-        if (null === $data || ! array_key_exists($name, $data)) {
+        if (null === $data || !is_array($data) || ! array_key_exists($name, $data)) {
             return;
         }

I see it has been implemented in the bundle there schmittjoh/JMSSerializerBundle#177. How hard would it be to move this here ?

With extended classes, like below, deserialization dose not work proper.
class A {}
class B extends A {}

I understand how the "discriminator" works with class A, but when i call
$serializer->deserialize($data, 'B', 'json');
it should not be depended on how the discriminator work on A, but it should deserialize the data as B, i think.

ClassMetadata is selected correctly, but propertyMetadata is overwritten by A's property.
As serialization, it should use B's property rather than A's.

it may be caused by jms/metadata so i show you my versions
jms/metadata - 1.3.0
jms/serializer - 0.12.0

I'm trying to serialize an object and manipulate its data before handing it off for another process.

1. Grab said object
2. Attempt Serialization
3. Note that the serialized object is completely empty.

example object:

use JMS\Serializer\Annotation as Serializer;

class Thingy {
  /**
   * @property string $name
   */
  private $name;

  /**
   * Do something with the serializer...
   * @Serializer\HandlerCallback("json", direction="serialization")
   */
  public function postSerialize(GenericSerializationVisitor $visitor) {
     $visitor->addData('bob', 'loblaw');
  }
}

test scenario:

$thingy = new Thingy();
$output = $serializer->serialize($thingy, 'json');
var_dump($output);

result:

expected result:

{
  'bob': 'loblaw'
}

I'm writing a library right now and was wondering what is the best way of declaring a class/metadata file as serializable. In my library, I'm suggesting to install the serializer, but it's not installed by default.

So to ask my question simply:

What's the best way of defining metadata without forcing users to just add the directory I provide....

I'd like to be able to do something like,

$j = (new MyBuilder())
    ->attachSerializer($jmsSerializer)
    ->build();

and then my library is in charge of defining where my class metadata lies, etc.

Granted, if this is a Symfony2 bundle instead of a library, this is easy to do, but it's not.

I may be over thinking this.... maybe a break from a computer will help. 👅

Let me know if you know of the best solution.

It doesn't appear that there's a way to give an already constructed object to the deserialize method (in which case the serializer would just skip the object construction phase and begin mapping properties).

My use case is simple:
In a REST API, I want to allow a user to create or update objects. Each type of operation (create, update, delete, read) has a different set of security rules. However, with the current implementation of the deserializer (in which we are using the Doctrine object constructor), the user can issue a create request, but specify an "id" as part of the payload. The Doctrine object constructor will then return a mapped entity before deserialization begins, allowing the end user to perform an update (while the server still thinks it's doing a create).

Also, on this point:
I was considering making a separate object constructor - but I need to give some attributes to the object constructor on each use (such as the ID which it should construct an object for). Right now, the only way to get those attributes to the deserializer is to include them in the payload string that gets passed to it - which is precisely what I'd like to avoid.

There are ways to handle this in the actual REST endpoint, but none of them are really ideal.What I'd like to be able to do is pass an already-constructed object (which my REST endpoint will handle fetching) to the deserializer and just have it do it's property mapping onto the object. This way, I can always pass a blank object in create calls, while I can pass a constructed object in update calls.

Would this be possible? I could submit a PR if this is something you'd be willing to implement.

According to http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx it is possible to attack a json response by transforming it into jsonp.

Adding a prefix like suggested in http://docs.angularjs.org/api/ng.$http (JSON Vulnerability Protection).

I did it in my fork 3d73cf6 in the class serializer, but maybe it would be good to do it in the JsonSerializationVisitor.

For reference: schmittjoh/JMSSerializerBundle#272

I do not know which repository is most appropriate to open these issues on.

For reference: schmittjoh/JMSSerializerBundle#271

Again, I am not sure which repository is most appropriate to open this issue against.

Hi all,

I am trying to serialize a Foo object with an embedded list of Bar objects to something like:

<foo>
    <bars>
        <bar display="1" name="baz"/>
        <bar display="0" name="zab"/>
        <bar display="1" name="azb"/>
        <bar display="1" name="bza"/>
    </bars>
</foo>

As you can imagine, I am trying to skip the second element. I have tried to implement that adding a HandlerCallback to the Bar object, but I can't figure out what to do with the $visitor to prevent him serializing the object.

Any thoughts ?

Thanks in advance,

Cheers,

A.

Hi Johannes,

Could you please tag a version? It's quite annoying to require @dev packages...

Thank you,
William

Example:

$coll = $serializer->deserialize('["foo", "bar"]', 'ArrayCollection', 'json');
var_dump($coll);

Expected:

object(Doctrine\Common\Collections\ArrayCollection)[123]
  private '_elements' => 
    array
      0 => string 'foo' (length=3)
      1 => string 'bar' (length=3)

Got:

array
  0 => string 'foo' (length=3)
  1 => string 'bar' (length=3)

Moved from SerializerBundle to here: schmittjoh/JMSSerializerBundle#255

To be able to work with Knockout.js I require the keys of empty values to be preserved.
I thought this was added to a previous version of JMSSerializerBundle / Serializer but in the current version I can't find anything to make sure it also serializes null values.

Any suggestions?

(note: not sure if this should be posted in JMSSerializeBundle or here)

Is there a way to have the serializer throw exceptions on bad input? Was this considered and not done for any particular reason?

Imagine you are accepting input in a REST api. You use the serializer to deserialize the input from the client, and then you use a validator to validate the model before persisting it.

In this scenario (which I think is fairly common), you lose bad input - for example the client setting a field that does not exist, or a read only field. The operation works fine, the client can't corrupt the data, but since the serializer swallows the bad input, you also cannot really warn the client that they are misusing the API.

Am I just doing it wrong? :) Is there a better workflow for handling this scenario?

EDIT: If this is possible to implement in the serializer, what's the best way to go about it? A custom ExclusionPolicy?

XmlDeserializationVisitor::visitProperty uses reflection to set properties unless none of xmlAttribute, xmlValue, xmlCollection are set. For any remaining properties, reflection will only be used if metadata->setter is null. The latter logic seems more desirable for all cases.

This is presumably a bug? I can't see any reason the following configuration should not be using setItems when deserializing from XML:

class Order {
    /**
     * @Type("ArrayCollection<Item>")
     * @XmlList(entry = "item", inline = true)
     * @AccessType("public_method")
     */
    private $items;

    public function setItems($items){
        $this->items = $items;
        //Do something else
    }
}

I ran into this when attempting to make sure my Items were aware of my Orders, as Item was the owner of a Doctrine association.

Hi,

First, I'd like to thank you for the great library.

Using it I stumbled on a situation which caused unexpected result.
Every time when you set the version (Context::setVersion) or the groups (Context::setGroups) of the context, the context adds new VersionExclusionStrategy and GroupsExclusionStrategy respectively. As result changing the version or the groups will correctly update the attributes version and groups, but it will also add new exclusion strategies with the new value(s) without removing the obsolete exclusion strategies. In my opinion this is unexpected and the context should either remove the old exclusion strategies or not attempt to update the DisjunctExclusionStrategy (here and here).

Cheers!

Does this issue belongs here???

FriendsOfSymfony/FOSRestBundle#447

I noticed metadata caches on the fly. Is there any clever way of caching all via command / function call?

This probably belongs in the metadata library, but since serializer is used more commonly, I'd like to flag this here. We are going to start using the serializer in a high traffic application, and don't want to run across any caching issues. I'd rather like to run a command before symlinking a directory in production ensuring all metadatas are cached.

If this doesn't belong here, then what's the best way to achieve this without running serialize() or getMetadataForClass () on every model before going live.

This also pertains to schmittjoh/metadata#19

The serialized_name attribute does not work at "properties" section, but works inside "virtual_properties" section

It'd be great if some documentation was added about the virtual properties. I've needed to search in the tests (ObjectWithVirtualProperties.yml) in order to know how to do it.

Hi,

I need to add a namespace at the root level of an object but it seem's no annotations are providing the way to do this. I saw the PR 58 wich seem's to add this cool and nice feature.

Any chances to get this PR merged ?

Thx by advance

I have a following quite complex array with parent objects and child objects, let's say User and Avatar. Both are, however, very simple objects (not Doctrine Entities or anything)

- user1
    - avatar1
    - avatar2
- user2
    - avatar1
    - ...
    - avatarN
- ...

When I serialize this multi-dimensional array normally without using groups everything works just fine.

BUT: Let's say I try to limit the serialized output of every User object by creating a serialization group because I don't want all the fields of the User exposed. Everything works ok until I include the field avatars (array of Avatar instances) in the exposed fields group. If I do that I'm greeted with this error: Warning: json_encode() [<a href='function.json-encode'>function.json-encode</a>]: recursion detected in .../vendor/jms/serializer/src/JMS/Serializer/JsonSerializationVisitor.php line 29

The funny thing really is, it works great for the whole array. Problems only occur when I try to limit the output using groups feature.

My User object's serialization config looks like this:

My\FoobarBundle\Model\User:
    exclusion_policy: none
    properties:
        name:
            groups: [query]
        avatars:
            groups: [query]

Or is this just some missing configuration I'm not familiar to?

This has been discussed in schmittjoh/JMSSerializerBundle#140, but it mainly belongs here now.

My personal use case for multiple exclusion strategies: I'd like to use Groups with the proposed DepthExclusion strategy (#4). Restrict the properties that are serialized, and restrict the depth to which some properties are serialized. I need both for that. Strategies really complement each other; the same is true for e.g. groups and version.

The issue mainly dealed with three changes:

1. Adding a serializer builder service that separates the new settings for each invocation => Builder exists
2. The option to configure specific serializers in the config files => would go to SerializerBundle
3. Changes to Groups => Default Groups are there, I think that was it
4. A new option to have a chain of exclusion strategies instead of a single one

Is there still demand for this?
Looks like the builder doesn't have support for setting (multiple) exclusion strategies yet. So it looks like we'd need to do that and 4.). Or has this been accomplished some other way?

Hi, Quite often I see the need to deserialize objects where the object is only defined by it's id.

For example:

class User {

/* @var Customer */
protected $customer; 

}

here I do not want to pass customer back and forth for deserialization, but I want to be able to keep the refrence when I update the user object.

Would it be possible to have an annotation for defining that this object should be deserialized to an entity?

I have a property "foo" which is a referenced doctrine document. I basically want to serialize it as:

{
   "foo_id": 1
}

Internally, the serializer sees that the object is a doctrine proxy object then changes it's type to the document class. Normally, I'd create my own handler here to just call, $foo->getId() and make that the value with configuration of:

<property name="foo" type="DoctrineIdentifier" serialized-name="foo_id" />

However, because the doctrine proxy event converts the type to the class name first, it never hits the handler.

Any current ways around this before I start digging into the code?

Utilizing the PropertyPath component may be cool?

<property name="foo.id" type="string" />

would output:

{ "foo_id": 1 }

Another example

<property name="posts[0].id" type="string" />
<property name="friends[0].best_friend.name" type="string" serialized-name="my_first_friends_bff" />

would output:

{
    "posts_0_id": 1,
    "my_first_friends_bff": "Johannes"
}

Etc, etc. I feel like I create a lot of handlers for doing stuff like this and it'd be cool to easily put something via property path in the root!

Anyway, two questions:

1. How can I achieve this now?
2. Does the PropertyPath component fit into the serializer?

If an object of a class, which has a serialization handler attached for it, is serialized, the value results in NULL.

GraphNavigator::accept returns the value created by the handler, but the value is never added to the visitor. Serializer::serialize returns the result of the visitor by returning $visitor->getResult(). The visitor does not contain the value of the serialization handler, because it is never set to it, so the serialization result is NULL, instead of the generated value.

Consider this:
Let's say there is an abstract class "A" and some her subclasses ("B", "C", "D").
There is another class "Test" with property "myA" could be any of "A" subclasses.

Aim: deserialize members "Test" class with valid type of myA property

Solution 1: possibility set "discriminatorProperty" and subclassesMap for Test->myA property way like that:

  Test:
    myA:
      discriminatorProperty: disc
      type: {"b": "B", "c" : "C", "d": "D"}

It can be very useful to deserialize Doctrine Entities with Inheritance. Note: discrimitatorProperty cannot be member of "A" class.

We can consider ArrayCollection<{"b": "B", "c" : "C", "d": "D"}> notation (deserialize mulit type ArrayCollection)

Solution 2:
Create deserialization type resolvers and registered them in serializer.
Something like that:

interface TypeResolver {
  /**
   * Returns valid deserialization type
   * @return string
   */
  public function resolveType($arData, $class, $property);
}

Registering resolvers manual or by tagging services in bundle.

What do you think about my idea?

When using control characters like "!" in the format strings of DateTime-properties, this works just fine for deserialization, but does not for serialization. This is of course an issue with PHP's APIs and the incompatibility of format strings accepted by DateTime::format($format) and the ones accepted by DateTime::createFromFormat($format, $time). However, when using it with the serializer, this becomes an issue because there is (afaik) no way to define a separate deserialization type for a property.

Example:
Deserializing the value "2013-05-18" with type DateTime<'!Y-m-d'>, results in the following object:

DateTime Object
(
    [date] => 2013-05-18 00:00:00
    [timezone_type] => 3
    [timezone] => UTC
)

When serializing this object using the exact same type definition, this results in the string "!2013-05-18" (with the "!" as part of the result string, which is of course logical, but not intended).

Do you think, that there is a good way to circumvent this issue? If we can find one, I'd be happy to contribute by submitting a PR for it.

I am curious if it is currently possible to define which xml element is the root for deserialization. In this example

<emptyroot>
    <notempty id="5">
        <more>
        </more>
    </notempty>
</emptyroot>

I would like to skip <emptyroot> and take <notempty> as the base.

I'm using event subscribers to add additional data post-serialize. I'd like to only add certain properties if a particular exclusion strategy group is active, but can't see a way to access that information from within the callback. Assuming I haven't missed something, would it be possible to add this functionality, perhaps by making it available from the event? I'd make a PR if so.

I'm trying to use the serializer in an external project with entities from a symfony project, but my entities have doctrine orm mappings on them so i tried to use AnnotationReader::addGlobalIgnoredName to ignore them. For some reason when I call $serializer->serialize() the names I set to ignore are not set in Doctrine's DocParser.php.

AnnotationReader::addGlobalIgnoredName('ORM\\MappedSuperclass');
$serializer = JMS\Serializer\SerializerBuilder::create()->build();
$artist = new Artist();
$artist->setName('Test artist');
$jsonContent = $serializer->serialize($artist, 'json'); // ORM\\MappedSuperclass not found

If I var_dump $this->ignoredAnnotationNames in DocParser::Annotation() it seems to get hit twice, but the first time the array is empty.

while upgrading to the refactored SerializerBundle => Serializer, i noticed that before it was working to serialize a plain array. now i get an exception about array not being an object in NavigatorContext.php::isVisiting

i did not have time to investiage in detail and using doctrine ArrayCollection instead made the error go away, but i wonder if this is a mistake or on purpose.

Hi there,

do you have any plans when to tag the next version?

Updating dependencies (including require-dev)

• Installing jms/metadata (1.3.0)
  Loading from cache
• Installing jms/cg (1.0.0)
  Loading from cache
• Installing jms/aop-bundle (1.0.0)
  Loading from cache
• Installing jms/di-extra-bundle (1.3.0)
  Loading from cache
• Installing jms/parser-lib (1.0.0)
  Loading from cache
• Installing jms/security-extra-bundle (1.4.0)
  Loading from cache
• Installing jms/serializer-bundle (0.11.0)
  Loading from cache

Generating autoload files

[ReflectionException]
Class JMS\Serializer\EventDispatcher\Subscriber\DoctrineProxySubscriber doe
s not exist

o_0

Did an update yesterday and it was fine. Any commits past 24hours?

<?php

class Thing
{
    /**
     * @JMS\Type("integer")
     */
    private $fooBar;

    public function getFooBar()
    {
        return $this->fooBar;
    }
}

$json = '{"fooBar": 123}';
$deserializedThing = $serializer->deserialize($json, 'Thing', 'json');

assert(123, $deserializedThing->getFooBar()); 
// FAILS, we get null instead
// Adding @JMS\SerializedName("fooBar") resolves the issue
// Internally, the serializer converts fooBar to foo_bar unless instructed otherwise

This behavior is documented under @SerializedName http://jmsyst.com/libs/serializer/master/reference/annotations

However, this is so counterintuitive, that I think it is a bug. In the example above, there's absolutely no reason why the serializer should interfere with my naming, since both the json and the php code use camelcase.

Hi, in the entity I've this code:

/**
 * @var \DateTime $gamedatetime
 *
 * @ORM\Column(name="gameDateTime", type="datetime", nullable=false)
 * @SerializationGroups({"api.mobile.match.list.generic"})
 * @Accessor(getter="getGameDateTimestamp")
 * @Assert\NotBlank()
 */
private $gameDateTime;


public function getGameDateTimestamp()
{
    return $this->gameDateTime->getTimestamp();
}

I'm running f95ba2 commit and it seems the accessor doesn't make any difference, setting a wrong function gives no errors, tried to add a die() inside and never get called..

Hello,

I'm using the dev-master version of the bundle and now trying to set 'html' as format doesn't throw the usual UnsupportedFormatException but gives "None has no value"

Maybe i've something wrong in the config?

Old serializer.php had

/**
 * @return VisitorInterface
 */
public function getDeserializationVisitor($format)
{
    if (!isset($this->deserializationVisitors[$format])) {
        throw new UnsupportedFormatException(sprintf('Unsupported format "%s".', $format));
    }

    return $this->deserializationVisitors[$format];
}

/**
 * @return VisitorInterface
 */
public function getSerializationVisitor($format)
{
    if (!isset($this->serializationVisitors[$format])) {
        throw new UnsupportedFormatException(sprintf('Unsupported format "%s".', $format));
    }

    return $this->serializationVisitors[$format];
}

It could be useful to replace the element to be serialized in the post-serialization event as the docs says: "You can for example use this to add additional data to an object that you normally do not save inside objects such as links"

Trying to change the object fields in the post_serialization event doesn't makes any change in the resultant serialized object.

Edit: I've seen that in the pre-serialization event the object is changed, so it should be useful to improve the docs about that

Bull kittens

To reproduce:

$serializer->serialize(array((object) array()), 'json');

The error:

json_encode(): recursion detected

Hi,

I'm trying to access to the serializing group in a subscriber but I can't find any way to do it.
The "exclusionStrategy" attribute in the GraphNavigator class is private and no getter function is available to access it.

Do you know if there is any other way to get the group ?
If not, do you think I can add a "getExclusionStrategy" method in the GraphNavigator and send you a PR ?

Thanks

@schmittjoh What do you think about adding more formats like BSON, protocol buffer or thrift?

it would be nice to somehow specify in the context that f.e. a group exclusion strategy should only be applied to a specific class and not the entire object graph.

Is that feature of any interest? I want to have full control of what is going to be serialized.

Hi I'm using the HandlerCallback like this

class AbstractProduct implements ProductInterface
{

   /**
     * @Serializer\HandlerCallback("xml", direction="serialization")
     */
    public function serialize2Xml(XmlSerializationVisitor $visitor, $value)
    {
      ...
    }
}

The first time, it run's like expected. But all in all other Runs it ignore's the custom handler callback.
If I touch the File, it run's okay for one time...

If I'm trying to use @Accessor(getter="getName") on Doctrine Entrity with type @Orm\ManyToOne works fine with version 0.9.0 but in ne version causes LogicException that is string not object.
Also namespace was changed from JMS\SerializerBundle\Annotation to JMS\Serializer\Annotation - why this is not compatible ?