So does it make sense to consider how Java has handled a similar concept: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ File.html#getAbsolutePath()

Could we use some of the same terms, perhaps AbsoluteUnitName for the purpose you are proposing here, and not implement UnitName until someone asks for it?

In the non-managed environment, I assume application-name and module- name are empty so the absolute unit name would be the same as the unit name?

Craig

On Nov 14, 2006, at 2:48 PM, Patrick Linskey wrote:

So I'm having a bit of a hard time with this property setting.

In many environments, it makes a lot of sense to line up the
openjpa.PersistenceUnitName property with the setting in the persistence.xml file. However, in an appserver, that name might not be unique. We (BEA) sometimes need to be able to get the "fully-qualified" persistence unit name, which is probably most closely defined in a Java EE environment as
application-name.module-name.persistence-unit-name or somesuch.

But obviously, if I create a property called openjpa.PersistenceUnitName, people would (understandably) assume that the property should contain just persistence-unit-name, and not the fully-qualified beast. That's why I was
thinking along the terms of 'Id' instead of 'PersistenceUnitName'.

Do others agree that these concepts are not quite the same? If so, should I create a property for each (since PersistenceUnitName might be useful), or should I just create the ID-related one, since that's all I really need
right now?

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

______________________________________________________________________ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this
by email and then delete it.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 4:50 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: openjpa.Id property

Hi Patrick,

I don't think there would be an issue with calling it unitName or
persistenceUnitName, as in getUnitName() or
getPersistenceUnitName().
It will be common for people to try to figure out what the Id
property from a Configuration really means so the more help we give
them the easier it will be to remember.

openjpa.unitName
openjpa.persistenceUnitName

Maybe I'm missing something obvious...

Craig

On Nov 9, 2006, at 2:19 PM, Patrick Linskey wrote:

Hi,

It's useful in a number of places to get an identifier for a
particular
Configuration. For example, as we discussed a few months
ago, it would
be useful if the logging subsystem automatically wrote the
persistence
unit's ID along with log messages if no such ID was specified in
the log
configuration.

Any objections to such an addition? In a JPA environment, this would
correspond to the persistence unit's unitName attribute.

Any suggestions for a better name than openjpa.Id for the
property?
This
would result in an OpenJPAConfiguration.getId() method call that
returned a String.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.


______________________________________________________________
________
_
Notice:  This email message, together with any attachments, may
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and
affiliated
entities,  that may be confidential,  proprietary,  copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to