[JBoss JIRA] Resolved: (JBPORTAL-883) Portal + Hibernate + Oracle 9i, /nodetypes/custom_nodetypes.xml null pointer issue
by Roy Russo (JIRA)
[ http://jira.jboss.com/jira/browse/JBPORTAL-883?page=all ]
Roy Russo resolved JBPORTAL-883.
--------------------------------
Resolution: Out of Date
> Portal + Hibernate + Oracle 9i, /nodetypes/custom_nodetypes.xml null pointer issue
> ----------------------------------------------------------------------------------
>
> Key: JBPORTAL-883
> URL: http://jira.jboss.com/jira/browse/JBPORTAL-883
> Project: JBoss Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Portal CMS
> Affects Versions: 2.2.1 Final
> Environment: Portal 2.2.1 bundle, Oracle 9i (driver 9.2.0.4), Win2k server
> Reporter: David Nebinger
> Assigned To: Roy Russo
>
> This is related to the JBPORTAL-816 defect reported but erroneously closed because it could not be duplicated.
> The bug is still out there, and it is related to the columns generated in the jbp_cms_repositoryentry table. Basically when the portal is first set up, it creates the columns using the hibernate schema tools. The generated table has a blob in the FSENTRY_DATA column.
> As long as you do not cycle jboss, the portal/cms system works just fine.
> But after jboss restart, the null pointer exception related to the loading of the /nodetypes/custom_nodetypes.xml file (represented in a row from the table) fails, resulting in the CMS service not coming up and the portal is totally unusable. See 816 for the stack trace indicating the source of the cascading failures in the code.
> As oracle/hibernate have a history of not functioning well using blobs, this really came as no surprise once I figured out what was going on. And since hibernate does not treat this as a bug, it probably won't be considered a bug for the portal either. :-(
> However, should someone care to work with me on testing a resolution, feel free to contact me about it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 8 months
[JBoss JIRA] Commented: (JBAS-3158) Need a way to detect collisions between JSF RI and JSF MyFaces
by Stan Silvert (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3158?page=comments#action_12347763 ]
Stan Silvert commented on JBAS-3158:
------------------------------------
I think I can do a simple version of this fix for 4.2. Since 4.2 will contain the RI, we will do the opposite logic. We'll just detect if MyFaces can be loaded. If so, we will spit out a warning message.
For JBoss 5, I'd like to do something a bit more elaborate that automatically disables any JSF implementation that is bundled with the WAR.
> Need a way to detect collisions between JSF RI and JSF MyFaces
> --------------------------------------------------------------
>
> Key: JBAS-3158
> URL: http://jira.jboss.com/jira/browse/JBAS-3158
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Stan Silvert
> Assigned To: Stan Silvert
> Priority: Minor
>
> Developers who choose to bundle the Sun JSF Reference Implementation with their WAR will get strange errors like ERROR [javax.faces.webapp.UIComponentTag] Faces context not found. getResponseWriter will fail. Check if the FacesServlet has been initialized at all in your web.xml.
> This is because of collisions between classes provided in both implementations which are required to have the same javax.faces package name. We should be able to detect if the RI is present and tell the user to either remove the RI, remove MyFaces, or scope the deployment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 8 months