[JBoss JIRA] Created: (JBESB-589) Smooks decoders do not handle superclasses/interfaces of a specified type
by Kevin Conner (JIRA)
Smooks decoders do not handle superclasses/interfaces of a specified type
-------------------------------------------------------------------------
Key: JBESB-589
URL: http://jira.jboss.com/jira/browse/JBESB-589
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transformation Service
Reporter: Kevin Conner
Assigned To: Tom Fennelly
Fix For: 4.2
The XML2POJO and XML2XML_date_manipulation QSes have recently been changed to decode types related to the target class.
One of the changes was to decode a Calendar object in the OrderDate class.
Unfortunately smooks fails to identify the setter as the CalendarDecoder returns a GregorianCalendar which AbstractBeanPopulator uses to identify the setter.
I have spoken with Tom and he has a fix for this. In the meantime I have updated the QSes to use Dates instead of Calendars.
--
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
17 years, 4 months
[JBoss JIRA] Created: (JBESB-638) Transient registry errors caused by jUDDI race condition
by Kevin Conner (JIRA)
Transient registry errors caused by jUDDI race condition
--------------------------------------------------------
Key: JBESB-638
URL: http://jira.jboss.com/jira/browse/JBESB-638
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Registry and Repository
Reporter: Kevin Conner
Assigned To: Kurt Stam
Fix For: 4.2
Kurt, can you raise the following with jUDDI and have it fixed?
Thanks.
There is a race condition in the jUDDI codebase which causes transient registry failures.
The symptom of the race condition is the following error message
E_busy (10400) The request cannot be processed at the current time. The Registry is currently unavailable.
The class containing the race condition is org.apache.juddi.registry.local.Registry
Every call to Registry.getRegistry() results in the recreation and initialisation of a global variable (registry). As the assignment of the global variable is made *before* the initialisation method is called there exists a window of opportunity whereby a caller can obtain a reference to an uninitialised registry. The consequence of this is that calls to RegistryEngine.isAvailable() can return false.
I'm not sure why the RegistryEngine is being recreated on every call but the current code is unsafe (even if ignoring multiprocessor memory models). There should be not be a global reference to the registry if it is a requirement to recreate it on every invocation. If it is not a requirement then the initialisation should really be occurring within a static block.
--
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
17 years, 4 months