[JBoss JIRA] (SRAMP-390) Installer should just use major version for supported platforms
by Gary Brown (JIRA)
Gary Brown created SRAMP-390:
--------------------------------
Summary: Installer should just use major version for supported platforms
Key: SRAMP-390
URL: https://issues.jboss.org/browse/SRAMP-390
Project: S-RAMP
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Gary Brown
Assignee: Eric Wittmann
This issue affects overlord-commons, sramp and dtgov.
Currently jetty8 and tomcat7 are supported platforms, however the redhat platforms (eap and fuse) use a major/minor version number. This means that a new distribution would be required for each minor version release of these platforms.
Would prefer if just the major version number was used, and the installer for that major version cater for any differences that may occur through the minor versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results
by Eric Wittmann (JIRA)
Eric Wittmann created SRAMP-389:
-----------------------------------
Summary: Performance issue in s-ramp client when using custom properties in query results
Key: SRAMP-389
URL: https://issues.jboss.org/browse/SRAMP-389
Project: S-RAMP
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 0.4.0 - Tomcat Support
Reporter: Eric Wittmann
Assignee: David virgil naranjo
Fix For: 0.5.0 - API Management
There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed.
We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list).
Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue).
I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation.
If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months