Re: Help - Error trying to run Jakarta Rest RSVP example from jakarta ee tutorial.

--000000000000ca3f570653b7703a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Best regards to all.
I continued working on the example and managed to get it working using
one of the two
methods. This was using Named Queries, whereas using NamedEntityGraph
still gives me
errors.


=C2=ABNamed Queries=C2=BB

To make it work with Named Queries, I created two queries in the form
=E2=80=98SELECT DISTINCT ... JOIN FETCH ...=E2=80=99. The first query joine=
d one of the entity=E2=80=99s
one-to-many relationships, and the other joined the next one-to-many
relationship. Both
results were stored in the same list.
Furthermore, I had to configure the entity enhancement at build time.
This is because
when I tried to use enhancement at deployment time with the property
=E2=80=98openejb.jpa.deploy-time-enhancement=3Dtrue=E2=80=99, I received th=
e following error when
attempting to enhance the entities:
    WARNING [main]
org.apache.openejb.assembler.classic.DeployTimeEnhancer.enhance cannot
enhance entities at deployment time
        java.lang.reflect.InvocationTargetException ...
    Caused by: java.lang.IllegalArgumentException ...
And the entity causing the error has changed as I=E2=80=99ve been working o=
n
the example.
What confuses me is that I get an error when trying to enhance the
entity at deployment
time, but not at build time. What=E2=80=99s more, if I don=E2=80=99t enhanc=
e the
entity at build time,
I get the previous error:
    org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemExce=
ption
EjbTransactionUtil.handleSystemException:
    Cannot invoke
=E2=80=98org.apache.openjpa.jdbc.meta.ClassMapping.getFieldMappings()=E2=80=
=99 because
=E2=80=98cm=E2=80=99 is null
when trying to test the example.

I have included the log from the working example. Here, you can also
see the error that
occurs when attempting to enhance the entities at deployment time
because the property
=E2=80=98openejb.jpa.deploy-time-enhancement=3Dtrue=E2=80=99 is enabled.
The log is called rsvp-working-openjpa-join-buildEnhancement


=C2=ABNamedEntityGraph=C2=BB

When I try to use NamedEntityGraph, I keep getting the same error. It
says that the
operation is not supported by JPA 2.1. This is odd, as according to
the OpenJPA website,
version 4.1.1 included in Tomee 10 is a JPA 3.1 implementation. The
error is as follows:
    org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemExce=
ption
Ejb>
        java.lang.UnsupportedOperationException: JPA 2.1
            at org.apache.openjpa.persistence.EntityManagerImpl.getEntityGr=
aph(EntityManagerImpl.java:2126)
            ...
I have included the rest of the log in the file
rsvp-error-openjpa-entity-graph-enh-ann


You can find the updated example in the fork I created of the original
project on my GitHub:
https://github.com/Sxtormulo/jakartaee-examples/tree/main/tutorial/jaxrs/rs=
vp.

The example currently works correctly with named queries, as the POM
uses tomee-maven-plugin
and the OpenJPA plugin to enhance entities at build time.
However, if you wish to reproduce the error with NamedEntityGraph, you
can replace the
file /src/main/java/jakarta/tutorial/rsvp/ejb/StatusBean.java with the
StatusBean.java
file that I will include in this email.

Thank you all for your attention. And many thanks to Richard for his
help, which enabled
me to work through the example to this point.
Best regards, Gabriel.


El dom, 24 may 2026 a la(s) 1:08=E2=80=AFa.m., Gabriel Alejandro Soto River=
a
([email protected]) escribi=C3=B3:
>
> Kind regards.
>
> Thank you very much for your detailed reply. Your explanation of the prob=
lem helped me
> start looking in the right places. To add, having looked at the example m=
ore closely, I
> realise you=E2=80=99re right =E2=80=93 the code is a bit sloppy. Once I=
=E2=80=99ve sorted this issue out, I=E2=80=99ll
> try to suggest some improvements via a pull request.
>
> Firstly, I made the specified changes. The example ran successfully, but =
the relevant
> part of the website stopped working. This is because =E2=80=98EventManage=
r.java=E2=80=99 needs to
> retrieve the data declared as transient in the XML.
>
> So, I left the change to =E2=80=98pom.xml=E2=80=99 to continue using the =
tomee-maven-plugin but removed
> the @XmlTransient tags.
>
> Whilst searching for more information with the cause of the problem in mi=
nd, I came across
> this blog https://thorben-janssen.com/lazyinitializationexception/ which =
helped me find
> two solutions to the problem.
>
> One option is to use =E2=80=98LEFT JOIN FETCH=E2=80=99 to tell JPA that I=
 need to load not only the
> entity, but also the entities related to it. The other is to use @NamedEn=
tityGraph to
> specify the relationships with their properties and likewise load the dep=
endent entities.
>
> Neither option worked, and the following errors were encountered:
> The option with =E2=80=98LEFT JOIN FETCH=E2=80=99 gave me the error:
>  org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemExcep=
tion EjbTransactionUtil.handleSystemException: Cannot invoke =E2=80=98org.a=
pache.openjpa.jdbc.meta.ClassMapping.getFieldMappings()=E2=80=99
> because =E2=80=98cm=E2=80=99 is null
> <openjpa-4.1.1-r9d2f5f8 nonfatal general error> org.apache.openjpa.persis=
tence.PersistenceException:
> Cannot invoke =E2=80=98org.apache.openjpa.jdbc.meta.ClassMapping.getField=
Mappings()=E2=80=99 because =E2=80=98cm=E2=80=99 is null
>
> And the second option with @NamedEntityGraph gave me the following error:
> org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemExcept=
ion EjbTransactionUtil.handleSystemException: JPA 2.1
>     java.lang.UnsupportedOperationException: JPA 2.1
>
> So I tried changing the persistence provider in the tomee-maven-plugin fr=
om OpenJPA to
> Hibernate. This made both options run successfully.
>
> Is there a problem with OpenJPA causing it not to work correctly?
>
> As before, I have attached the new errors encountered, which are:
> * rsvp-error-with-openjpa-entity-graph, relating to running the example u=
sing
>   @NamedEntityGraph.
> * rsvp-error-with-openjpa-join-fetch: relating to the use of =E2=80=98LEF=
T JOIN FETCH=E2=80=99
>
> You can also find the changes I made to the example on my GitHub:
> https://github.com/Sxtormulo/jakartaee-examples/tree/main/tutorial/jaxrs/=
rsvp.
> In the =E2=80=98StatusBean.java=E2=80=99 class, within the =E2=80=98getAl=
lCurrentEvents=E2=80=99 method, I have commented
> out the code to allow you to switch between the options and test both.
>
> Thank you very much for your help. Finally, I have a question unrelated t=
o the problem:
> what is the difference between the Tomee Maven plugin and the Tomee Embed=
ded Maven plugin?
>
>
>
> El mar, 19 may 2026 a la(s) 12:45=E2=80=AFp.m., Richard Zowalla (rzo1@apa=
che.org) escribi=C3=B3:
>>
>> Hi,
>>
>> thanks for the detailed report and for taking the time to attach both lo=
g
>> variants, that made it possible to reproduce locally on the first try.
>>
>> Short answer: this is not a bug in your code or in the tutorial sources.
>>
>> You have hit a known interaction between OpenJPA's lazy-load behaviour a=
nd
>> JAX-RS (CXF) marshalling that runs *after* the EJB transaction has
>> finished. GlassFish + EclipseLink masks the same code's problem because
>> EclipseLink is more permissive about touching detached/closed-context
>> proxies.
>>
>> I reproduced this with apache-tomee-plus-10.1.5 on Temurin 17 using the
>> exact module you linked. Below is a complete breakdown plus a patch you
>> can apply to your fork. The diff is also attached as rsvp-fix.patch.
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>> 1) Why /status/all returns 500 in the "no openjpa trace" log
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>>
>> The relevant lines in your no-trace log are:
>>
>> WARNING ... org.apache.cxf.jaxrs.provider.JAXBElementProvider.writeTo
>> <openjpa-4.1.1 fatal user error>
>> org.apache.openjpa.util.InvalidStateException: The context has been
>> closed. ...
>> SEVERE ... Problem with writing the data, class
>> org.apache.openjpa.kernel.DelegatingResultList, ContentType: application=
/xml
>>
>> What is actually happening, step by step:
>>
>> a) StatusBean#getAllCurrentEvents() executes
>> em.createNamedQuery(...).getResultList()
>> OpenJPA returns an *org.apache.openjpa.kernel.DelegatingResultList*.
>> This is a lazy wrapper, iit does not fully materialise the rows.
>> b) The @Stateless method returns. The container-managed JTA transaction
>> commits, and the JPA persistence context is closed.
>> c) Only *now* does CXF's JAXBElementProvider start iterating the list to
>> marshal it to XML. While iterating, the DelegatingResultList tries to
>> pull the next row from the underlying broker, finds the broker is
>> closed, and throws InvalidStateException("The context has been
>> closed"). CXF maps that to HTTP 500.
>>
>> The same pattern bites again one level deeper: JAXB walks the Event
>> fields (you have @XmlAccessorType(XmlAccessType.FIELD)) and encounters
>> two LAZY relations:
>>
>> - @OneToMany(mappedBy =3D "event") List<Response> responses
>> - @ManyToMany List<Person> invitees
>>
>> By spec these default to FetchType.LAZY. They are still unresolved when =
the persistence context closes,
>> so attempting to read them during marshalling fails for exactly the same
>> reason.
>>
>> To answer the question you raised: yes, @ManyToOne defaults to
>> FetchType.EAGER, and OpenJPA does honour that. I verified
>> it by leaving Event.owner without @XmlTransient in the fix below; owner
>> serialises correctly into the response payload, because it was already
>> fully loaded inside the EJB transaction. So the eagerness behaviour you
>> expect is working; only the LAZY-by-default collections needed
>> intervention.
>>
>> The other endpoint, GET /status/{eventId}, works because it returns a
>> single Event fetched with em.find(...), whose scalar fields and EAGER
>> relations (owner) are fully loaded synchronously. Same reason
>> ConfigBean and ResponseBean behave; they do not return lazy result
>> sets.
>>
>> 2) About the "GlassFish works, TomEE doesn't" difference
>>
>> The tutorial code is sloppy (IMHO) in a way that EclipseLink tolerates a=
nd
>> OpenJPA does not. The JPA spec leaves "what happens if you touch a lazy
>> proxy after the persistence context is closed" largely
>> implementation-defined; providers are free to throw. EclipseLink
>> typically lets you read whatever state was already loaded and returns
>> nulls/empties for the rest; OpenJPA is strict and raises
>> InvalidStateException. Both behaviours are within spec; this is *not*
>> "OpenJPA not being JPA-compliant". The tutorial just happens to be
>> written in a way that exercises one of the edges where providers
>> diverge. The right fix is at the application level (see below), not in
>> the provider.
>>
>> 3.) The fix
>>
>> Two minimal application-side changes, no provider workarounds:
>>
>> (a) In StatusBean.getAllCurrentEvents(), wrap the result in a plain
>> ArrayList so the data is materialised inside the EJB transaction:
>>
>> this.allCurrentEvents =3D new ArrayList<>(
>> em.createNamedQuery("rsvp.entity.Event.getAllUpcomingEvents",
>> Event.class).getResultList());
>>
>> After this, CXF marshals a plain java.util.ArrayList instead of an
>> OpenJPA DelegatingResultList. No more "context has been closed" on
>> the outer list.
>>
>> (b) In Event.java, mark the two LAZY collections @XmlTransient:
>>
>> @OneToMany(mappedBy =3D "event")
>> @XmlTransient
>> private List<Response> responses;
>>
>> @ManyToMany
>> @XmlTransient
>> protected List<Person> invitees;
>>
>> These collections are not part of what /status returns
>> anyway (the endpoint reports events, not invitee/response graphs),
>> and excluding them from XML/JSON serialisation means JAXB never
>> tries to walk a LAZY proxy after the persistence context is closed.
>> Event.owner stays as-is, because @ManyToOne is EAGER by default and
>> is already loaded by the time the EJB returns.
>>
>> I have also added the tomee-maven-plugin to rsvp/pom.xml.
>>
>>             <plugin>
>>                 <groupId>org.apache.tomee.maven</groupId>
>>                 <artifactId>tomee-maven-plugin</artifactId>
>>                 <version>10.1.5</version>
>>                 <configuration>
>>                     <tomeeVersion>10.1.5</tomeeVersion>
>>                     <tomeeClassifier>plus</tomeeClassifier>
>>                     <context>rsvp</context>
>>                 </configuration>
>>             </plugin>
>>
>> That makes it trivial to reproduce / regression-test the example locally=
:
>>
>> mvn package
>> mvn tomee:run
>>
>> and then GET http://localhost:8080/rsvp/webapi/status/all .
>>
>> Hope this helps - and good luck with the rest of the tutorial!
>>
>> Gru=C3=9F
>> Richard
>>
>>
>>
>>
>> > Am 17.05.2026 um 03:53 schrieb Gabriel Alejandro Soto Rivera <gabriel.=
[email protected]>:
>> >
>> > Warm regards to everyone, and thank you very much in advance.
>> >
>> > I=E2=80=99m just starting to learn Jakarta EE and Tomee, so I=E2=80=99=
m not sure if this is the right
>> > place to ask for help with my problem. But I think it is, because it=
=E2=80=99s related to Tomee.
>> >
>> > I=E2=80=99m learning about Jakarta EE using the tutorial on their webs=
ite:
>> > Jakarta EE Tutorial I=E2=80=99ve just modified the POMs so that they d=
on=E2=80=99t use GlassFish
>> >  by default, but instead run on the Tomee server I=E2=80=99ve installe=
d locally; and change the
>> > persistence.xml to not use eclipse as persistence provider. And, so fa=
r, the examples
>> > have been working correctly.
>> >
>> > I am using Tomee 10.0.5 with their default configurations, only and a =
user in tomcat-users
>> > to access to the html manager. Then, to test if is the example that is=
 not working or is Tomee
>> > I installed GlassFish 7 and the example works well. But I want to make=
 it work with Tomee.
>> >
>> > But I got stuck on the example in =E2=80=98Building RESTful Web Servic=
es with Jakarta REST=E2=80=99
>> > The rsvp Example Application. Making some testing I discover that the =
endpoints of
>> > ResponseBean.java works well; and ConfigBean.java make their job. But =
the problem
>> > comes from executing the endpoints of StatusBean.java
>> > However, when trying to debug, I get confusing logs depending on the c=
onfiguration.
>> > With the default configuration, the log indicates issues related to
>> > =E2=80=98org.apach.cxf.jaxrs.provider.JAXBElementProvider=E2=80=99.
>> > However, when adding
>> > <property name=3D"openjpa.Log" value=3D"DefaultLevel=3DTRACE, Runtime=
=3DTRACE, Tool=3DTRACE"/>
>> > to persistence.xml as the log suggests to obtain more information, the=
 application fails
>> > to deploy. It throws errors relating to
>> >  =E2=80=98jdk.internal.reflect.NativeMethodAccessorIpml.invoke=E2=80=
=99.
>> > I have the tutorial code with the changes that i make to work with Tom=
ee in my github:
>> > https://github.com/Sxtormulo/jakartaee-examples/tree/main/tutorial/jax=
rs/rsvp.
>> > These are the errors I get when I try to run the example with and with=
out the openjpa.Log Trace
>> > property in persistence.xml.
>> > As I=E2=80=99m new to this, I=E2=80=99m not sure if it=E2=80=99s a con=
figuration error, an app error or a bug.
>> > If it is a bug, I=E2=80=99ll open an issue on GitHub to report it.
>> > Thank you very much in advance for your help.
>>

--000000000000ca3f570653b7703a
Content-Type: text/x-java; charset="US-ASCII"; name="StatusBean.java"
Content-Disposition: attachment; filename="StatusBean.java"
Content-Transfer-Encoding: base64
Content-ID: <f_mq4s5ujg2>
X-Attachment-Id: f_mq4s5ujg2

LyoKICogQ29weXJpZ2h0IChjKSwgRWNsaXBzZSBGb3VuZGF0aW9uLCBJbmMuIGFuZCBpdHMgbGlj
ZW5zb3JzLgogKgogKiBBbGwgcmlnaHRzIHJlc2VydmVkLgogKgogKiBUaGlzIHByb2dyYW0gYW5k
IHRoZSBhY2NvbXBhbnlpbmcgbWF0ZXJpYWxzIGFyZSBtYWRlIGF2YWlsYWJsZSB1bmRlciB0aGUK
ICogdGVybXMgb2YgdGhlIEVjbGlwc2UgRGlzdHJpYnV0aW9uIExpY2Vuc2UgdjEuMCwgd2hpY2gg
aXMgYXZhaWxhYmxlIGF0CiAqIGh0dHBzOi8vd3d3LmVjbGlwc2Uub3JnL29yZy9kb2N1bWVudHMv
ZWRsLXYxMC5waHAKICoKICogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEJTRC0zLUNsYXVzZQog
Ki8KcGFja2FnZSBqYWthcnRhLnR1dG9yaWFsLnJzdnAuZWpiOwoKaW1wb3J0IGphdmEudXRpbC5M
aXN0OwppbXBvcnQgamF2YS51dGlsLmxvZ2dpbmcuTG9nZ2VyOwoKaW1wb3J0IGpha2FydGEuZWpi
LlN0YXRlbGVzczsKaW1wb3J0IGpha2FydGEuaW5qZWN0Lk5hbWVkOwppbXBvcnQgamFrYXJ0YS5w
ZXJzaXN0ZW5jZS5FbnRpdHlHcmFwaDsKaW1wb3J0IGpha2FydGEucGVyc2lzdGVuY2UuRW50aXR5
TWFuYWdlcjsKaW1wb3J0IGpha2FydGEucGVyc2lzdGVuY2UuUGVyc2lzdGVuY2VDb250ZXh0Owpp
bXBvcnQgamFrYXJ0YS5wZXJzaXN0ZW5jZS5UeXBlZFF1ZXJ5OwppbXBvcnQgamFrYXJ0YS50dXRv
cmlhbC5yc3ZwLmVudGl0eS5FdmVudDsKaW1wb3J0IGpha2FydGEud3MucnMuR0VUOwppbXBvcnQg
amFrYXJ0YS53cy5ycy5QYXRoOwppbXBvcnQgamFrYXJ0YS53cy5ycy5QYXRoUGFyYW07CmltcG9y
dCBqYWthcnRhLndzLnJzLlByb2R1Y2VzOwppbXBvcnQgamFrYXJ0YS53cy5ycy5jb3JlLk1lZGlh
VHlwZTsKaW1wb3J0IGphdmEudXRpbC5IYXNoTWFwOwppbXBvcnQgamF2YS51dGlsLk1hcDsKCi8q
KgogKgogKiBAYXV0aG9yIGlldmFucwogKi8KQFN0YXRlbGVzcwpATmFtZWQKQFBhdGgoIi9zdGF0
dXMiKQpwdWJsaWMgY2xhc3MgU3RhdHVzQmVhbgp7CgogICAgcHJpdmF0ZSBMaXN0PEV2ZW50PiBh
bGxDdXJyZW50RXZlbnRzOwogICAgcHJpdmF0ZSBzdGF0aWMgZmluYWwgTG9nZ2VyIGxvZ2dlciA9
IExvZ2dlci5nZXRMb2dnZXIoCiAgICAgICAgImpha2FydGEudHV0b3JpYWwucnN2cC5lamIuU3Rh
dHVzQmVhbiIpOwoKICAgIEBQZXJzaXN0ZW5jZUNvbnRleHQKICAgIHByaXZhdGUgRW50aXR5TWFu
YWdlciBlbTsKCiAgICBAR0VUCiAgICBAUHJvZHVjZXMoe01lZGlhVHlwZS5BUFBMSUNBVElPTl9Y
TUwsIE1lZGlhVHlwZS5BUFBMSUNBVElPTl9KU09OfSkKICAgIEBQYXRoKCJ7ZXZlbnRJZH0vIikK
ICAgIHB1YmxpYyBFdmVudCBnZXRFdmVudChAUGF0aFBhcmFtKCJldmVudElkIikgTG9uZyBldmVu
dElkKQogICAgewogICAgICAgIGZpbmFsIEVudGl0eUdyYXBoPD8+IGVudGl0eUdyYXBoID0gZW0u
Z2V0RW50aXR5R3JhcGgoImdyYXBoLkV2ZW50cyIpOwogICAgICAgIGZpbmFsIE1hcCBoaW50cyA9
IG5ldyBIYXNoTWFwKCk7CiAgICAgICAgaGludHMucHV0KCJqYWthcnRhLnBlcnNpc3RlbmNlLmZl
dGNoZ3JhcGgiLCBlbnRpdHlHcmFwaCk7CiAgICAgICAgcmV0dXJuIGVtLmZpbmQoRXZlbnQuY2xh
c3MsIGV2ZW50SWQsIGhpbnRzKTsKICAgIH0KCiAgICBAR0VUCiAgICBAUHJvZHVjZXMoe01lZGlh
VHlwZS5BUFBMSUNBVElPTl9YTUwsIE1lZGlhVHlwZS5BUFBMSUNBVElPTl9KU09OfSkKICAgIEBQ
YXRoKCJhbGwiKQogICAgcHVibGljIExpc3Q8RXZlbnQ+IGdldEFsbEN1cnJlbnRFdmVudHMoKQog
ICAgewogICAgICAgIGxvZ2dlci5pbmZvKCJDYWxsaW5nIGdldEFsbEN1cnJlbnRFdmVudHMiKTsK
ICAgICAgICAvL1Byb2JsZW0gc29sdmVkIHVzaW5nIG5hbWVkIGVudGl0eSBncmFwaHMKCiAgICAg
ICAgZmluYWwgRW50aXR5R3JhcGg8Pz4gZW50aXR5R3JhcGggPSBlbS5nZXRFbnRpdHlHcmFwaCgi
Z3JhcGguRXZlbnRzIik7CiAgICAgICAgZmluYWwgVHlwZWRRdWVyeTxFdmVudD4gZXZlbnRRdWVy
eSA9CiAgICAgICAgICAgIGVtLmNyZWF0ZVF1ZXJ5KCJTRUxFQ1QgZSBGUk9NIEV2ZW50IGUiLCBF
dmVudC5jbGFzcykuc2V0SGludCgKICAgICAgICAgICAgICAgICJqYWthcnRhLnBlcnNpc3RlbmNl
LmZldGNoZ3JhcGgiLAogICAgICAgICAgICAgICAgZW50aXR5R3JhcGgpOwogICAgICAgIGFsbEN1
cnJlbnRFdmVudHMgPSBldmVudFF1ZXJ5LmdldFJlc3VsdExpc3QoKTsKCiAgICAgICAgaWYoYWxs
Q3VycmVudEV2ZW50cyA9PSBudWxsKSB7CiAgICAgICAgICAgIGxvZ2dlci53YXJuaW5nKCJObyBj
dXJyZW50IGV2ZW50cyEiKTsKICAgICAgICB9CiAgICAgICAgcmV0dXJuIGFsbEN1cnJlbnRFdmVu
dHM7CiAgICB9CgogICAgcHVibGljIHZvaWQgc2V0QWxsQ3VycmVudEV2ZW50cyhMaXN0PEV2ZW50
PiBldmVudHMpCiAgICB7CiAgICAgICAgYWxsQ3VycmVudEV2ZW50cyA9IGV2ZW50czsKICAgIH0K
fQo=
--000000000000ca3f570653b7703a--