September 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (OVERLORD-130) GenerateSamlKeystoreUtil currently using three deprecated BC classes

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/OVERLORD-130?page=com.atlassian.jira.plug... ] Eric Wittmann closed OVERLORD-130. ---------------------------------- > GenerateSamlKeystoreUtil currently using three deprecated BC classes > -------------------------------------------------------------------- > > Key: OVERLORD-130 > URL: https://issues.jboss.org/browse/OVERLORD-130 > Project: Overlord > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: David virgil naranjo > > In overlord-commons we have the GenerateSamlKeystoreUtil class. This class is currently using BouncyCastle to do some keystore related stuff. It's using three deprecated classes from BC. We need to figure out a way to do this same work without using deprecated code. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (OVERLORD-130) GenerateSamlKeystoreUtil currently using three deprecated BC classes

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/OVERLORD-130?page=com.atlassian.jira.plug... ] Eric Wittmann resolved OVERLORD-130. ------------------------------------ Resolution: Done > GenerateSamlKeystoreUtil currently using three deprecated BC classes > -------------------------------------------------------------------- > > Key: OVERLORD-130 > URL: https://issues.jboss.org/browse/OVERLORD-130 > Project: Overlord > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: David virgil naranjo > > In overlord-commons we have the GenerateSamlKeystoreUtil class. This class is currently using BouncyCastle to do some keystore related stuff. It's using three deprecated classes from BC. We need to figure out a way to do this same work without using deprecated code. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-566) [resubmit] RemoteMessage#context is empty

by Michael Clay (JIRA)

[ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.... ] Michael Clay commented on RTGOV-566: ------------------------------------ another use case for this This one is required because for e.g. SOAP messages originating from a SCA binding for which there is no possibility to configure a custom ContextMapper to retrieve/extract (SOAP header) exchange properties which need to be simply passed through to some referenced service (Reference). Consider the following example application with one service with a soap and a sca binding and an implementation which simple forwards (proxies) the soap request to some referenced service (i.e. Reference in sy/sca terms). This referenced service is configured with a custom contextmapper which has the same configuration like the one on the incoming soap binding to tunnel/forward all SOAP header properties. > [resubmit] RemoteMessage#context is empty > ----------------------------------------- > > Key: RTGOV-566 > URL: https://issues.jboss.org/browse/RTGOV-566 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Michael Clay > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > because RemoteMessage#context is empty/not used there is no way to pass > properties required for the implementation of the resubmitted/retried service invocation (e.g. SOAPHeader are stored as message properties) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-569) Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0

by Michael Clay (JIRA)

[ https://issues.jboss.org/browse/RTGOV-569?page=com.atlassian.jira.plugin.... ] Michael Clay commented on RTGOV-569: ------------------------------------ reviewed/tested > Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0 > -------------------------------------------------------------------------- > > Key: RTGOV-569 > URL: https://issues.jboss.org/browse/RTGOV-569 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Related to comment on RTGOV-556 - the switchyard version used in the FSW 6.0 RTGOV UI war is 2.x where it should be 1.x. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (OVERLORD-137) Ensure cached OSGi services are removed when service bundle uninstalled

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/OVERLORD-137?page=com.atlassian.jira.plug... ] Gary Brown updated OVERLORD-137: -------------------------------- Fix Version/s: Overlord-Commons-2.0.11.Final (was: Overlord-Commons-2.0.10.Final) > Ensure cached OSGi services are removed when service bundle uninstalled > ----------------------------------------------------------------------- > > Key: OVERLORD-137 > URL: https://issues.jboss.org/browse/OVERLORD-137 > Project: Overlord > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: Overlord-Commons-2.0.11.Final > > > When services are retrieved using the getServices or getSingleService method on the ServiceRegistry(Util), they are cached for more efficient subsequent access. > The ServiceListener mechanism enables a client to be notified when services implementing a particular interface are registered or unregistered. > Either use a direct OSGi service listener, or the ServiceRegistry ServiceListener, to determine when the cached services should be removed. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (OVERLORD-138) Tests for OSGiServiceRegistry

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/OVERLORD-138?page=com.atlassian.jira.plug... ] Gary Brown updated OVERLORD-138: -------------------------------- Fix Version/s: Overlord-Commons-2.0.11.Final (was: Overlord-Commons-2.0.10.Final) > Tests for OSGiServiceRegistry > ----------------------------- > > Key: OVERLORD-138 > URL: https://issues.jboss.org/browse/OVERLORD-138 > Project: Overlord > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: Overlord-Commons-2.0.11.Final > > > Provide unit or integration tests to ensure OSGi services accessed via 'get' or service listener approach are correctly initialized and closed. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-488) Use the maven-bundle-plugin in WAR projects

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-488?page=com.atlassian.jira.plugin.... ] Work on SRAMP-488 started by Brett Meyer. ----------------------------------------- > Use the maven-bundle-plugin in WAR projects > ------------------------------------------- > > Key: SRAMP-488 > URL: https://issues.jboss.org/browse/SRAMP-488 > Project: S-RAMP > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Right now in our WAR projects we are using the war plugin to configure the manifest for osgi. Instead we should use the bundle plugin. > Links: > https://ops4j1.jira.com/wiki/display/paxweb/OSGi-fy+your+WAR > https://ops4j1.jira.com/wiki/display/ops4j/Getting+the+benefits+of+maven-... > Here is an example of using it in overlord-commons-idp: > {code} > <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> > <modelVersion>4.0.0</modelVersion> > <parent> > <groupId>org.overlord</groupId> > <artifactId>overlord-commons</artifactId> > <version>2.0.3-SNAPSHOT</version> > </parent> > <artifactId>overlord-commons-idp</artifactId> > <packaging>war</packaging> > <name>Overlord Commons: IDP</name> > <description>An identity provider using PicketLink SAML.</description> > <dependencies> >  > <dependency> > <groupId>org.picketlink</groupId> > <artifactId>picketlink-federation</artifactId> > </dependency> > <dependency> > <groupId>org.picketbox</groupId> > <artifactId>picketbox</artifactId> > </dependency> > <dependency> > <groupId>org.picketlink</groupId> > <artifactId>picketlink-federation</artifactId> > </dependency> > <dependency> > <groupId>org.jboss.logging</groupId> > <artifactId>jboss-logging</artifactId> > </dependency> > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>overlord-commons-auth</artifactId> > </dependency> > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>overlord-commons-auth-jboss7</artifactId> > </dependency> > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>overlord-commons-auth-jetty8</artifactId> > </dependency> > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>overlord-commons-auth-tomcat7</artifactId> > </dependency> >  > <dependency> > <groupId>org.jboss.spec.javax.servlet</groupId> > <artifactId>jboss-servlet-api_3.0_spec</artifactId> > <scope>provided</scope> > </dependency> > </dependencies> > <build> > <plugins> > <plugin> > <groupId>org.codehaus.mojo</groupId> > <artifactId>build-helper-maven-plugin</artifactId> > <executions> > <execution> > <id>regex-property</id> > <goals> > <goal>regex-property</goal> > </goals> > <configuration> > <name>project.version.osgi</name> > <value>${project.version}</value> > <regex>-SNAPSHOT</regex> > <replacement>.Snapshot</replacement> > <failIfNoMatch>false</failIfNoMatch> > </configuration> > </execution> > </executions> > </plugin> >  >  >  >  >  >  >  >  >  >  >  >  >  >  >  >  >  >  >  >  >  >  > <plugin> > <artifactId>maven-war-plugin</artifactId> > <configuration> > <archive> >  > <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile> > </archive> > </configuration> > </plugin> > <plugin> > <groupId>org.apache.felix</groupId> > <artifactId>maven-bundle-plugin</artifactId> > <executions> > <execution> > <id>bundle-manifest</id> > <phase>process-classes</phase> > <goals> > <goal>manifest</goal> > </goals> > </execution> > </executions> > <configuration> > <failOnMissingWebXml>false</failOnMissingWebXml> --> > <warName>${project.artifactId}</warName> > <attachClasses>true</attachClasses> > <classesClassifier>classes</classesClassifier> > <instructions> > <Bundle-ManifestVersion>2</Bundle-ManifestVersion> > <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName> > <Bundle-Version>${project.version.osgi}</Bundle-Version> > <Web-ContextPath>/overlord-idp</Web-ContextPath> > <Webapp-Context>/overlord-idp</Webapp-Context> > <Import-Package>org.apache.log4j,javax.servlet, javax.servlet.http,javax.security.auth.login,javax.xml.stream,javax.xml.stream.events,javax.xml.namespace,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform.stream,javax.xml.parsers,javax.xml.datatype,javax.xml.crypto,javax.xml.crypto.dsig,javax.xml.bind,org.apache.karaf.jaas.boot.principal,org.eclipse.jetty.plus.jaas,org.xml.sax,org.w3c.dom,org.w3c.dom.ls,org.overlord.commons.auth.util,org.picketlink.identity.federation.core.interfaces > </Import-Package> > <Bundle-ClassPath>.,WEB-INF/classes,WEB-INF/lib/commons-logging-${version.commons-logging}.jar,WEB-INF/lib/jboss-logging-${version.org.jboss.logging}.jar,WEB-INF/lib/jbossxacml-2.0.8.Final.jar,WEB-INF/lib/picketbox-${picketbox.version}.jar,WEB-INF/lib/picketlink-common-${picketlink.version}.jar,WEB-INF/lib/picketlink-config-${picketlink.version}.jar,WEB-INF/lib/picketlink-federation-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-api-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-impl-${picketlink.version}.jar,WEB-INF/lib/xmlsec-1.5.1.jar > </Bundle-ClassPath> > </instructions> > </configuration> > </plugin> > </plugins> > </build> > </project> > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-535: ----------------------------------- [~eric.wittmann], is the "deleted" artifact kept purely for auditing? If so, will reseting the UUID screw with that? Or, are the audit nodes pulled over with the "deleted" node? It looks like enabling same-name siblings for specific children is possible: http://www.day.com/specs/jcr/2.0/22_Same-Name_Siblings.html. But even so, the question is the same. How are the "deleted" artifacts used and what might the implications be? > Reset UUID of artifact when it is deleted > ----------------------------------------- > > Key: SRAMP-535 > URL: https://issues.jboss.org/browse/SRAMP-535 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one). > However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this: > {code} > A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default" > {code} > Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-558) UI: Suggest users while typing in "Created By" & "Last Modified By" fields

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-558?page=com.atlassian.jira.plugin.... ] Brett Meyer closed SRAMP-558. ----------------------------- Resolution: Won't Fix Decided against this. It'll won't be easy to parse all primary artifact nodes and find the full list of users. Attempting to pull them from the UI artifact results might be possible, but with paging you have the potential to only get a subset. All in all, lots of work for an extremely minimal gain. Rejecting. > UI: Suggest users while typing in "Created By" & "Last Modified By" fields > -------------------------------------------------------------------------- > > Key: SRAMP-558 > URL: https://issues.jboss.org/browse/SRAMP-558 > Project: S-RAMP > Issue Type: Enhancement > Components: UI > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-504) Classifier filter UI label not updated on return to page

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-504?page=com.atlassian.jira.plugin.... ] Brett Meyer resolved SRAMP-504. ------------------------------- Resolution: Done > Classifier filter UI label not updated on return to page > -------------------------------------------------------- > > Key: SRAMP-504 > URL: https://issues.jboss.org/browse/SRAMP-504 > Project: S-RAMP > Issue Type: Bug > Components: UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Steps to reproduce: > 1) Add an artifact to s-ramp > 2) Add an ontology to s-ramp > 3) Add one of the classifiers to the s-ramp artifact from (1) > 4) In the artifact listing page select the classifier from (3) in the Classifier filter section > 5) note the label is updated, for example: > {code} > Deployment Status (1 selected) > {code} > 6) click the artifact in the list (to navigate to the artifact details page) > 7) navigate back to the artifact listing page (e.g. via the breadcrumb) > 8) Bug: even though the classifier is *still* selected in the filter, the filter label now reads: > {code} > Deployment Status (0 selected) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues September 2014