Database publishing Editlive field issue

Rhythmyx Technical Discussion
1

Managed to get an edition set up which is database publishing a number of my content items successfully to my target database. I need to know how to split multiple values from a checkboxtree into a child table, but for now would be happy to resolve the fact that my editlive fields are going into the database as follows:

com.percussion.utils.jsr170.PSProperty@6ddd39[name=rx:callout,value=<p>An opportunity abstract</p>,initialized=true]

This is despite setting, for example:

$row.CALLOUT - $sys.item.getProperty(“rx:callout”), and
$row.$encoding.CALLOUT - “base64”

as per the instructions in the manual.

2

I suspect you want:

$row.CALLOUT = $sys.item.getProperty(“rx:callout”).String

That is, you want the String Value of the Property, not the Property itself.

3

Thanks Dave.

Riddle me this. I have a dataconnection set to my target database which is not the Rhythmyx repository. My database publishing templates have all the parameters according to the manual required to publish to this database. Yet my database publish keeps insisting on creating the tables and publishing to the Rhythmyx repository, not the specified target database.

When I do the JNDI test connection I see that my database connection has a “principal = null” error. If I go into the Database tab in the workbench and look in the target database it appears fine, I refresh the table list and re-run the JNDI connection test and miraculously the connection is now OK. Following that the DB publish runs to the correct database the first time it’s run. It then decides to publish any subsequent editions to the RX repository database again.

This is very odd.

4

But may be because the same username and password had access to both databases??? Changed that and there appears to be consistency now.

Although after a RX service restart I still get the JNDI check error until I go to the workbench database tab and refresh my view on the target database. Does that have to be done every time?

5

It is indeed the case that when a restart of the RX service is done the JNDI db connection check reports an error with my target database and a DB publish errors with:

java.lang.SecurityException: Invalid authentication attempt, principal=null
at org.jboss.resource.connectionmanager.BaseConnectionManager2.getSubject(BaseConnectionManager2.java:665)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:461)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:894)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:73)
…etc

but after going into the Workbench and refreshing the Database Explorer view of the target database the publish works fine. I assume this is a bug?

6

It does seem to be a bug - we have a temp solution for now (we have cron job running our editions every hour) and we have set timeout for JNDI connection to 90min, so it never times out. Otherwise - we had same issue DB Publishing won’t work because the DB connection is timed out.

7

Please specify what version of Rhythmyx you’re using.

We’re contemplating doing database publishing for one of our sites, so it’d be good to know what to expect.

8

We are using 6.5.2 (just upgraded) and had many apps publishing to DB.

There are some positives and many negatives to DB publishing - it really depends how you going to utilize the data/content. You may as well look into publishing xml or .properties files, or completely switch to JCR queries and use some of the new Rx functionality of the JSR-170. But that if you have no too much legacy apps and content - not easy.

DB publishing setup is not hard - but has some limitations and lots of manual work , although with new DB publishing Templates in 6.5 you may build the content query and publish pretty fast.

Well - if you are upgrading from 5.7 - you are in for a little surprise - you’ll have to modify all you DB publishing assemblers to include file named identity.xsl - this one isn’t mentioned anywhere in documentation - it will force well formed nodes in xml / tabledefset / datadefset, otherwise the new rendering Rx engine …/assembler/render? will try to render everything as html which will give you HTML TABLES.
Here is the sample of identity.xsl:

****************************
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.1" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
  <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
  <xsl:template match="@*|node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
  </xsl:template>
</xsl:stylesheet>
****************************

Hope this helps anyone working with DB publishing

This file is courtesy of Allan - he remembered this fix when we called in with our issue :slight_smile:

9

[QUOTE=dbenua;945]I suspect you want:

$row.CALLOUT = $sys.item.getProperty(“rx:callout”).String

That is, you want the String Value of the Property, not the Property itself.[/QUOTE]

Worked for me. The documentation on page 380 of the Implementation guide for 6.5.2 needs to be fixed to reflect this change. As in, I didn’t need .String before I upgraded to 6.5…

10

Yes, we know about this issue. There’s was a change added in 6.5 intended to allow better support for binary properties. One of the “side effects” was that the “toString()” method and the “getString()” method are now different. This means that when you want the string value you must explicitly call .getString() or .String (they are equivalent).

I’ll check with the Doc people about whether this particular instance is on their fix list.

11

Responding to these posts:

[QUOTE=allana;956]It is indeed the case that when a restart of the RX service is done the JNDI db connection check reports an error with my target database and a DB publish errors with:

java.lang.SecurityException: Invalid authentication attempt, principal=null
at org.jboss.resource.connectionmanager.BaseConnectionManager2.getSubject(BaseConnectionManager2.java:665)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:461)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:894)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:73)
…etc

but after going into the Workbench and refreshing the Database Explorer view of the target database the publish works fine. I assume this is a bug?[/QUOTE]

The issue is that you cannot use datasources created via the Rhythmyx Server Administrator with Database Publishing. The reason is that the password encryption scheme used for these datasources is tied to the Rhythmyx web application (rxapp.war), and doesn’t work from the publisher web app (rxservices.war). The JndiTest page is in the rxservices.war application, and so cannot create connections using datasources that have passwords encrypted in this manner.

This may seem to work intermittenly and unreliably if the connections are first successfully created from within the Rhythmyx webapp (e.g. by using the workbench Database Explorer) - these connections are added to the JBoss connection pool and will work from any web app while they remain alive. Once they time out, the next time the publisher web app (rxservices.war) it tries to get a connection from the connection pool, it needs to create a new one, and since that request is coming from the rxservices webapp, it fails.

The correct method for database publishing is to create your own JNDI datasource file in the AppServer\server\rx\deploy directory, which must be a file ending with the “-ds.xml” suffix (e.g. “dbpub-ds.xml”). You can find examples in the AppServer\docs\examples\jca directory - you should create a local-tx-datasource.

The next product release will allow Rhythmyx datasources created with the Server Administrator to be used with database publishing.

12

[QUOTE=dbenua;2198]Yes, we know about this issue. There’s was a change added in 6.5 intended to allow better support for binary properties. One of the “side effects” was that the “toString()” method and the “getString()” method are now different. This means that when you want the string value you must explicitly call .getString() or .String (they are equivalent).

I’ll check with the Doc people about whether this particular instance is on their fix list.[/QUOTE]

This issue has been logged for correction in the documentation. The fix is currently scheduled for the next release.

RLJII