Property Set Deployment

Question

Hello All:
I am looking for a way to deploy a property set file; joedoe.usr to Weblogic Portal 8.1. Has anyone successfully deployed a property set file (including the UUP ejb that uses it) to WebLogic outside of Workshop? If so, can you provide steps to do so?
FYI, I created a property set file and added to my ear in the META-INF directory. When I deploy my ear to Weblogic, I can see my portal application and all the portal resources in the Portal Admin. However, I do not see my "custom" property set when editing a user. My constraint is that my application must not use Workshop to create and deploy.
Thank you,
Southin

Answer 1

Hi Deepak:
Thank you for replying to my message. Unfortunately, the example the BEA does not work for me. Yes my corporateProfile.usr is in the data/userprofiles folder where the CustomerProperties.usr resides. My custom ejb that extends extends com.bea.p13n.property.EntityPropertyManager is successfully deployed, however I cannot see the property set that I created in the Portal Admin console.
Attached are my weblogic-ejb-jar.xm and ejb-jar.xml files that I edit after following the instructions for "Deploy a ProfileManager That Can Use the New EntityPropertyManager." Does anyone see something wrong?
------------------------ ejb-jar.xml -------------
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC
'-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN'
'http://java.sun.com/dtd/ejb-jar_2_0.dtd' >
<ejb-jar>
<enterprise-beans>
<!-- TrackedAnonymous EJB -->
<entity>
<ejb-name>TrackedAnonymous</ejb-name>
<home>com.bea.p13n.usermgmt.profile.TrackedAnonymousHome</home>
<remote>com.bea.p13n.usermgmt.profile.TrackedAnonymous</remote>
<ejb-class>com.bea.p13n.usermgmt.profile.internal.TrackedAnonymousBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.String</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>TrackedAnonymousBean</abstract-schema-name>
<cmp-field>
<field-name>anonymousUserId</field-name>
</cmp-field>
<cmp-field>
<field-name>lastVisited</field-name>
</cmp-field>
<primkey-field>anonymousUserId</primkey-field>
<ejb-local-ref>
<description>Reference to TrackedPropertySet EJB</description>
<ejb-ref-name>ejb/TrackedPropertySet</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<local-home>com.bea.p13n.property.TrackedPropertySetHome</local-home>
<local>com.bea.p13n.property.TrackedPropertySet</local>
<ejb-link>TrackedPropertySet</ejb-link>
</ejb-local-ref>
</entity>
<!-- Tracked Property Set EJB -->
<!-- Local interfaces for this one only, because it's referred to only by TrackedAnonymous.
The relationships bewteen these two EJBs are defined in the 'relationships' attribute at
the end of this file. -->
<entity>
<ejb-name>TrackedPropertySet</ejb-name>
<local-home>com.bea.p13n.property.TrackedPropertySetHome</local-home>
<local>com.bea.p13n.property.TrackedPropertySet</local>
<ejb-class>com.bea.p13n.property.internal.TrackedPropertySetBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.String</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>TrackedPropertySetBean</abstract-schema-name>
<cmp-field>
<field-name>anonymousPropertyId</field-name>
</cmp-field>
<cmp-field>
<field-name>anonymousUserId</field-name>
</cmp-field>
<cmp-field>
<field-name>propertySetName</field-name>
</cmp-field>
<cmp-field>
<field-name>propertyName</field-name>
</cmp-field>
<cmp-field>
<field-name>propertyValue</field-name>
</cmp-field>
<primkey-field>anonymousPropertyId</primkey-field>
<!-- Find all property sets with the same anonymous user id. This gives us all property sets associated with a single
TrackedAnonymous EJB -->
<query>
<query-method>
<method-name>findByAnonymousUserId</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</query-method>
<ejb-ql>SELECT OBJECT (a) FROM TrackedPropertySetBean a WHERE a.anonymousUserId = ?1 </ejb-ql>
</query>
</entity>
<!-- PropertySetManager EJB -->
<session>
<ejb-name>PropertySetManager</ejb-name>
<home>com.bea.p13n.property.PropertySetManagerHome</home>
<remote>com.bea.p13n.property.PropertySetManager</remote>
<ejb-class>com.bea.p13n.property.internal.PropertySetManagerImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<env-entry>
<env-entry-name>repository/CONTENT</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>com.bea.content.manager.propertysets.PropertySetRepositoryImpl</env-entry-value>
</env-entry>
<!-- following are mappings from file extension to property set type -->
<env-entry>
<env-entry-name>extension/clg</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>CATALOG</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>extension/evt</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>EVENT</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>extension/req</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>REQUEST</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>extension/ses</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>SESSION</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>extension/usr</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>USER</env-entry-value>
</env-entry>
<!-- the ejb/ContentManagers branch is for the
com.bea.p13n.content.PropertyRepositoryImpl
-->
<ejb-ref>
<ejb-ref-name>ejb/ContentManagers/Document</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.content.document.DocumentManagerHome</home>
<remote>com.bea.p13n.content.document.DocumentManager</remote>
<!-- FIXME. Eventually need to rework user manager stuff so we can do this. For now, the DocumentManager
is in weblogic-ejb-jar.xml, where it is deployed only if it is referenced.
<ejb-link>wps.jar#DocumentManager</ejb-link> -->
</ejb-ref>
</session>
<!-- EntityPropertyManager EJB -->
<session>
<ejb-name>EntityPropertyManager</ejb-name>
<home>com.bea.p13n.property.EntityPropertyManagerHome</home>
<remote>com.bea.p13n.property.EntityPropertyManager</remote>
<ejb-class>com.bea.p13n.property.internal.EntityPropertyManagerImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<ejb-ref>
<ejb-ref-name>ejb/PropertySetManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.property.PropertySetManagerHome</home>
<remote>com.bea.p13n.property.PropertySetManager</remote>
<ejb-link>PropertySetManager</ejb-link>
</ejb-ref>
<resource-ref>
<res-ref-name>jdbc/commercePool</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</session>
<!-- Ldap Property Manager
To use this, uncomment it here as well as in weblogic-ejb-jar.xml.
Configure the LDAP connection and settings using the env-entry values (see descriptions below).
Do not forget to uncomment the ejb-link and method-permission tags for the LdapPropertyManager.
An easy way to ensure you don't miss anything is to search for "ldap" (case-insensitive) here AND in
weblogic-ejb-jar.xml. Search from the beginning to the end of the file.
<session>
<ejb-name>LdapPropertyManager</ejb-name>
<home>com.bea.p13n.usermgmt.profile.ldap.LdapPropertyManagerHome</home>
<remote>com.bea.p13n.usermgmt.profile.ldap.LdapPropertyManager</remote>
<ejb-class>com.bea.p13n.usermgmt.profile.ldap.internal.LdapPropertyManagerImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<env-entry>
<description>Use SSL to connect to ldap server</description>
<env-entry-name>config/useSSL</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>false</env-entry-value>
</env-entry>
<env-entry>
<description>LDAP Server URL</description>
<env-entry-name>config/serverURL</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ldap://server.company.com:389</env-entry-value>
</env-entry>
<env-entry>
<description>Principal name to use when connecting to the ldap server (optional).
Anonymous bind will be used if not specified. This entry will be
ignored if config/credentialMBeanName is set below. </description>
<env-entry-name>config/principal</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot</env-entry-value>
</env-entry>
<env-entry>
<description>The password of the principal specified above (required if principal set). This
entry is ignored if config/credentialMBeanName is set below.</description>
<env-entry-name>config/principalCredential</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>weblogic</env-entry-value>
</env-entry>
<env-entry>
<description>The name of the Credential MBean in application-config.xml that will
be used to store the principal's username and principal's password. The password
will be stored in an encrypted form. This is the principal/credential used to bind to
the LDAP server. The password will be decrypted before it is used to bind to the
LDAP server.
Using this entry will override anything set for the config/principal and
config/principalCredential. If this entry and config/principal and
config/principalCredential are not specified then anonymous bind will be used.
(this entry is optional)</description>
<env-entry-name>config/credentialMBeanName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>LdapPropertyManager</env-entry-value>
</env-entry>
<env-entry>
<description> The location(s) of users in the ldap directory.
There can be one or more user DNs. The entries are named like this:
config/userDN
config/userDN-1
config/userDN-2
and they are searched in that order.
If there is only one, then it must be config/userDN
Typical values:
ou=People,o=company.com
ou=People,dc=mycompany,dc=com
</description>
<env-entry-name>config/userDN</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ou=People,o=company.com</env-entry-value>
</env-entry>
<env-entry>
<description> The location(s) of groups in the ldap directory
There can be one or more group DNs. The entries are named like this:
config/groupDN
config/groupDN-1
config/groupDN-2
and they are searched in that order.
If there is only one, then it must be config/groupDN
Typical values:
ou=Groups,o=company.com
ou=Groups,dc=mycompany,dc=com
</description>
<env-entry-name>config/groupDN</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ou=Groups,o=company.com</env-entry-value>
</env-entry>
<env-entry>
<description>A boolean to enbable/disable SUBTREE_SCOPE searches for user/group properties
below the userDN(s) and groupDN(s). For example, if this property is true, then you could specify
the "config/userDN" env-entry as ou=People,dc=mycompany,dc=com and users that are in both
ou=PeopleA,ou=People,dc=mycompany,dc=com and in ou=PeopleB,ou=People,dc=mycompany,dc=com
could be used. A getProperty() call would return a value for the first user found in
the specified "config/userDN" or in any branch below it. This boolean also affects
searches for group properties. If multiple userDNs (or groupDNs) are specified then
this SUBTREE_SCOPE will apply to searches starting in all of those specified DNs.
</description>
<env-entry-name>config/objectPropertySubtreeScope</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>false</env-entry-value>
</env-entry>
<env-entry>
<description>The user attribute to map to a username
If there is only one, then it is applied to all userDNs.
If there is more than one, then they are applied, in order,
to the userDNs. If there is more than one, then the number must
match the number of userDNs.
The entries are named like this:
config/usernameAttribute
config/usernameAttribute-1
config/usernameAttribute-2
and they are used in that order.
If there is only one, then it must be config/usernameAttribute
</description>
<env-entry-name>config/usernameAttribute</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>uid</env-entry-value>
</env-entry>
<env-entry>
<description> The group attribute to map to a group name
If there is only one, then it is applied to all groupDNs.
If there is more than one, then they are applied, in order,
to the groupDNs. If there is more than one, then the number must
match the number of groupDNs.
The entries are named like this:
config/groupnameAttribute
config/groupnameAttribute-1
config/groupnameAttribute-2
and they are used in that order.
If there is only one, then it must be config/groupnameAttribute
</description>
<env-entry-name>config/groupnameAttribute</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>cn</env-entry-value>
</env-entry>
<env-entry>
<description>Flag to specify if LDAP attributes will be determined to be
single value or multi-value via the schema obtained from
the attribute. If false, then the attribute is stored as
multi-valued (a Collection) only if it has more than one value.
Leave false unless you intend to use multi-valued LDAP attributes
that may have only one value. Using true adds overhead to check the
LDAP schema. Also, if you use true beware that most LDAP attributes
are multi-value. For example, iPlanet Directory Server 5.x uses multi-value
for givenName, which you may not expect unless you are familiar with LDAP
schemas.
This flag will apply to property searches for all userDNs and all groupDNs.
</description>
<env-entry-name>config/detectSingleValueFromSchema</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>false</env-entry-value>
</env-entry>
<env-entry>
<description>Value of the name of the attribute in the LDAP schema that is used to
determine single value or multi-value (RFC2252 uses SINGLE-VALUE)
This attribute in the schema should be true for single value and false or
absent from the schema otherwise.
The value only matters if config/detectSingleValueFromSchema is true.
</description>
<env-entry-name>config/singleValueSchemaAttribute</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>SINGLE-VALUE</env-entry-value>
</env-entry>
<env-entry>
<description> Name for the cache used by the ldap property manager
If you deploy multiple LdapPropertyManager beans, you must set
the caches to different names to avoid collisions.
Defaults to "ldapPropertyCache" if unset.
</description>
<env-entry-name>config/ldapPropertyCacheName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>ldapPropertyCache</env-entry-value>
</env-entry>
</session>
-->
<!-- Property Set Web Service EJB -->
<session>
<ejb-name>PropertySetWebService</ejb-name>
<home>com.bea.p13n.property.webservice.PropertySetWebServiceHome</home>
<remote>com.bea.p13n.property.webservice.PropertySetWebService</remote>
<ejb-class>com.bea.p13n.property.webservice.internal.PropertySetWebServiceImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<ejb-ref>
<ejb-ref-name>ejb/PropertySetManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.property.PropertySetManagerHome</home>
<remote>com.bea.p13n.property.PropertySetManager</remote>
<ejb-link>PropertySetManager</ejb-link>
</ejb-ref>
</session>
<!-- RulesManager EJB -->
<session>
<ejb-name>RulesManager</ejb-name>
<home>com.bea.p13n.rules.manager.RulesManagerHome</home>
<remote>com.bea.p13n.rules.manager.RulesManager</remote>
<ejb-class>com.bea.p13n.rules.manager.internal.RulesManagerImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<env-entry>
<description>
This property will be used by RulesManagerImpl to create an instance of
the RuleSetRepository.
</description>
<env-entry-name>RuleSetRepositoryClassName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>com.bea.p13n.rules.manager.internal.RuleSetPersistenceManager</env-entry-value>
</env-entry>
</session>
<!-- User Manager EJB -->
<session>
<ejb-name>UserManager</ejb-name>
<home>com.bea.p13n.usermgmt.UserManagerHome</home>
<remote>com.bea.p13n.usermgmt.UserManager</remote>
<ejb-class>com.bea.p13n.usermgmt.internal.UserManagerImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<!-- ReservedUserNames is used to list all names (case insensitive)
that are restricted: the UserManager will not create users
with these names. The list is comma-delimited.
-->
<!--
<env-entry>
<env-entry-name>ReservedUserNames</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>foo,foo2</env-entry-value>
</env-entry>
-->
<!-- ProtectedUserNames is used to list all names (case insensitive)
that cannot be deleted through the UserManager (or portal tools).
The list is comma-delimited.
-->
<!--
<env-entry>
<env-entry-name>ProtectedUserNames</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>foo,foo2</env-entry-value>
</env-entry>
-->
<!-- The UserManager used programatic security to allow
users to modify their own data (where username == profileName)
or anyone in one of these (administrative) roles.
Used in the methods: setPassword and removeUser.
Other methods can be protected using declarative security.
Should at least include the WebLogic Admin role, if left empty
or mapped to "empty" roles, then no one will be able to admin
user profiles.
Each role listed here should also have a security-role-ref entry below -->
<env-entry>
<env-entry-name>AuthorizedRoles</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>Admin,PortalSystemAdministrator</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>disallowedUserCharacters</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>*,%</env-entry-value>
</env-entry>
<ejb-ref>
<ejb-ref-name>ejb/UserProfileManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.usermgmt.profile.ProfileManagerHome</home>
<remote>com.bea.p13n.usermgmt.profile.ProfileManager</remote>
<ejb-link>UserProfileManager</ejb-link>
</ejb-ref>
<ejb-ref>
<ejb-ref-name>ejb/ProfileType/WLCS_Customer</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.commerce.ebusiness.customer.CustomerProfileManagerHome</home>
<remote>com.bea.commerce.ebusiness.customer.CustomerProfileManager</remote>
<!-- FIXME. Can't do this without always deploying Customer. Eventually need
to rework user manager stuff so we can do this. For now, the CustomerProfileManager
is in weblogic-ejb-jar.xml, where it is deployed only if it is referenced.
<ejb-link>commerce.jar#CustomerProfileManager</ejb-link> -->
</ejb-ref>
<!-- Security role refs for roles listed in AuthorizedRoles -->
<security-role-ref>
<description>Portal system administrators</description>
<role-name>PortalSystemAdministrator</role-name>
<role-link>PortalSystemAdministrator</role-link>
</security-role-ref>
<security-role-ref>
<description>WLS System administrators</description>
<role-name>Admin</role-name>
<role-link>Admin</role-link>
</security-role-ref>
<resource-ref>
<res-ref-name>jdbc/commercePool</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</session>
<!-- Group Manager EJB -->
<session>
<ejb-name>GroupManager</ejb-name>
<home>com.bea.p13n.usermgmt.GroupManagerHome</home>
<remote>com.bea.p13n.usermgmt.GroupManager</remote>
<ejb-class>com.bea.p13n.usermgmt.internal.GroupManagerImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<!-- ProtectedGroupNames is used to list all names (case insensitive)
that cannot be deleted through the GroupManager (or portal tools).
The list is comma-delimited.
-->
<env-entry>
<env-entry-name>ProtectedGroupNames</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>Operators,Monitors,Deployers</env-entry-value>
</env-entry>
<ejb-ref>
<ejb-ref-name>ejb/GroupProfileManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.usermgmt.profile.ProfileManagerHome</home>
<remote>com.bea.p13n.usermgmt.profile.ProfileManager</remote>
<ejb-link>GroupProfileManager</ejb-link>
</ejb-ref>
</session>
<!-- Realm Configuration EJB -->
<session>
<ejb-name>RealmConfiguration</ejb-name>
<home>com.bea.p13n.usermgmt.config.RealmConfigurationHome</home>
<remote>com.bea.p13n.usermgmt.config.RealmConfiguration</remote>
<ejb-class>com.bea.p13n.usermgmt.config.internal.RealmConfigurationImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<ejb-ref>
<ejb-ref-name>ejb/GroupProfileManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.usermgmt.profile.ProfileManagerHome</home>
<remote>com.bea.p13n.usermgmt.profile.ProfileManager</remote>
<ejb-link>GroupProfileManager</ejb-link>
</ejb-ref>
<ejb-ref>
<ejb-ref-name>ejb/UserProfileManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.usermgmt.profile.ProfileManagerHome</home>
<remote>com.bea.p13n.usermgmt.profile.ProfileManager</remote>
<ejb-link>UserProfileManager</ejb-link>
</ejb-ref>
</session>
<!-- User Profile Manager-->
<session>
<ejb-name>UserProfileManager</ejb-name>
<home>com.bea.p13n.usermgmt.profile.ProfileManagerHome</home>
<remote>com.bea.p13n.usermgmt.profile.ProfileManager</remote>
<ejb-class>com.bea.p13n.usermgmt.profile.internal.UserProfileManagerImpl</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<!-- map all properties in property set ldap to ldap server -->
<env-entry>
<env-entry-name>PropertyMapping/ldap</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>LdapPropertyManager</env-entry-value>
</env-entry>
     <!-- map all properties in corporateProfile property set to CorporateProfileManager -->
          <env-entry>
<env-entry-name>PropertyMapping/corporateProfile</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>CorporateProfileManager</env-entry-value>
</env-entry>
<!-- The UserProfileManager used programatic security to allow
users to modify their own data (where username == profileName)
or anyone in one of these (administrative) roles.
Used in the methods: deleteProfile, removeProperty,
removeSuccessor, setProperty, and setSuccessor.
Other methods can be protected using declarative security.
Should at least include the WebLogic Admin role, if left empty
or mapped to "empty" roles, then noone will be able to admin
user profiles.
Each role listed here should also have a security-role-ref entry below -->