The PersistenceManagerFactory in SVN is desperately in need of the following
adding to it ;-)
/**
* Adds the listener instance to the list of lifecycle event
* listeners. The codeclasses/code parameter identifies all
* of the classes of interest. If the codeclasses/code
*
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/jdo/tck/pc/fieldtypes/SimpleInterface
So it cant find the class SimpleInterface ?
extension vendor-name=jpox key=implementation-classes
value=org.apache.jdo.tck.pc.fieldtypes.SimpleInterface/
SimpleInterface is an
?xml version=1.0 encoding=UTF-8?
!DOCTYPE jdo PUBLIC -//Sun Microsystems, Inc.//DTD Java Data Objects
Metadata 2.0//EN http://java.sun.com/dtd/jdo_2_0.dtd;
jdo
package name=org.apache.jdo.tck.pc.fieldtypes
class name=SimpleClass identity-type=application
Below is a summary four test errors that are responsible for 90 out of a
total of 115 errors when running the tck on jpox/derby. The fourth one
listed is a test cleanup problem logged as JIRA JDO-48. Could the JPOX
team please take a look at the others?
Craig/Michelle,
Craig wrote:
In the company-derby.orm, the Project is mapped thus:
class name=Project table=projects
field name=projid column=PROJID primary-key=true/
field name=reviewers table=project_reviewer
join column=PROJID/
OK. You'll just have to put it down to not currently supported by JPOX
with that MetaData definition. We support M-N just in a different way.
Do you have an idea of when you might support this? The new metadata
tests I'm working on use the company model and this mapping, so I'm
wondering
Do you have an idea of when you might support this? The new metadata
tests I'm working on use the company model and this mapping, so I'm
wondering if I should bother to temporarily remap them for debugging.
sometime in the next month hopefully. Maybe sooner ...
You can just use the
I've done that, but then JPOX seems to want a primary key in the join
table and supplies it, though there is none in the schema or metadata.
[java] [FATAL] tck - Exception during setUp or runtest:
javax.jdo.JDODataStoreException: Put request failed : INSERT INTO
EMPLOYEE_PHONENO_TYPE
Apparently there is a gap in the spec around specifying the PK for a
join table, so this is a tricky case. We have to find some solution to
that.
Hi Michelle,
JPOX next nightly build (20050528) will only add/require this ADPT_PK_IDX
column if the Map/Set uses a non-PC key and where the
We are getting this error with the checked-in code running a new test.
Could you please take a look?
There is no table EMPLOYEE_PROJECTS in the .orm file, so JPOX must be
imagining it (generating the table name from the class names).
Hi Craig,
it results from you wanting to specify the
Hi Michael,
This is what I have done:
1) Downloaded JPOX plugin for commons-dbcp (jpox-dbcp-1.1.0-beta-3.jar)
2) Downloaded commons-dbcp (commons-dbcp-1.2.1.jar)
3) Downloaded commons-pool (commons-pool-1.2.jar)
4) Downloaded commons-collections (commons-collections-3.1.jar)
5) Added a
Sounds good, thanks. I found that the 6/6 JPOX build ran 10x slower
than the 6/3 build -- 10 hours to run the TCK. I am running the 6/7
build right now, and I'm not sure what the final time will be. At first
it seemed to be running pretty quickly, but now that it's doing the
fieldtypes
Hi Craig,
Thanks, does this mean
org.jpox.autoStartMechanism=None
in the properties file?
It does!
See http://www.jpox.org/docs/1_1/performance_tuning.html
--
Andy
Java Persistent Objects JDO - JPOX
attached you find some changes of the api20 project. It adds method
isDetached to the StateManager interface and add since tags to two PM
methods.
Hi Michael,
when an object is detached it doesn't have a StateManager, hence the
jdoIsDirty() method added to PC instances during enhancement is
when an object is detached it doesn't have a StateManager, hence the
jdoIsDirty() method added to PC instances during enhancement is typically
based on whether it has an objectId and state manager in the instance.
Hence my question is, why do we need this method ?
I did of course mean to say
this is just for JDO implementations that decide to keep the
StateManager for detached instances. The enhancer generated code for
jdoIsDetached needs to check whether there is a StateManager anyway. If
so it should delegate to it, if not it should check for the objectId.
What do you think?
I sent a patch (Assertion-A7-A8.patch) containg the test case
(NewObjectIdInstance.java) to jdo-dev today. I ran it with JPOX build
20050628.022915. This seems to be the latest build available under
nightly builds. I still get the exception (see below).
Please have a look at the test case
This is a configuration file
executing only test cases of class NewObjectIdInstance. You may adapt
the entry jdo.tck.classes as appropriate. Please copy this file to
.../tck20/conf, then execute in tck20:
Yes, but how do I run a single test ?
I'm not interested in running a block of tests,
Hi Michael,
I think, we do not support this case currently. You can run a single
test class, but you cannot run a single test case if the test class has
several test cases like class NewObjectIdInstance.
OK. I consider it a must-have. We used to have runsingle or something. I
see no Maven
I have updated my api20 workspace today and called maven -o rebuild.
The ObjectIdentityTest prints an error (see below). I'm not sure, why I
do not see the error stacktrace.
You mean the failed test ?
This is the error. Looks like some date parsing needs a fix in JDOImplHelper.
Hi Michael,
The test case defines a superclass and a subclass. Both are persistence
capable and both define define persistent fields. Mistakenly, I assigned
all column/field mappings to the subclass in the orm metadata. That's
why the exception is thrown.
If I move the fields in the
I understand that many databases restrict SQL identifiers to a length of
30 characters, though SQL92 specifies a max length of 128 characters.
What is the reason, that JPOX mangels tablenames specified in the orm
metadata?
Something that had been in the codebase from before its JPOX lifetime
I think, mangling of tablenames does only make sense in the case of
forward engineering when the orm metadata and the SQL schema are generated.
Well, we could just throw a StupidUserException, or we could take remedial
action. Not part of the JDO spec so we can do as we please, and we have
I 'just' looked on the nightly download page and it still has not
anything later than June 28. Can you verify that I'm looking in the
right place?
No. You're looking on SourceForge and they kindly changed their systems 2
weeks ago and broke the Maven SourceForge plugin so consequently we
JDO2 defines an attribute serialized that specifies whether the
contents of a field should be serialized and dumped into a single
column, and therefore not queryable. It does allow for any
serializable data to be stored, regardless of whether the data is
persistence-capable or not.
So I
Some corrections to the previous attempt (due to excessive use of the
Ctrl-C-Ctrl-V design pattern) :-
Example 1 : Collection of BigDecimal
I accidentally omitted this option
3. Embedded collection
field name=myfield embedded=true
collection element-type=java.math.BigInteger/
/field
No
Hi Craig,
thanks for your reply and your insights.
Example 1 : Collection of BigDecimal
1. Basic collection
field name=myfield
collection element-type=java.math.BigDecimal/
join/
/field
This creates 2 tables - 1 for the class owning myfield, and 1
join table to
contain
You are right. We have to mention java.util.Currency in order to
support it, and those classes we need to compile under 1.4.
I'd like to get feedback from others on this as well.
Craig,
That's what we're doing with JPOX. I can't see a better way
--
Andy
The jdbc-type attribute declares the type of the column in the
database. This type is defaulted based on the type of the field
being mapped.
Does this mean, that an implementation may choose for an default?
That was not the intent. The intent was that the JDBC type would be
obvious.
Well in the case of a char it is, but in the case of a java double for
example ? It all depends on the RDBMS. Some RDBMS support DOUBLE, some
DECIMAL, some NUMERIC, some have other types ...
This is the jdbc-type (generic sql type), not the sql-type we're
talking about (there is a
Hi Craig,
the most recent spec I have has reference to a PM.setDetachOnClose(boolean)
method (section 12.6.8). This isn't in the API20 project. It also refers to a
property ... which I think was going to be javax.jdo.option.DetachOnClose.
Can you clarify what the JDO impl can plan to use ?,
Hi Craig,
I'm also talking about the jdbc-type (or to be specific
javax.sql.Types). So
the JDO impl should always take JDBC Types.DOUBLE when the user has
a Java
double field? Many JDBC drivers *don't* provide a type mapping for
Types.DOUBLE (many don't provide support for several of
I asked this question back in April and got a response that it wasn't possible
while in this Incubator or something. Since we have users asking for this,
and since we have to coordinate JPOX releases to match it, I'll ask again ...
Can we please have the Apache JDO jar released somewhere so
Hi Craig,
Interim to getting it on ibiblio, I think it's easy to post on a wiki
page. Would that be suitable for the folks who are asking you for it?
I assume that the people asking want to get the jar file without
having to build the project, right?
Yep. The deliverable of the API20 project
A few things that need fixing in the TCK from my latest running, in the hope
that someone with SVN permissions can do the necessary. No patches here, just
instructions of what's wrong and what is needed to fix ;-)
File :
I'll look at the Map cases next
Michelle,
Here's some initial comments on the map tests.
1. HashMapStringKeyCollections : Field HashMapOfString_SimpleInterface7 is a
MapString,Interface with the value embedded, and no join table. I interpret
that as needing to serialise the map into the main
The issue about A truncation error was encountered trying to shrink CHAR
'65535' to length 1 should now be fixed with latest JPOX. JPOX CVS now uses
default jdbc-type as per the most recent JDO spec. In particular for this
error, when the java type is Character/char the jdbc-type chosen will be
Attached are patches for datastore and application identity schemas to fix
issues with incorrect schemas for table ALLTYPES, and PCPOINTSINGLEFIELDCHAR.
--
Andy
Index: /home/andy/work/jdo/trunk/tck20/test/sql/derby/applicationidentity/schema.sql
I changed the column types of table FIELDSOFCHARACTER back to INTEGER.
I also changed the ORM metadata for class FieldsOfCharacter, e.g.
I'm using JPOX nightly build 2005-08-01. Can you please check and verify
if JPOX calls PrepraredStatement.setString for the case above?
Hi Michael,
It's
The message reads as if the exception is thrown during execution of
SchemaTool. I'm not sure if SchemaTool if executed running TCK because
TCK assumes there is an existing schema in DB. These are JPOX parameters
that TCK specifies in file jdori.properties:
Hi Michael,
SchemaTool is simply a
org.apache.jdo.tck.pc.fieldtypes.FieldsOfSimpleInterface.SimpleInterface1
is of type org.apache.jdo.tck.pc.fieldtypes.SimpleInterface yet has
been specified as embedded. JPOX doesnt support embedding of this type.
Your embedded type must be PersistenceCapable.
I'm glad JPOX exception handling
Karan: Issue with maven: renaming JPOX releases to SNAPSHOT. Need to
update the README file and project.xml file.
Hi Karan,
FYI. JPOX now has it's own Maven repositor, at
http://www.jpox.org/downloads/maven
So if you add this repository to your maven.repo.remote environment variable
you can
1. Test status (Michael) Upgraded tests for SimpleObject,
SimpleInterface, and Object to test serializable have been checked in
and are pending JPOX feedback.
JPOX feedback : serialized attribute on field is not yet supported for
PersistenceCapable/Interface objects (it's supported for
I assume that this is the cause of the JDO-107 error:
JDODataStoreException: Cannot set Long parameter: value = null
Since you don't support serializing the object, you're trying to
write the key to the column.
Hi Craig,
Yep.
Fuller error messages so people can identify the column causing
Is maven not able to do use sourceforge download? What's the story?
Please don't tell me to just download it manually. That obviously
works. Why not automatic?
Attempting to download c3p0-0.9.0.jar.
WARNING: Failed to download c3p0-0.9.0.jar.
The build cannot continue because of the
2. Andy, if we can upload something to ibiblio repository using the
following (as you mentioned in a mail earlier)
maven create-upload-bundle
Hi Karan,
no, JPOX cannot upload things to IBiblio like that. All that maven
create-upload-bundle does is create a jar that can then be passed to the
The Detachable interface has one method: jdoReplaceDetachedState().
The StateManager interface has an additional method: Object[ ]
replacingDetachedState(Detachable, Object[ ]).
Minor updates to PersistenceCapable.
Comments please.
No comment other than please let us know when it's applied
FieldsOfSimpleClass now passes. JPOX latest now supports serialised PC fields
and serialised Interface fields.
The only thing stopping FieldsOfSimpleInterface passing is probably that JPOX
doesn't support embedded interface fields. I don't consider this a mandatory
part of JDO2. Embedded
When would be a good time to check it in then? I'm not planning any
updates unless someone finds a bug...
So just let me know when you are ready and I'll check it in.
Hi Craig,
check it in whenever you get a spare moment, and I'll get started on the JPOX
part.
--
Andy
Java Persistent
Any update on this?
Not from me. Not had time to look at it. Don't know if Erik has.
Out of interest, how do I run this CompletenessTest on its own ? (since it's
not in alltests.conf). I've tried running companyNoRelationships.conf,
which is fine for 1 run, but if I run it again it tries to
For the benefit of anyone developing the TCK and thinking about using the
latest API20 (with yesterdays changes) when running with JPOX : It won't work
with current latest build of JPOX (so stick to your existing
jdo2-api-2.0-SNAPSHOT.jar)
JPOX CVS has now been updated and the next nightly
Hi Michael(s),
Not fully read your proposal, so can't comment on the rest ...
- Does JDO require a inheritance element for classes in an inheritance
hierarchy? If not, is there a default? The same questions apply to the
strategy attribute inside of the inheritance element.
You don't need to
Suppose there are two non-abstract persistence-capable classes A and B.
Class B extends A. Both explicitly define the inheritance strategy
new-table. Class A maps to table TA and B maps to table TB. Then there
are still two scenarios possible, depending on where to store the
inherited fields
I can run companyNoRelationships.conf several times without
reinstalling the schema. The result is always the same:
Hi Michael,
I get the same as you, today! but certainly didn't yesterday. Since I can't
reproduce it myself now, someone please just close the issue (JIRA-116) and
if I find
Any update on this?
Not from me. Not had time to look at it.
Now had time, and is fixed in JPOX CVS - in tomorrows (11/08/2005) nightly
build. CompletenessTest passes for companyNoRelationships.conf
--
Andy
That exception is a NoSuchMethodError thrown by the enhanced code (see
below) of a class PCPointSingleFieldDate in methods
jdoCopyKeyFieldsFromObjectId. I decompiled the code of that class. It
seems that the JPOX enhancer generates a java.util.Date constructor call
that does not exist. This
Hi Michael,
for testing reasons I changed the type of a PK field from java.util.Date
to java.sql.Date. Running the JPOX enhancer I noticed that the declaring
pc class was not enhanced. After I changed the field type back to
java.util.Date, the pc class was enhanced properly. Does JPOX support
I've patched the JDOImplHelper class to make the construct method
static. There are no issues that I can think of to make this method
static, so I'll change this.
Does this help?
Hi Craig,
Thanks for looking into it. Referring to Michael's mail of the added
jdoCopyKeyFieldsFromObjectId()
CollectionCollections has a field CollectionOfSimpleClass3 which maps to
join table COLLECTION_OF_SIMPLE_CLASS3 with an element column called
SIMPCLSREF. This doesn't exist - it's called SIMPINTERFREF in the schema
for that table. [There are probably other fields in this class with the same
Hi Michael,
you are right: The ORM metadata does not match the schema. A while ago,
I have fixed the same issue in classes HashXXX, ListXXX, MapXXX
etc. Obviously, I have overlooked the issue in class
CollectionCollections. I'll fix this and I'll also check classes
ArrayXXX.
Thanks.
It's
Hi Michelle,
your fix for SimpleInterface is confirmed. Can someone with the necessary JIRA
privileges please close this issue (since I can't ...).
--
Andy
What if we define a new attribute on field called field-type, and for
the TCK we put in ...SimpleClass? Would that allow you to map it?
It certainly sounds doable (not looked at the code ...).
OK, JPOX now supports java.lang.Object as FCO. It's not currently using the
proposed field
Thanks you for passing your eagle eye over these snippets. I made the
corrections in the orm (three places for Object, SimpleClass, and
SimpleInterface), but I still get the same error.
Hi Michelle,
issues of this nature (merging of the ORM file with the JDO file) should be
fixed in the
Hi Michelle,
It seems that jpox maps Object as serialized by default. Where there is
no serialized or embedded attribute on the field, we map to a FK column,
e.g. OBJECT102 BIGINT REFERENCES SIMPLE_CLASS, giving a jpox error:
Well we interpret all types as serialized=false, but in section
Well we interpret all types as serialized=false, but in section 18.14 of
the spec java.lang types (which Object is) are to be embedded=true by
default. So we interpret this as serialising the Object into the table of
the class, into a BLOB column.
Michelle,
before you change anything
FieldsOfObject still doesn't work. JDO-120. AI: Need feedback from
Erik or Andy.
Feedback : TestFieldsOfObject.java is not correct. It's still trying to use
Object values that are String, and Integer even though the metadata is now
specifying that the implementation of the Object field is
Hi Craig,
I've added a couple of JIRAs about missing elements/attributes in the DTDs in
the api20 project. JDO-123, JDO-124.
Thanks
--
Andy
Hi Michael,
- Inheritance mapping 2: org.jpox.metadata.InvalidMetaDataException:
Class org.apache.jdo.tck.pc.company.DentalInsurance has field
org.apache.jdo.tck.pc.company.DentalInsurance.carrier declared in
MetaData, but this field doesnt exist in the class!
You have a field in
I replaced in the ORM the part that overwrites the definition for
Insurance, Dental and Medical as below and got it to work. I'm using
JPOX head.
And previous to that, I fixed an issue in CVS HEAD where the overriding field
was specified in the ORM file (rather than the JDO file which our
for inheritance tests , the moment i run the
test the second time, i get a primary key / duplicate key exception.
Hi Karan,
the issue you have with the first inheritance test about PK exceptions is due
to a failure in tearDown() the first time it was run. This is fixed in JPOX
CVS and will
Clean checkout, followed by maven -o clean installSchema for TCK20 results
in
file: /home/andy/work/jdo/trunk/tck20/test/conf/schemaAttributeORM.conf does
not exist!
Someone's mistyped an entry in test/conf/configurations.list
Currently says schemaAttributeORM.conf
Should be
*** For factory sequences (not defined in the database) is the API
sufficient to use the sequence in the three modes: nontransactional,
contiguous, and noncontiguous? ***
Well, the implementation has to call factory.newInstance() to create the
sequence, but has no way of telling the factory
Can you help us define a table-based incrementing sequence that can
be used with the TCK? We (TCK team) will write a factory sequence
class but as you know, the specification is short on how to define it.
Hi Craig, Karan,
JPOX provides some sequences internally, and also we have a sample
i get a JDOUserException that jpox is unable to find the sequence.
Karan,
the issue here is that JPOX doesn't yet support specification of the
sequence in the ORM. Just put it in the JDO file for now.
--
Andy
Hi Craig,
Andy, Erik,
Is it possible to use the SimpleSequenceFactory as a sequence factory
with JPOX? It does adhere to the specified interface and static
newInstance method.
Yes.
Just took your sequence patch and added a metadata definition to refer to it
sequence
Hi Michael,
I read the spec that a self-referencing relationship (meaning the field
type is the same class that declares the field) is a good use case for
the fetch-depth attribute. But I think the use of fetch-depth is not
restricted to self-referencing relationships. Am I wrong here?
I
] wrote:
Hi Jeff,
That was fast.
Thanks!
Craig
On Sep 25, 2005, at 12:45 AM, Jeff Turner wrote:
On Sat, Sep 24, 2005 at 10:41:27AM -0700, Craig Russell wrote:
Hi,
Can you please add Andy Jefferson to the list of people allowed to
update issues in JDO JIRA?
http://issues.apache.org/jira
Is build of runtime20 currently broken ? I get
[javac] Compiling 71 source files
to /home/andy/work/jdo/trunk/runtime20/target/classes
/home/andy/work/jdo/trunk/runtime20/src/java/org/apache/jdo/impl/pm/PersistenceManagerImpl.java:269:
cannot resolve symbol
symbol : method
The Schema 2 inheritance test provokes a question regarding
autoassign/identity strategy when using subclass-table strategy. We have 3
classes Employee, PartTimeEmployee, FullTimeEmployee. The Employee class uses
subclass-table and the 2 subclasses use new-table inheritance strategy.
This maps
Hi Michael,
My understanding is that your scenario applies to datastore identity.
Applications can only construct objectid instances in case of
application identity. So, how would an application get an Employee
objectid instance?
I was quoting one example of where things break in this
I've not gone through the data created by the test, only the first few
records and the fact that it is creating these duplicate records (as I call
them).
Here's an issue for you Michael. This is the real issue behind our discussion
earlier. Hopefully this simplifies it all :-)
In the schema
Would it be cleaner to not allow transient instances to be included in
attachCopy() graphs at all? Sounds that way to me.
No, I'd like to continue to allow transient instances to be included in
attachCopy graphs. I'd like to **add** the ability for detached objects to
be included in
Hi Michelle,
I have the 10/7 JPOX enhancer, but the last build of jpox-latest.jar
that I see at http://www.jpox.org/downloads/nightly/ is 9/28.
Sorry about that. Seems that I forgot to update the jdo2 api snapshot jar on
the server that it builds against, and consequently the nightly build
Hi Michael,
Craig proposed to drop the identity types on the PK columns of tables
persons, fulltimeemployees, and parttimeemployees. Instead, an
implementation-defined sequence should be used to generate unique PK
values for the three tables.
OK. As I mentioned in the previous post, the only
Hi Michelle,
I've been through the issues with the various TCK Map tests, and have the
following comments :-
1. The key-type, value-type are currently being defined as things like Object,
String, SimpleClass whereas the Collection tests use fully-qualified names.
While this may be intentional
Why is it that when I sometimes look at Apache JIRA I find that issues are
maybe no longer there, then I look back 10 mins later they appear. Seems like
Apache have some process that reloads up JIRA every so often. Can anyone
confirm what is actually going on with your JIRA ?
I look today and
Why is it that when I sometimes look at Apache JIRA I find that issues are
maybe no longer there, then I look back 10 mins later they appear. Seems like
Apache have some process that reloads up JIRA every so often. Can anyone
confirm what is actually going on with your JIRA ?
I look today and
The only other interpretation that I would support is to literally do
what Java does: for these specific type names (String, Integer, etc.
list of 10 names), look first in the named package for the type, and
if not found, go to java.lang to resolve them.
I like better this
I do too, and
The TCK test for NotEquals is comparing the equality of floating point values
and
subsequently failing.
The spec says :-
spec
Note that comparisons between floating point values are by nature inexact.
Therefore, equality com-
parisons (== and !=) with floating point values should be used with
The TCK test OrderOfParameters has an error currently.
The second query has firstname == :param2 lastname == :param1 (the opposite
way around to the params in the first query), and thye parameter values for both
queries are the same. As a result the result will be the same (the parameters
are
The TCK test ImplicitParameters has an error currently.
The testFilter has a query using firstname = :param.
This should be changed to firstname == :param
--
Andy
Hi Michael,
Please have a look.
Did that and its now fixed in JPOX CVS.
--
Andy
The TCK test Instanceof has an error.
It defines 2 queries, yet only 1 set of expected results, ending up with
ArrayOutOfBoundsException when trying to get the expected result for the second
part.
--
Andy
Hi Michael,
thanks for your changes.
I don't understand why you changed the expected result to be emp3, emp4. The
query is looking for Employees that have a mentor field that is
PartTimeEmployee.
That means that it should return emp2 and emp3. The query is *not* which
employees *are*
The ImplicitParameters test has a test called testResult that puts a parameter
in the result.
Let's leave aside why anyone would want to do this, other than insanity :-)
Looking at the result of the test (with JPOX CVS) I now get
[java] expected: [[Ljava.lang.Object;@18e1286,
Hi Michael,
have been through your latest JDOQL tests that were checked in yesterday, and
applied necessary changes to JPOX.
Some things for you also I think :-
1. MetadataSearchOrder.testPackageJDOQuery - this complains about not finding
the
jdoquery file. By my understanding the jdoquery file
Hi Craig,
It sounds like you are thinking that you would like two different
attributes, one for element-type and another for implementation-
type. Can you explain what the difference is? I only see the need
for one value here: the type that can be stored in the field,
element, key, or
Hi,
This has been asked for before, not just by me. I'll ask again :-)
We have 3 possible types of MetaData files in JDO2.
jdo (which has jdo.dtd for validation)
orm (which has orm.dtd for validation)
jdoquery (which has nothing for validation)
There is currently a TCK test that uses jdoquery
The result class LongString has a field private long l, yet the constructor
and setter are taking in an int. This results in failures in the checks
that JPOX makes. Is this intentional ?
I would refer to 14.6.12
spec
if no public field matches the name and type, a public “set” method that
Hi Michael,
Is the different event handling concerning relationships intentional?
Impossible to comment without having a case in front of me that I can see what
is being performed. I dont know what relationships you have between those
objects and what is having makePersistent/deletePersistent
1 - 100 of 1257 matches
Mail list logo
