From issues at jboss.org Mon Jun 1 16:38:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 1 Jun 2015 16:38:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-689) Remove the JCR persistence adapter In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-689: --------------------------------- Summary: Remove the JCR persistence adapter Key: ARTIF-689 URL: https://issues.jboss.org/browse/ARTIF-689 Project: Artificer Issue Type: Task Reporter: Brett Meyer Assignee: Brett Meyer ARTIF-683 switched to a JPA/RDBMS default persistence strategy. Originally, we intended to keep the JCR plugin and continue to maintain it, however: First and foremost, initial performance tests are looking extremely promising. With the exception of uploads (slower for JPA due to Hibernate Search indexing and complicated INSERTs, as opposed to JCR node creation), everything else is 2-5x faster, including complex queries. Further, I'm starting to hit certain dependency conflicts between Hibernate and ModeShape that might eventually require a split in Artificer distros. Maintaining both is already becoming a headache. Is there much of a point in keeping both? The only argument I can think of is if for some reason a user was integrating S-RAMP's JCR storage with their existing, *non-RDBMS* source (Cassandra, etc) through ModeShape/Infinispan. But that's highly unlikely. In my mind, everything else trumps the off-chance for backward compatibility issues. Most users we talk to see JCR purely as an implementation detail. We will, however, provide a migration strategy. It would simply be code fragments from both adapters, translating to and from the backends. Honestly simple stuff. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 1 17:02:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 1 Jun 2015 17:02:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to CMT JTA In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-690: --------------------------------- Summary: Switch to CMT JTA Key: ARTIF-690 URL: https://issues.jboss.org/browse/ARTIF-690 Project: Artificer Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer Rather than simply using JDBC transactions at the persistence level, switch to using CMT JTA at the REST/EJB level. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 1 17:03:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 1 Jun 2015 17:03:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to CMT JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072889#comment-13072889 ] Brett Meyer commented on ARTIF-690: ----------------------------------- Note that the EJB services currently include a BMT annotation! > Switch to CMT JTA > ----------------- > > Key: ARTIF-690 > URL: https://issues.jboss.org/browse/ARTIF-690 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > Rather than simply using JDBC transactions at the persistence level, switch to using CMT JTA at the REST/EJB level. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 1 17:06:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 1 Jun 2015 17:06:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to CMT JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072892#comment-13072892 ] Brett Meyer commented on ARTIF-690: ----------------------------------- WIP: https://github.com/brmeyer/s-ramp/tree/ARTIF-690 (simply the JPA config) > Switch to CMT JTA > ----------------- > > Key: ARTIF-690 > URL: https://issues.jboss.org/browse/ARTIF-690 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > Rather than simply using JDBC transactions at the persistence level, switch to using CMT JTA at the REST/EJB level. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 2 10:47:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 2 Jun 2015 10:47:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-691) Create an S-RAMP import/export utility In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-691: --------------------------------- Summary: Create an S-RAMP import/export utility Key: ARTIF-691 URL: https://issues.jboss.org/browse/ARTIF-691 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Create an Atom API client utility that allows import/export between S-RAMP implementations. This will be helpful in general. But currently important, it will allow migration to the new backend. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 2 11:16:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 2 Jun 2015 11:16:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-683 started by Brett Meyer. ----------------------------------------- > Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution > --------------------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 2 11:19:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 2 Jun 2015 11:19:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-689) Remove the JCR persistence adapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-689: ------------------------------ Fix Version/s: 1.1.0.Final 1.0.0.Beta1 > Remove the JCR persistence adapter > ---------------------------------- > > Key: ARTIF-689 > URL: https://issues.jboss.org/browse/ARTIF-689 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > ARTIF-683 switched to a JPA/RDBMS default persistence strategy. Originally, we intended to keep the JCR plugin and continue to maintain it, however: > First and foremost, initial performance tests are looking extremely promising. With the exception of uploads (slower for JPA due to Hibernate Search indexing and complicated INSERTs, as opposed to JCR node creation), everything else is 2-5x faster, including complex queries. > Further, I'm starting to hit certain dependency conflicts between Hibernate and ModeShape that might eventually require a split in Artificer distros. Maintaining both is already becoming a headache. > Is there much of a point in keeping both? The only argument I can think of is if for some reason a user was integrating S-RAMP's JCR storage with their existing, *non-RDBMS* source (Cassandra, etc) through ModeShape/Infinispan. But that's highly unlikely. In my mind, everything else trumps the off-chance for backward compatibility issues. Most users we talk to see JCR purely as an implementation detail. > We will, however, provide a migration strategy. It would simply be code fragments from both adapters, translating to and from the backends. Honestly simple stuff. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 2 11:55:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 2 Jun 2015 11:55:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-689) Remove the JCR persistence adapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-689. ------------------------------- Resolution: Done > Remove the JCR persistence adapter > ---------------------------------- > > Key: ARTIF-689 > URL: https://issues.jboss.org/browse/ARTIF-689 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > ARTIF-683 switched to a JPA/RDBMS default persistence strategy. Originally, we intended to keep the JCR plugin and continue to maintain it, however: > First and foremost, initial performance tests are looking extremely promising. With the exception of uploads (slower for JPA due to Hibernate Search indexing and complicated INSERTs, as opposed to JCR node creation), everything else is 2-5x faster, including complex queries. > Further, I'm starting to hit certain dependency conflicts between Hibernate and ModeShape that might eventually require a split in Artificer distros. Maintaining both is already becoming a headache. > Is there much of a point in keeping both? The only argument I can think of is if for some reason a user was integrating S-RAMP's JCR storage with their existing, *non-RDBMS* source (Cassandra, etc) through ModeShape/Infinispan. But that's highly unlikely. In my mind, everything else trumps the off-chance for backward compatibility issues. Most users we talk to see JCR purely as an implementation detail. > We will, however, provide a migration strategy. It would simply be code fragments from both adapters, translating to and from the backends. Honestly simple stuff. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 2 17:22:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 2 Jun 2015 17:22:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-692) Provide Apache Tika JARs in our WAR, once HSEARCH-1885 corrected In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-692: --------------------------------- Summary: Provide Apache Tika JARs in our WAR, once HSEARCH-1885 corrected Key: ARTIF-692 URL: https://issues.jboss.org/browse/ARTIF-692 Project: Artificer Issue Type: Task Reporter: Brett Meyer Assignee: Brett Meyer Until HSEARCH-1885, we need to deploy our own WF/EAP Tika module (stolen from the ModeShape distro) and force the Search module to depend on it. Once HSEARCH-1885 is corrected and we upgrade, remove tika-module.zip, configureHibernateSearch.xslt, etc. and instead provide the Tika JARs in our WAR. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 4 10:10:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Jun 2015 10:10:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-693) Move query paging into the query itself In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-693: --------------------------------- Summary: Move query paging into the query itself Key: ARTIF-693 URL: https://issues.jboss.org/browse/ARTIF-693 Project: Artificer Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer Due to JCR-SQL2's lack of paging support, paging was handled in-memory *after* the query was run. For obvious performance reasons, re-architect the setup and move into the query itself. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 5 11:20:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 5 Jun 2015 11:20:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-693) Move query paging into the query itself In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-693. ------------------------------- Fix Version/s: 1.1.0.Final 1.0.0.Beta1 Resolution: Done > Move query paging into the query itself > --------------------------------------- > > Key: ARTIF-693 > URL: https://issues.jboss.org/browse/ARTIF-693 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > Due to JCR-SQL2's lack of paging support, paging was handled in-memory *after* the query was run. For obvious performance reasons, re-architect the setup and move into the query itself. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 22:46:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 8 Jun 2015 22:46:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-679) Complete the auditing capabilities In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-679: ------------------------------ Fix Version/s: (was: 1.0.0.Beta1) > Complete the auditing capabilities > ---------------------------------- > > Key: ARTIF-679 > URL: https://issues.jboss.org/browse/ARTIF-679 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > This tracks several steps needed to "fully complete" the auditing capability, including making it useful across all interfaces. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 22:47:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 8 Jun 2015 22:47:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-681) Versioning support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-681: ------------------------------ Fix Version/s: (was: 1.0.0.Beta1) > Versioning support > ------------------ > > Key: ARTIF-681 > URL: https://issues.jboss.org/browse/ARTIF-681 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > Tracker for adding proper OOTB "versioning" support to the server and all interfaces -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 22:47:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 8 Jun 2015 22:47:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-682) Display multiple versions of an artifact through the web UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-682: ------------------------------ Fix Version/s: (was: 1.0.0.Beta1) > Display multiple versions of an artifact through the web UI > ----------------------------------------------------------- > > Key: ARTIF-682 > URL: https://issues.jboss.org/browse/ARTIF-682 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > Figure out how to effectively handle and display multiple versions of an artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 23:03:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 8 Jun 2015 23:03:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-683. ------------------------------- Fix Version/s: 1.1.0.Final 1.0.0.Beta1 Resolution: Done > Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution > --------------------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 23:03:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 8 Jun 2015 23:03:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to CMT JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-690: ------------------------------ Fix Version/s: 1.1.0.Final 1.0.0.Beta1 > Switch to CMT JTA > ----------------- > > Key: ARTIF-690 > URL: https://issues.jboss.org/browse/ARTIF-690 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > Rather than simply using JDBC transactions at the persistence level, switch to using CMT JTA at the REST/EJB level. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:28:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:28:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-692) Provide Apache Tika JARs in our WAR, once HSEARCH-1885 corrected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-692. ----------------------------- Resolution: Won't Fix > Provide Apache Tika JARs in our WAR, once HSEARCH-1885 corrected > ---------------------------------------------------------------- > > Key: ARTIF-692 > URL: https://issues.jboss.org/browse/ARTIF-692 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > > Until HSEARCH-1885, we need to deploy our own WF/EAP Tika module (stolen from the ModeShape distro) and force the Search module to depend on it. Once HSEARCH-1885 is corrected and we upgrade, remove tika-module.zip, configureHibernateSearch.xslt, etc. and instead provide the Tika JARs in our WAR. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:31:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:31:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-665) Add additional Tika text extractors for full-text searching In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-665. ----------------------------- Fix Version/s: (was: 1.1.0.Final) Resolution: Out of Date We now provide Tika and all its parsers, after having switched to Hibernate Search > Add additional Tika text extractors for full-text searching > ----------------------------------------------------------- > > Key: ARTIF-665 > URL: https://issues.jboss.org/browse/ARTIF-665 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > ModeShape's tika extractors include several useful defaults. However, consider adding additional extractors, at least for each built-in plugin. For example, the XML extractor considers element *values* only. Under certain circumstances (XSD types, SwitchYard, etc.), element attributes will be vital. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:32:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:32:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-664) Queries with relationship predicates fail on EAP 6.2-6.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-664. ----------------------------- Resolution: Out of Date Artificer has switched to RDBMS/JPA persistence > Queries with relationship predicates fail on EAP 6.2-6.4 > -------------------------------------------------------- > > Key: ARTIF-664 > URL: https://issues.jboss.org/browse/ARTIF-664 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > > Example: > {code} > /s-ramp[expandedFromDocument] > {code} > JCR-SQL2: > {code} > SELECT artifact1.* FROM [sramp:baseArtifactType] AS artifact1 WHERE > artifact1.[jcr:uuid] IN > (SELECT artifact2.[jcr:uuid] AS uuid FROM [sramp:relationship] AS relationship1 > INNER JOIN [sramp:baseArtifactType] AS artifact2 ON ISCHILDNODE(relationship1,artifact2) > WHERE (relationship1.[sramp:relationshipType] = 'expandedFromDocument' AND ISDESCENDANTNODE(relationship1,'/s-ramp'))) > AND ISDESCENDANTNODE(artifact1,'/s-ramp') ORDER BY artifact1.[sramp:name] ASC > {code} > The query simply returns nothing. Works perfectly for Wildfly 8 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:32:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:32:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-642) Move pagination support to the JCR queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-642. ----------------------------- Resolution: Out of Date Artificer has switched to RDBMS/JPA persistence > Move pagination support to the JCR queries > ------------------------------------------ > > Key: ARTIF-642 > URL: https://issues.jboss.org/browse/ARTIF-642 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > Pagination currently (naively) runs the entire query, then pages *in memory*. Instead, add the pagination params to the JCR query itself. Will also need to introduce the ability to query for count(), *without* pagination, in order to return a total #. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:32:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:32:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-658) Upgrade to ModeShape 4.3.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-658. ----------------------------- Resolution: Out of Date Artificer has switched to RDBMS/JPA persistence > Upgrade to ModeShape 4.3.0 > -------------------------- > > Key: ARTIF-658 > URL: https://issues.jboss.org/browse/ARTIF-658 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:33:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:33:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-512) Cleanup and improve all datasources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-512. ----------------------------- Resolution: Out of Date > Cleanup and improve all datasources > ----------------------------------- > > Key: ARTIF-512 > URL: https://issues.jboss.org/browse/ARTIF-512 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > Connection pooling, stale connection testing, etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:34:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:34:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-552) Support relationships with no target In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-552: ------------------------------ Description: 2.1.2 "It is possible for a relationship of a given Relationship Type not to have a target, which is termed a "relationship with no targets". In this case there is only one relationship instance with that Relationship Type for a given Source. Such relationships have a target cardinality of "0". If there is a relationship instance with a given Relationship Type that does have a target, then there CANNOT also be a relationship instance with that Relationship Type which has no target." was: 2.1.2 "It is possible for a relationship of a given Relationship Type not to have a target, which is termed a "relationship with no targets". In this case there is only one relationship instance with that Relationship Type for a given Source. Such relationships have a target cardinality of "0". If there is a relationship instance with a given Relationship Type that does have a target, then there CANNOT also be a relationship instance with that Relationship Type which has no target." Currently, this causes: {code} Caused by: javax.jcr.PathNotFoundException: No item exists at path sramp:relationshipType relative to /s-ramp/artifacts/4a/97/7b/bd-ab9b-4f00-b7b5-25f62f04eb45/sramp-relationships:null in workspace "default" at org.modeshape.jcr.AbstractJcrNode.getProperty(AbstractJcrNode.java:346) at org.modeshape.jcr.AbstractJcrNode.getProperty(AbstractJcrNode.java:108) at org.overlord.sramp.repository.jcr.mapper.ArtifactToJCRNodeVisitor.updateGenericRelationships(ArtifactToJCRNodeVisitor.java:267) at org.overlord.sramp.repository.jcr.mapper.ArtifactToJCRNodeVisitor.visitBase(ArtifactToJCRNodeVisitor.java:128) at org.overlord.sramp.common.visitors.HierarchicalArtifactVisitorAdapter.visit(HierarchicalArtifactVisitorAdapter.java:209) at org.overlord.sramp.repository.jcr.mapper.ArtifactToJCRNodeVisitor.visit(ArtifactToJCRNodeVisitor.java:310) at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.overlord.sramp.common.visitors.ArtifactVisitorHelper.visitArtifact(ArtifactVisitorHelper.java:41) at org.overlord.sramp.repository.jcr.JCRArtifactPersister.persistArtifactPhase1(JCRArtifactPersister.java:138) at org.overlord.sramp.repository.jcr.JCRPersistence.persistArtifact(JCRPersistence.java:177) ... 47 more {code} > Support relationships with no target > ------------------------------------ > > Key: ARTIF-552 > URL: https://issues.jboss.org/browse/ARTIF-552 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > 2.1.2 > "It is possible for a relationship of a given Relationship Type not to have a target, which is termed a "relationship with no targets". In this case there is only one relationship instance with that Relationship Type for a given Source. Such relationships have a target cardinality of "0". If there is a relationship instance with a given Relationship Type that does have a target, then there CANNOT also be a relationship instance with that Relationship Type which has no target." -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:36:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:36:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-655) Allow users to provide their own query indexes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-655. ----------------------------- Resolution: Out of Date Artificer has switched to RDBMS/JPA persistence > Allow users to provide their own query indexes > ---------------------------------------------- > > Key: ARTIF-655 > URL: https://issues.jboss.org/browse/ARTIF-655 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Through ModeShape's Workspace#getIndexManager(), allow users to provide their own query indexes during startup/runtime. If they know specific queries they may frequently run, this could be a helpful optimization. > In addition, attempt to automatically create indexes for StoredQueries when they're first added. Logic would need to pull out the artifact type, column, etc. > Note that the MS local index currently supports single-column indexes only. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:36:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:36:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-645) Allow users to supply extensions through a new plugin architecture In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-645: ------------------------------ Description: The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: - extension contract impls (ArtifactBuilder, TypeDetector, etc.) - JPA entities - UI elements (custom metadata displays, custom actions, etc.) - endpoint bindings (again, /s-ramp/model/type) Eric's demo: https://bluejeans.com/s/82tW/ was: The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: - extension contract impls (ArtifactBuilder, TypeDetector, etc.) - JCR node types (assuming we're able to change the spec to allow /s-ramp/[custom model]/[custom type] - UI elements (custom metadata displays, custom actions, etc.) - endpoint bindings (again, /s-ramp/model/type) Eric's demo: https://bluejeans.com/s/82tW/ > Allow users to supply extensions through a new plugin architecture > ------------------------------------------------------------------ > > Key: ARTIF-645 > URL: https://issues.jboss.org/browse/ARTIF-645 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: > - extension contract impls (ArtifactBuilder, TypeDetector, etc.) > - JPA entities > - UI elements (custom metadata displays, custom actions, etc.) > - endpoint bindings (again, /s-ramp/model/type) > Eric's demo: https://bluejeans.com/s/82tW/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:36:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:36:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-227) Allow derivers to define and use custom node types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-227: ------------------------------ Parent: (was: ARTIF-645) Issue Type: Feature Request (was: Sub-task) > Allow derivers to define and use custom node types > -------------------------------------------------- > > Key: ARTIF-227 > URL: https://issues.jboss.org/browse/ARTIF-227 > Project: Artificer > Issue Type: Feature Request > Reporter: Randall Hauch > Assignee: Brett Meyer > > Presently, any content produced by a deriver is stored in the JCR repository with S-RAMP-defined node types, and it is not possible for a deriver to use custom or domain-specific node types or mixins. > This enhancement would allow derivers to define such domain-specific node types and/or mixins, and to produce content that uses these node types. This would allow directly querying the underlying JCR repository using JCR-SQL (which is based very much on using specific node types and mixins). > Granted, it may be very difficult to abstract the JCR-ness of the custom node types, especially during content creation. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:36:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:36:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-227) Allow derivers to define and use custom node types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-227. ----------------------------- Resolution: Out of Date Artificer has switched to RDBMS/JPA persistence > Allow derivers to define and use custom node types > -------------------------------------------------- > > Key: ARTIF-227 > URL: https://issues.jboss.org/browse/ARTIF-227 > Project: Artificer > Issue Type: Feature Request > Reporter: Randall Hauch > Assignee: Brett Meyer > > Presently, any content produced by a deriver is stored in the JCR repository with S-RAMP-defined node types, and it is not possible for a deriver to use custom or domain-specific node types or mixins. > This enhancement would allow derivers to define such domain-specific node types and/or mixins, and to produce content that uses these node types. This would allow directly querying the underlying JCR repository using JCR-SQL (which is based very much on using specific node types and mixins). > Granted, it may be very difficult to abstract the JCR-ness of the custom node types, especially during content creation. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 00:37:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 00:37:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-616) Verify we're not vulnerable to injection attacks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-616. ----------------------------- Resolution: Out of Date Artificer has switched to RDBMS/JPA persistence > Verify we're not vulnerable to injection attacks > ------------------------------------------------ > > Key: ARTIF-616 > URL: https://issues.jboss.org/browse/ARTIF-616 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > Verify that no JCR-SQL2 queries are vulnerable to injection attacks -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:17:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 10:17:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-694) Create a new data model for restful services In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-694: --------------------------------- Summary: Create a new data model for restful services Key: ARTIF-694 URL: https://issues.jboss.org/browse/ARTIF-694 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.1.0.Final -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:19:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 10:19:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-688) Create an ArtifactBuilder for Swagger files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-688: ------------------------------ Parent: ARTIF-694 Issue Type: Sub-task (was: Feature Request) > Create an ArtifactBuilder for Swagger files > ------------------------------------------- > > Key: ARTIF-688 > URL: https://issues.jboss.org/browse/ARTIF-688 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > An an artifact type and deriver for Swagger REST API files -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:19:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 10:19:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-404) Create an ArtifactBuilder for WADL files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-404: ------------------------------ Parent: ARTIF-694 Issue Type: Sub-task (was: Feature Request) > Create an ArtifactBuilder for WADL files > ---------------------------------------- > > Key: ARTIF-404 > URL: https://issues.jboss.org/browse/ARTIF-404 > Project: Artificer > Issue Type: Sub-task > Components: Core > Reporter: Eric Wittmann > Assignee: Brett Meyer > > We currently have Derivers for WSDL and related SOA artifact types, but it would be nice to have a Deriver for WADL files. > This feature request initiated from: > https://community.jboss.org/message/869323 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:20:14 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 10:20:14 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-675) Replace the S-RAMP SOA/ServiceImpl model with something comprehensive for "services" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-675: ------------------------------ Summary: Replace the S-RAMP SOA/ServiceImpl model with something comprehensive for "services" (was: Define new "service" model) > Replace the S-RAMP SOA/ServiceImpl model with something comprehensive for "services" > ------------------------------------------------------------------------------------ > > Key: ARTIF-675 > URL: https://issues.jboss.org/browse/ARTIF-675 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Define a new, generic model to better encapsulate "services", discovery, and re-use. Arguably, some of this should probably be added to the core, base model as well. > Ideas (from various sources): > - Provides a catalog of information, what services exist and are available for use > - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. > - Provides information about the version of the services > - Allows you to record and retrieve multiple versions of the same service > - Allows you to dynamically refer to the latest version of the service > - Allows dynamically at runtime to search and select end-point chosen service > - Collects information who and what services are used > - Provides information that services are repeatedly used and which are not > - Determining the impact of changes the services to existing dependent services > - Providing information to consumers of the services about ongoing or planned changes to of the services > - Identify the environments (OS, app server, etc.) supported by the artifact > - Differentiate between front and back end artifacts > - Security: what version of SSL is used, etc. (extremely valuable for security audits) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:22:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 10:22:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-675) Replace the S-RAMP SOA/ServiceImpl model with something comprehensive for "services" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-675: ------------------------------ Description: Define a new, generic, logical metadata-only model to better encapsulate "services", discovery, and re-use. This should use *some* of the concepts in S-RAMP's SOA/ServiceImplementation models. Arguably, some concepts should probably be rolled into the core Artifact model as well. Ideas (from various sources): - Provides a catalog of information, what services exist and are available for use - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. - Provides information about the version of the services - Allows you to record and retrieve multiple versions of the same service - Allows you to dynamically refer to the latest version of the service - Allows dynamically at runtime to search and select end-point chosen service - Collects information who and what services are used - Provides information that services are repeatedly used and which are not - Determining the impact of changes the services to existing dependent services - Providing information to consumers of the services about ongoing or planned changes to of the services - Identify the environments (OS, app server, etc.) supported by the artifact - Differentiate between front and back end artifacts - Security: what version of SSL is used, etc. (extremely valuable for security audits) was: Define a new, generic model to better encapsulate "services", discovery, and re-use. Arguably, some of this should probably be added to the core, base model as well. Ideas (from various sources): - Provides a catalog of information, what services exist and are available for use - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. - Provides information about the version of the services - Allows you to record and retrieve multiple versions of the same service - Allows you to dynamically refer to the latest version of the service - Allows dynamically at runtime to search and select end-point chosen service - Collects information who and what services are used - Provides information that services are repeatedly used and which are not - Determining the impact of changes the services to existing dependent services - Providing information to consumers of the services about ongoing or planned changes to of the services - Identify the environments (OS, app server, etc.) supported by the artifact - Differentiate between front and back end artifacts - Security: what version of SSL is used, etc. (extremely valuable for security audits) > Replace the S-RAMP SOA/ServiceImpl model with something comprehensive for "services" > ------------------------------------------------------------------------------------ > > Key: ARTIF-675 > URL: https://issues.jboss.org/browse/ARTIF-675 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Define a new, generic, logical metadata-only model to better encapsulate "services", discovery, and re-use. This should use *some* of the concepts in S-RAMP's SOA/ServiceImplementation models. Arguably, some concepts should probably be rolled into the core Artifact model as well. > Ideas (from various sources): > - Provides a catalog of information, what services exist and are available for use > - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. > - Provides information about the version of the services > - Allows you to record and retrieve multiple versions of the same service > - Allows you to dynamically refer to the latest version of the service > - Allows dynamically at runtime to search and select end-point chosen service > - Collects information who and what services are used > - Provides information that services are repeatedly used and which are not > - Determining the impact of changes the services to existing dependent services > - Providing information to consumers of the services about ongoing or planned changes to of the services > - Identify the environments (OS, app server, etc.) supported by the artifact > - Differentiate between front and back end artifacts > - Security: what version of SSL is used, etc. (extremely valuable for security audits) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:23:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 10:23:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-675) Replace the S-RAMP SOA/ServiceImpl model with something comprehensive for "services" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-675: ------------------------------ Parent: ARTIF-694 Issue Type: Sub-task (was: Feature Request) > Replace the S-RAMP SOA/ServiceImpl model with something comprehensive for "services" > ------------------------------------------------------------------------------------ > > Key: ARTIF-675 > URL: https://issues.jboss.org/browse/ARTIF-675 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > Define a new, generic, logical metadata-only model to better encapsulate "services", discovery, and re-use. This should use *some* of the concepts in S-RAMP's SOA/ServiceImplementation models. Arguably, some concepts should probably be rolled into the core Artifact model as well. > Ideas (from various sources): > - Provides a catalog of information, what services exist and are available for use > - Presents the condition of the service lifecycle is eg. Implemented, testing, advised against, etc. > - Provides information about the version of the services > - Allows you to record and retrieve multiple versions of the same service > - Allows you to dynamically refer to the latest version of the service > - Allows dynamically at runtime to search and select end-point chosen service > - Collects information who and what services are used > - Provides information that services are repeatedly used and which are not > - Determining the impact of changes the services to existing dependent services > - Providing information to consumers of the services about ongoing or planned changes to of the services > - Identify the environments (OS, app server, etc.) supported by the artifact > - Differentiate between front and back end artifacts > - Security: what version of SSL is used, etc. (extremely valuable for security audits) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:47:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 10:47:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-695) Refactor the file storage service In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-695: --------------------------------- Summary: Refactor the file storage service Key: ARTIF-695 URL: https://issues.jboss.org/browse/ARTIF-695 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer JDBC Blob vs filesystem storage is currently tightly coupled to the JPA plugin. Pull out into a separate contract. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:48:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 10:48:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-696) Support Ceph for file storage In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-696: --------------------------------- Summary: Support Ceph for file storage Key: ARTIF-696 URL: https://issues.jboss.org/browse/ARTIF-696 Project: Artificer Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:48:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 10:48:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-697) Support Gluster for file storage In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-697: --------------------------------- Summary: Support Gluster for file storage Key: ARTIF-697 URL: https://issues.jboss.org/browse/ARTIF-697 Project: Artificer Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 11:06:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 11:06:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-695) Refactor the file storage service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-695: ------------------------------ Description: JDBC Blob vs filesystem storage is currently tightly coupled to the JPA plugin. Pull out into a separate contract (strategy registration pattern) (was: JDBC Blob vs filesystem storage is currently tightly coupled to the JPA plugin. Pull out into a separate contract.) > Refactor the file storage service > --------------------------------- > > Key: ARTIF-695 > URL: https://issues.jboss.org/browse/ARTIF-695 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > JDBC Blob vs filesystem storage is currently tightly coupled to the JPA plugin. Pull out into a separate contract (strategy registration pattern) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 12:04:05 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 12:04:05 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to CMT JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-690: ------------------------------ Fix Version/s: (was: 1.0.0.Beta1) > Switch to CMT JTA > ----------------- > > Key: ARTIF-690 > URL: https://issues.jboss.org/browse/ARTIF-690 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > Rather than simply using JDBC transactions at the persistence level, switch to using CMT JTA at the REST/EJB level. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 12:39:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 12:39:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-657) Remove updateContent and deleteContent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-657: ------------------------------ Summary: Remove updateContent and deleteContent (was: Remove updateContent capability) > Remove updateContent and deleteContent > -------------------------------------- > > Key: ARTIF-657 > URL: https://issues.jboss.org/browse/ARTIF-657 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > In the middle of ImpactAnalysisDemo, after all artifacts and relationships have been created, run updateContent on the XSD, using the same .xsd file. The demo will still run successfully. But when finished, pull up the UI and hit one of the Part 'parameter" artifacts, then hit their Relationship tab. It fails, most likely because the relationship wasn't re-created. > Not sure how to handle that. Should the relationships really be re-generated? If so, what happens if, for example, a WSDL Part uses a type that's been modified or removed? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 12:40:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 12:40:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-657) Remove updateContent and deleteContent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-657. ------------------------------- Resolution: Done > Remove updateContent and deleteContent > -------------------------------------- > > Key: ARTIF-657 > URL: https://issues.jboss.org/browse/ARTIF-657 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > In the middle of ImpactAnalysisDemo, after all artifacts and relationships have been created, run updateContent on the XSD, using the same .xsd file. The demo will still run successfully. But when finished, pull up the UI and hit one of the Part 'parameter" artifacts, then hit their Relationship tab. It fails, most likely because the relationship wasn't re-created. > Not sure how to handle that. Should the relationships really be re-generated? If so, what happens if, for example, a WSDL Part uses a type that's been modified or removed? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 12:42:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 12:42:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-669) Document bulk operations through S-RAMP archives In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-669: ------------------------------ Fix Version/s: (was: 1.1.0.Final) (was: 1.0.0.Beta1) > Document bulk operations through S-RAMP archives > ------------------------------------------------ > > Key: ARTIF-669 > URL: https://issues.jboss.org/browse/ARTIF-669 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 21:21:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 21:21:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-657) Remove updateContent and deleteContent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-657. ----------------------------- > Remove updateContent and deleteContent > -------------------------------------- > > Key: ARTIF-657 > URL: https://issues.jboss.org/browse/ARTIF-657 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > In the middle of ImpactAnalysisDemo, after all artifacts and relationships have been created, run updateContent on the XSD, using the same .xsd file. The demo will still run successfully. But when finished, pull up the UI and hit one of the Part 'parameter" artifacts, then hit their Relationship tab. It fails, most likely because the relationship wasn't re-created. > Not sure how to handle that. Should the relationships really be re-generated? If so, what happens if, for example, a WSDL Part uses a type that's been modified or removed? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 21:21:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 21:21:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-689) Remove the JCR persistence adapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-689. ----------------------------- > Remove the JCR persistence adapter > ---------------------------------- > > Key: ARTIF-689 > URL: https://issues.jboss.org/browse/ARTIF-689 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > ARTIF-683 switched to a JPA/RDBMS default persistence strategy. Originally, we intended to keep the JCR plugin and continue to maintain it, however: > First and foremost, initial performance tests are looking extremely promising. With the exception of uploads (slower for JPA due to Hibernate Search indexing and complicated INSERTs, as opposed to JCR node creation), everything else is 2-5x faster, including complex queries. > Further, I'm starting to hit certain dependency conflicts between Hibernate and ModeShape that might eventually require a split in Artificer distros. Maintaining both is already becoming a headache. > Is there much of a point in keeping both? The only argument I can think of is if for some reason a user was integrating S-RAMP's JCR storage with their existing, *non-RDBMS* source (Cassandra, etc) through ModeShape/Infinispan. But that's highly unlikely. In my mind, everything else trumps the off-chance for backward compatibility issues. Most users we talk to see JCR purely as an implementation detail. > We will, however, provide a migration strategy. It would simply be code fragments from both adapters, translating to and from the backends. Honestly simple stuff. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 21:21:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 21:21:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-311) Add support for comments associated with an Artifact In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-311. ----------------------------- > Add support for comments associated with an Artifact > ---------------------------------------------------- > > Key: ARTIF-311 > URL: https://issues.jboss.org/browse/ARTIF-311 > Project: Artificer > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > Add a UI around commenting on artifacts in the repository. Each comment should be its own artifact in the repository with a relationship to the artifact being discussed. The artifact type should be something like: > /ext/ArtifactComment -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 21:21:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 21:21:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-683. ----------------------------- > Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution > --------------------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 21:21:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 21:21:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-678) Allow "forced" deletion of artifacts with no constraint checks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-678. ----------------------------- > Allow "forced" deletion of artifacts with no constraint checks > -------------------------------------------------------------- > > Key: ARTIF-678 > URL: https://issues.jboss.org/browse/ARTIF-678 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 21:21:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 21:21:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-324) UI: Edit artifact relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-324. ----------------------------- > UI: Edit artifact relationships > ------------------------------- > > Key: ARTIF-324 > URL: https://issues.jboss.org/browse/ARTIF-324 > Project: Artificer > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > Provide a way for the user to manage the relationships on the artifact. The user should be able to add and remove relationships. Note that some relationships are derived and thus cannot be removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 21:21:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 21:21:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-693) Move query paging into the query itself In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-693. ----------------------------- > Move query paging into the query itself > --------------------------------------- > > Key: ARTIF-693 > URL: https://issues.jboss.org/browse/ARTIF-693 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final, 1.0.0.Beta1 > > > Due to JCR-SQL2's lack of paging support, paging was handled in-memory *after* the query was run. For obvious performance reasons, re-architect the setup and move into the query itself. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:25:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:25:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-689) Remove the JCR persistence adapter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-689: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Remove the JCR persistence adapter > ---------------------------------- > > Key: ARTIF-689 > URL: https://issues.jboss.org/browse/ARTIF-689 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta1 > > > ARTIF-683 switched to a JPA/RDBMS default persistence strategy. Originally, we intended to keep the JCR plugin and continue to maintain it, however: > First and foremost, initial performance tests are looking extremely promising. With the exception of uploads (slower for JPA due to Hibernate Search indexing and complicated INSERTs, as opposed to JCR node creation), everything else is 2-5x faster, including complex queries. > Further, I'm starting to hit certain dependency conflicts between Hibernate and ModeShape that might eventually require a split in Artificer distros. Maintaining both is already becoming a headache. > Is there much of a point in keeping both? The only argument I can think of is if for some reason a user was integrating S-RAMP's JCR storage with their existing, *non-RDBMS* source (Cassandra, etc) through ModeShape/Infinispan. But that's highly unlikely. In my mind, everything else trumps the off-chance for backward compatibility issues. Most users we talk to see JCR purely as an implementation detail. > We will, however, provide a migration strategy. It would simply be code fragments from both adapters, translating to and from the backends. Honestly simple stuff. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:25:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:25:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-693) Move query paging into the query itself In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-693: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Move query paging into the query itself > --------------------------------------- > > Key: ARTIF-693 > URL: https://issues.jboss.org/browse/ARTIF-693 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta1 > > > Due to JCR-SQL2's lack of paging support, paging was handled in-memory *after* the query was run. For obvious performance reasons, re-architect the setup and move into the query itself. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:25:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:25:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-683) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-683: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache as the default persistence solution > --------------------------------------------------------------------------------------------------------------------- > > Key: ARTIF-683 > URL: https://issues.jboss.org/browse/ARTIF-683 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta1 > > > Artificer currently uses ModeShape + Infinispan + JDBC as its storage. Back when Artificer was a simple S-RAMP impl, JCR made a lot of sense. The S-RAMP spec is essentially a hierarchical artifact repo that maintains the node metadata and relationships between them. However, the "hierarchical" bit is overstated -- it's limited to a primary artifact and its derived artifact (ex -- primary: XSD, derived: type declarations). So, the hierarchy is at most 2 levels and could be represented by a simple relationship or one-to-one foreign key. The only time the hierarchical structure is helpful is when we look up an artifact by its UUID (due to a specific tree structure we use). But otherwise, I think it's a bit of a misnomer. > We're now extending well beyond S-RAMP. In addition to an artifact/metadata/info repo, we're trying to position the project as a more general repo for multiple projects and service information. Most importantly, the relationship requirements will expand the most. As such, I'm thinking we'd be better served by alternatives. > Note that this is essentially a read-intensive system. Writes do of course occur, but they're almost always *additions*. Nodes are rarely updated once created. Locking and isolation should be used, but can be extremely optimistic. Also note that most artifacts have files with them. That currently uses a local filesystem store through ISPN, but could certainly be NAS. > Additional fuel for the fire: many enterprise-level development shops have millions of artifacts, exponentially higher once derivation kicks in. Further, many have multiple relationships defined. > Ideas: > 1.) Switch to RDBMS, JPA (Hibernate), Hibernate Search, and Hibernate 2nd Level Cache. Although the structure originally looked JCR-specific, it may make a lot more sense as a relational DB. HSearch is a no brainer -- the full-text search capability would be vastly improved, right out of the box. And the RDBMS + in-memory-cache would be perfect for the read-intensive environment and scalability. > 2.) Graph databases: Neo4j (w/ or w/o Hibernate OGM), OrientDB, etc.. The concern here is mainly horizontal scaling and, from what I understand, their (lack of adequate) clustering support. But, it's definitely an option. > 3.) Distributed but strongly consistent database: RocksDB (a variant of LevelDB), CockroachDB. These are newer, but can (theoretically) scale larger than relational, and because they replicate data it might be more durable or at least recover faster in the event of failure. On the other hand, this may be more difficult for enterprises to adopt > 3.) Stick with MS + ISPN, but use Cassandra behind it (instead of JDBC). Arguably, this wouldn't really change things and could potentially end up worse. > 4.) Tinkerpop/Blueprints (graph API). Hawkular is using this. However, from what I've heard elsewhere, it's a horrible standard. Solutions that attempt to implement it end up in a state of twisted adaptation, resulting in performance hits. > In the end, I'd argue that #1 is the best from enterprise-level, scalability, reliability, and configurability standpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:25:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:25:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-678) Allow "forced" deletion of artifacts with no constraint checks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-678: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Allow "forced" deletion of artifacts with no constraint checks > -------------------------------------------------------------- > > Key: ARTIF-678 > URL: https://issues.jboss.org/browse/ARTIF-678 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:25:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:25:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-668) Upgrade to Errai 3.1.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-668: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Upgrade to Errai 3.1.2 > ---------------------- > > Key: ARTIF-668 > URL: https://issues.jboss.org/browse/ARTIF-668 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:25:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:25:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-663) UI: Delete Artifact is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-663: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > UI: Delete Artifact is broken > ----------------------------- > > Key: ARTIF-663 > URL: https://issues.jboss.org/browse/ARTIF-663 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha2 > > > Deleting an artifact, through the UI's artifact details view, is broken: > "org.jboss.errai.enterprise.client.jaxrs.api.ResponseException: Unsupported Media Type" > When correcting, think through how constraint violations should look. Maybe just throw it and let the error message come up? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:25:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:25:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-662) Upgrade to Aesh 0.59 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-662: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Upgrade to Aesh 0.59 > -------------------- > > Key: ARTIF-662 > URL: https://issues.jboss.org/browse/ARTIF-662 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha2 > > > Aesh 0.58 corrects many issues found during the Artificer CLI re-write. When available, upgrade and re-test. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-661) Add "create artifact" button to UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-661: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Add "create artifact" button to UI > ---------------------------------- > > Key: ARTIF-661 > URL: https://issues.jboss.org/browse/ARTIF-661 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha2 > > > The UI currently supports uploading artifact files. Add the ability to create logical, metadata-only artifacts as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-660) Embed ant in installer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-660: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Embed ant in installer > ---------------------- > > Key: ARTIF-660 > URL: https://issues.jboss.org/browse/ARTIF-660 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha2 > > > To simplify the docker image, embed ant in the installer (similar to RTGov) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-656) Cannot query with 2 relationship predicates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-656: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Cannot query with 2 relationship predicates > ------------------------------------------- > > Key: ARTIF-656 > URL: https://issues.jboss.org/browse/ARTIF-656 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha2 > > > Example: > {code} > /s-ramp/wsdl/Part[relatedDocument[@uuid = '%1$s'] and element] > {code} > That currently results in something like: > {code} > SELECT artifact1.* FROM [sramp:baseArtifactType] AS artifact1 > INNER JOIN [sramp:relationship] AS relationship2 ON ISCHILDNODE(relationship2,artifact1) > INNER JOIN [sramp:target] AS target3 ON ISCHILDNODE(target3,relationship2) > INNER JOIN [sramp:baseArtifactType] AS artifact4 ON target3.[sramp:targetArtifact] = artifact4.[jcr:uuid] > INNER JOIN [sramp:relationship] AS relationship5 ON ISCHILDNODE(relationship5,artifact1) > WHERE > artifact1.[sramp:artifactType] = 'Part' > AND relationship2.[sramp:relationshipType] = 'relatedDocument' > AND artifact4.[sramp:uuid] = 'cea13510-e7a6-4195-a18e-c091eb5a939e' > AND relationship5.[sramp:relationshipType] = 'element' > AND ISDESCENDANTNODE([sramp:baseArtifactType],'/s-ramp' > {code} > Since we use an artifact -> relationship -> target structure, and since ModeShape doesn't allow you to use the selectors transitively (ie, can't use "artifact1" in a subselect), inner joins were the method used. Each time a relationship predicate is hit, the parser assumes "I need to join and add a condition". > Forgetting the parser, for a moment, I'm not sure what the eventual query should look like... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-657) Remove updateContent and deleteContent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-657: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Remove updateContent and deleteContent > -------------------------------------- > > Key: ARTIF-657 > URL: https://issues.jboss.org/browse/ARTIF-657 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta1 > > > In the middle of ImpactAnalysisDemo, after all artifacts and relationships have been created, run updateContent on the XSD, using the same .xsd file. The demo will still run successfully. But when finished, pull up the UI and hit one of the Part 'parameter" artifacts, then hit their Relationship tab. It fails, most likely because the relationship wasn't re-created. > Not sure how to handle that. Should the relationships really be re-generated? If so, what happens if, for example, a WSDL Part uses a type that's been modified or removed? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-464) Docker image In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-464: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Docker image > ------------ > > Key: ARTIF-464 > URL: https://issues.jboss.org/browse/ARTIF-464 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-324) UI: Edit artifact relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-324: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > UI: Edit artifact relationships > ------------------------------- > > Key: ARTIF-324 > URL: https://issues.jboss.org/browse/ARTIF-324 > Project: Artificer > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 1.0.0.Beta1 > > > Provide a way for the user to manage the relationships on the artifact. The user should be able to add and remove relationships. Note that some relationships are derived and thus cannot be removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-311) Add support for comments associated with an Artifact In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-311: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Add support for comments associated with an Artifact > ---------------------------------------------------- > > Key: ARTIF-311 > URL: https://issues.jboss.org/browse/ARTIF-311 > Project: Artificer > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 1.0.0.Beta1 > > > Add a UI around commenting on artifacts in the repository. Each comment should be its own artifact in the repository with a relationship to the artifact being discussed. The artifact type should be something like: > /ext/ArtifactComment -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-310) Import Artifact dialog - only enable submit button once a file is selected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-310: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Import Artifact dialog - only enable submit button once a file is selected > -------------------------------------------------------------------------- > > Key: ARTIF-310 > URL: https://issues.jboss.org/browse/ARTIF-310 > Project: Artificer > Issue Type: Feature Request > Components: UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha2 > > > The Submit (labeled "Import") button should only be enabled once the user has selected a file. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-260) Free Text Search for artifacts Enhancement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-260: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > Free Text Search for artifacts Enhancement > ------------------------------------------ > > Key: ARTIF-260 > URL: https://issues.jboss.org/browse/ARTIF-260 > Project: Artificer > Issue Type: Feature Request > Components: Client > Environment: N/A > Reporter: Cojan van Ballegooijen > Assignee: Brett Meyer > Fix For: 1.0.0.Alpha2 > > > Support free-text searching through any client. Expand "xp2:matches" to support a "." value. > /s-ramp[xp2:matches(., '.*foo.*')] == find all artifacts that have "foo" in *any* metadata. > Further expand the above to include artifact *content*. We'll need to make use of ModeShape full text searching, as well as its support for Tika text extractors. > In addition, we should consider allowing searches through a content-specific value. Something like: /s-ramp[xp2:matches(@content, '.*foo.*')] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 22:26:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Jun 2015 22:26:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-202) The not() function doesn't quite work with relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-202: ------------------------------ Fix Version/s: (was: 1.1.0.Final) > The not() function doesn't quite work with relationships > -------------------------------------------------------- > > Key: ARTIF-202 > URL: https://issues.jboss.org/browse/ARTIF-202 > Project: Artificer > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Minor > Fix For: 1.0.0.Alpha2 > > > The not() function works well with properties, but not quite with relationships. An example of what doesn't work: > /s-ramp/wsdl/Part[not(element)] > That should return all Parts that do *not* have an element relationship. Since relationships are found by doing a JOIN, it's actually tricky to invert. Right now I think the query engine will produce something that would return all Parts that have some *other* relationship - but it won't return Parts without any relationships at all. I'm not sure how to do the latter other than by using an IN with a subquery (which is supported by ModeShape but is non-standard). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 11:45:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 10 Jun 2015 11:45:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-698) Installer should allow Wildfly auto-download In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-698: --------------------------------- Summary: Installer should allow Wildfly auto-download Key: ARTIF-698 URL: https://issues.jboss.org/browse/ARTIF-698 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 11:46:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 10 Jun 2015 11:46:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-698) Installer should allow Wildfly auto-download In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-698: ------------------------------ Fix Version/s: 1.0.0.Beta2 > Installer should allow Wildfly auto-download > -------------------------------------------- > > Key: ARTIF-698 > URL: https://issues.jboss.org/browse/ARTIF-698 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 11:47:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 10 Jun 2015 11:47:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-699) Installer echos the admin password back in plain text In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-699: --------------------------------- Summary: Installer echos the admin password back in plain text Key: ARTIF-699 URL: https://issues.jboss.org/browse/ARTIF-699 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Obscure it -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 12:03:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 10 Jun 2015 12:03:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-700) Minor UI fixes for 1.0.0 In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-700: --------------------------------- Summary: Minor UI fixes for 1.0.0 Key: ARTIF-700 URL: https://issues.jboss.org/browse/ARTIF-700 Project: Artificer Issue Type: Enhancement Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 - the source text box can be taller now that Overview is a separate tab -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 12:08:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 10 Jun 2015 12:08:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-701) 'relatedDocument' not shown in web UI's reverse relationshisp In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-701: --------------------------------- Summary: 'relatedDocument' not shown in web UI's reverse relationshisp Key: ARTIF-701 URL: https://issues.jboss.org/browse/ARTIF-701 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Since 'relatedDocument' is not a part of the general purpose 'relationships' field (ie, we define a separate 'derivedFrom' FK), it's not shown on the web UI's reverse relationships. Manually add it. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 12:16:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 10 Jun 2015 12:16:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-702) CLI: first use of getMetaData is slow In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-702: --------------------------------- Summary: CLI: first use of getMetaData is slow Key: ARTIF-702 URL: https://issues.jboss.org/browse/ARTIF-702 Project: Artificer Issue Type: Enhancement Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer (12:12:47 PM) ewittman: getMetaData is super slow the first time you use it (this is an old bug) (12:12:58 PM) ewittman: I think it takes a long time to build the jaxb context iirc -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 12:20:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 10 Jun 2015 12:20:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-703) Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-703: --------------------------------- Summary: Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL Key: ARTIF-703 URL: https://issues.jboss.org/browse/ARTIF-703 Project: Artificer Issue Type: Enhancement Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 It would be great if, for Wildfly, the installer could include an overlay ZIP with a pre-configured Keycloak realm and file-based H2 database (with the DDL pre-installed). We'll need this for Docker, anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 12:03:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 12:03:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-704) aesh includes a 'man' command on CLI, but it's broken In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-704: --------------------------------- Summary: aesh includes a 'man' command on CLI, but it's broken Key: ARTIF-704 URL: https://issues.jboss.org/browse/ARTIF-704 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Ex: artificer> man getMetaData Exception when parsing/running: man getMetaData, null -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 12:08:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 12:08:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-704) aesh includes a 'man' command on CLI, but it's broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077649#comment-13077649 ] Brett Meyer commented on ARTIF-704: ----------------------------------- Aesh requires a custom man provider, but for our purposes, the generated "--help" is sufficient. > aesh includes a 'man' command on CLI, but it's broken > ----------------------------------------------------- > > Key: ARTIF-704 > URL: https://issues.jboss.org/browse/ARTIF-704 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Ex: > artificer> man getMetaData > Exception when parsing/running: man getMetaData, null -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 12:11:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 12:11:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-704) CLI: Disable's aesh's 'man' command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-704: ------------------------------ Summary: CLI: Disable's aesh's 'man' command (was: aesh includes a 'man' command on CLI, but it's broken) > CLI: Disable's aesh's 'man' command > ----------------------------------- > > Key: ARTIF-704 > URL: https://issues.jboss.org/browse/ARTIF-704 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Ex: > artificer> man getMetaData > Exception when parsing/running: man getMetaData, null -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 13:00:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 13:00:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-701) 'relatedDocument' not shown in web UI's reverse relationshisp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-701. ------------------------------- Resolution: Done > 'relatedDocument' not shown in web UI's reverse relationshisp > ------------------------------------------------------------- > > Key: ARTIF-701 > URL: https://issues.jboss.org/browse/ARTIF-701 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Since 'relatedDocument' is not a part of the general purpose 'relationships' field (ie, we define a separate 'derivedFrom' FK), it's not shown on the web UI's reverse relationships. Manually add it. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 13:38:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 13:38:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-699) Installer echos the admin password back in plain text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-699. ------------------------------- Resolution: Done > Installer echos the admin password back in plain text > ----------------------------------------------------- > > Key: ARTIF-699 > URL: https://issues.jboss.org/browse/ARTIF-699 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Obscure it -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 14:25:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 14:25:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-698) Installer should allow Wildfly auto-download In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-698. ----------------------------- Fix Version/s: (was: 1.0.0.Beta2) Resolution: Won't Fix > Installer should allow Wildfly auto-download > -------------------------------------------- > > Key: ARTIF-698 > URL: https://issues.jboss.org/browse/ARTIF-698 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 14:51:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 14:51:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-703) Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-703. ----------------------------- Fix Version/s: (was: 1.0.0.Beta2) Resolution: Won't Fix Deciding against this, for now, since the same results can already be accomplished with: bin/standalone.sh -c standalone-full.xml -Dkeycloak.import=$ARTIFICER_HOME/distro/assembly/src/main/resources/ROOT/artificer-realm.json -Dhibernate.hbm2ddl.auto=update > Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL > ----------------------------------------------------------------------- > > Key: ARTIF-703 > URL: https://issues.jboss.org/browse/ARTIF-703 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > It would be great if, for Wildfly, the installer could include an overlay ZIP with a pre-configured Keycloak realm and file-based H2 database (with the DDL pre-installed). We'll need this for Docker, anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 15:55:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 15:55:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-703) Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reopened ARTIF-703: ------------------------------- > Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL > ----------------------------------------------------------------------- > > Key: ARTIF-703 > URL: https://issues.jboss.org/browse/ARTIF-703 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > It would be great if, for Wildfly, the installer could include an overlay ZIP with a pre-configured Keycloak realm and file-based H2 database (with the DDL pre-installed). We'll need this for Docker, anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 15:55:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 15:55:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-703) Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077738#comment-13077738 ] Brett Meyer edited comment on ARTIF-703 at 6/11/15 3:54 PM: ------------------------------------------------------------ Decided against an overlay.zip, for now, since the same results can already be accomplished with: bin/standalone.sh -c standalone-full.xml -Dkeycloak.import=$ARTIFICER_HOME/distro/assembly/src/main/resources/ROOT/artificer-realm.json -Dhibernate.hbm2ddl.auto=update was (Author: brmeyer): Deciding against this, for now, since the same results can already be accomplished with: bin/standalone.sh -c standalone-full.xml -Dkeycloak.import=$ARTIFICER_HOME/distro/assembly/src/main/resources/ROOT/artificer-realm.json -Dhibernate.hbm2ddl.auto=update > Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL > ----------------------------------------------------------------------- > > Key: ARTIF-703 > URL: https://issues.jboss.org/browse/ARTIF-703 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > It would be great if, for Wildfly, the installer could include an overlay ZIP with a pre-configured Keycloak realm and file-based H2 database (with the DDL pre-installed). We'll need this for Docker, anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 15:55:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 15:55:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-703) Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-703: ------------------------------ Comment: was deleted (was: Decided against an overlay.zip, for now, since the same results can already be accomplished with: bin/standalone.sh -c standalone-full.xml -Dkeycloak.import=$ARTIFICER_HOME/distro/assembly/src/main/resources/ROOT/artificer-realm.json -Dhibernate.hbm2ddl.auto=update) > Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL > ----------------------------------------------------------------------- > > Key: ARTIF-703 > URL: https://issues.jboss.org/browse/ARTIF-703 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > It would be great if, for Wildfly, the installer could include an overlay ZIP with a pre-configured Keycloak realm and file-based H2 database (with the DDL pre-installed). We'll need this for Docker, anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 15:55:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 15:55:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-703) Auto install DDL if the tables don't exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-703: ------------------------------ Summary: Auto install DDL if the tables don't exist (was: Installer Wildfly overlay with pre-configured Keycloak realm and H2 DDL) > Auto install DDL if the tables don't exist > ------------------------------------------ > > Key: ARTIF-703 > URL: https://issues.jboss.org/browse/ARTIF-703 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > It would be great if, for Wildfly, the installer could include an overlay ZIP with a pre-configured Keycloak realm and file-based H2 database (with the DDL pre-installed). We'll need this for Docker, anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 15:57:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 15:57:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-703) Auto install DDL if the tables don't exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-703: ------------------------------ Description: Since we now build the EMF programmatically, on demand, we should be able to automatically install the DDL on the DB if the tables don't already exist. This is *much* preferred over Hibernate's hbm2ddl, since we can use our real (optimized) DDL SQL. Further, it will allow users to get started even quicker. Even further, we'll need something like this for Docker anyway... (was: It would be great if, for Wildfly, the installer could include an overlay ZIP with a pre-configured Keycloak realm and file-based H2 database (with the DDL pre-installed). We'll need this for Docker, anyway...) > Auto install DDL if the tables don't exist > ------------------------------------------ > > Key: ARTIF-703 > URL: https://issues.jboss.org/browse/ARTIF-703 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > Since we now build the EMF programmatically, on demand, we should be able to automatically install the DDL on the DB if the tables don't already exist. This is *much* preferred over Hibernate's hbm2ddl, since we can use our real (optimized) DDL SQL. Further, it will allow users to get started even quicker. Even further, we'll need something like this for Docker anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 22:51:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Jun 2015 22:51:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-703) Auto install DDL if the tables don't exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-703. ------------------------------- Fix Version/s: 1.0.0.Beta2 Resolution: Done > Auto install DDL if the tables don't exist > ------------------------------------------ > > Key: ARTIF-703 > URL: https://issues.jboss.org/browse/ARTIF-703 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Since we now build the EMF programmatically, on demand, we should be able to automatically install the DDL on the DB if the tables don't already exist. This is *much* preferred over Hibernate's hbm2ddl, since we can use our real (optimized) DDL SQL. Further, it will allow users to get started even quicker. Even further, we'll need something like this for Docker anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 06:49:02 2015 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Fri, 12 Jun 2015 06:49:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-467) UI: relationship visualizations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078096#comment-13078096 ] Jorge Morales commented on ARTIF-467: ------------------------------------- Hey Brett, I know it is different technology, and different scope, but check out this video to see the visualization of relationships part (minute 6:15): http://stef.thewalter.net/cockpit-kubernetes-dashboard.html > UI: relationship visualizations > ------------------------------- > > Key: ARTIF-467 > URL: https://issues.jboss.org/browse/ARTIF-467 > Project: Artificer > Issue Type: Feature Request > Components: UI > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 09:50:04 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 12 Jun 2015 09:50:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-705) Exception when adding properties or classifiers to artifact In-Reply-To: References: Message-ID: Gary Brown created ARTIF-705: -------------------------------- Summary: Exception when adding properties or classifiers to artifact Key: ARTIF-705 URL: https://issues.jboss.org/browse/ARTIF-705 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Environment: Wildfly 8.2 final, H2 Reporter: Gary Brown Assignee: Brett Meyer Imported a jar artifact successfully. However when I tried to add a property on one of the derived artifacts, representing a SwitchYardComponentService, it resulted in an exception (org.jboss.errai.enterprise.client.jaxrs.api.ResponseException: Internal Server Error). Server log will be attached. I then created a simple Ontology called "Test" with top node "Country" and three sub nodes "UK", "France", "Germany". I then tried to 'modify classifiers' on the same artifact, selecting UK and Germany, and it resulted in the same exception. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 09:51:03 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 12 Jun 2015 09:51:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-705) Exception when adding properties or classifiers to artifact In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated ARTIF-705: ----------------------------- Attachment: server.log ordermgmt.jar Log and imported artifact. > Exception when adding properties or classifiers to artifact > ----------------------------------------------------------- > > Key: ARTIF-705 > URL: https://issues.jboss.org/browse/ARTIF-705 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: Wildfly 8.2 final, H2 > Reporter: Gary Brown > Assignee: Brett Meyer > Attachments: ordermgmt.jar, server.log > > > Imported a jar artifact successfully. > However when I tried to add a property on one of the derived artifacts, representing a SwitchYardComponentService, it resulted in an exception (org.jboss.errai.enterprise.client.jaxrs.api.ResponseException: Internal Server Error). Server log will be attached. > I then created a simple Ontology called "Test" with top node "Country" and three sub nodes "UK", "France", "Germany". I then tried to 'modify classifiers' on the same artifact, selecting UK and Germany, and it resulted in the same exception. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 10:12:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 12 Jun 2015 10:12:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-705) Exception when adding properties or classifiers to artifact In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-705: ------------------------------ Fix Version/s: 1.0.0.Beta2 > Exception when adding properties or classifiers to artifact > ----------------------------------------------------------- > > Key: ARTIF-705 > URL: https://issues.jboss.org/browse/ARTIF-705 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: Wildfly 8.2 final, H2 > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > Attachments: ordermgmt.jar, server.log > > > Imported a jar artifact successfully. > However when I tried to add a property on one of the derived artifacts, representing a SwitchYardComponentService, it resulted in an exception (org.jboss.errai.enterprise.client.jaxrs.api.ResponseException: Internal Server Error). Server log will be attached. > I then created a simple Ontology called "Test" with top node "Country" and three sub nodes "UK", "France", "Germany". I then tried to 'modify classifiers' on the same artifact, selecting UK and Germany, and it resulted in the same exception. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 10:49:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 12 Jun 2015 10:49:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-706) Create DerivedExtendedArtifactType In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-706: --------------------------------- Summary: Create DerivedExtendedArtifactType Key: ARTIF-706 URL: https://issues.jboss.org/browse/ARTIF-706 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Having "relatedDocument" in an artifact's relationships list requires some stupid logic to deal with (see ArtifactVerifier#verifyNames). Instead, we should rely solely on the real #relatedDocument field. Unfortunately, that's only on DerivedArtifactType. If a derived artifact is an *extended* artifact, there's no access to that field, hence the need to use the general relationship. Re-work that structure to be more useful. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 10:54:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 12 Jun 2015 10:54:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-706) Create DerivedExtendedArtifactType In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078262#comment-13078262 ] Brett Meyer commented on ARTIF-706: ----------------------------------- Note: when this is fixed, search for all instances of "relatedDocument" and see what can be fixed... > Create DerivedExtendedArtifactType > ---------------------------------- > > Key: ARTIF-706 > URL: https://issues.jboss.org/browse/ARTIF-706 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Having "relatedDocument" in an artifact's relationships list requires some stupid logic to deal with (see ArtifactVerifier#verifyNames). Instead, we should rely solely on the real #relatedDocument field. Unfortunately, that's only on DerivedArtifactType. If a derived artifact is an *extended* artifact, there's no access to that field, hence the need to use the general relationship. Re-work that structure to be more useful. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 11:25:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 12 Jun 2015 11:25:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-705) Exception when adding properties or classifiers to artifact In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-705. ------------------------------- Resolution: Done > Exception when adding properties or classifiers to artifact > ----------------------------------------------------------- > > Key: ARTIF-705 > URL: https://issues.jboss.org/browse/ARTIF-705 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: Wildfly 8.2 final, H2 > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > Attachments: ordermgmt.jar, server.log > > > Imported a jar artifact successfully. > However when I tried to add a property on one of the derived artifacts, representing a SwitchYardComponentService, it resulted in an exception (org.jboss.errai.enterprise.client.jaxrs.api.ResponseException: Internal Server Error). Server log will be attached. > I then created a simple Ontology called "Test" with top node "Country" and three sub nodes "UK", "France", "Germany". I then tried to 'modify classifiers' on the same artifact, selecting UK and Germany, and it resulted in the same exception. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 06:19:02 2015 From: issues at jboss.org (Thomas Heute (JIRA)) Date: Mon, 15 Jun 2015 06:19:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-707) Uncaught GWT Error: Cannot read property 'indexOf' of null In-Reply-To: References: Message-ID: Thomas Heute created ARTIF-707: ---------------------------------- Summary: Uncaught GWT Error: Cannot read property 'indexOf' of null Key: ARTIF-707 URL: https://issues.jboss.org/browse/ARTIF-707 Project: Artificer Issue Type: Bug Components: UI Affects Versions: 1.0.0.Beta1 Reporter: Thomas Heute Assignee: Brett Meyer While playing with the UI, I tried to upload some random artifacts (In that case I tried to upload artificer-1.0.0.Beta1.zip itself. I get an error in the UI: Uncaught GWT Error! Exception caught: (TypeError) : Cannot read property 'indexOf' of null and a message remains forever: Importing Artifact(s) Please wait while your import is processed... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 06:20:02 2015 From: issues at jboss.org (Thomas Heute (JIRA)) Date: Mon, 15 Jun 2015 06:20:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-707) Uncaught GWT Error: Cannot read property 'indexOf' of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078895#comment-13078895 ] Thomas Heute commented on ARTIF-707: ------------------------------------ In Chrome developer console I get: POST http://localhost:8080/artificer-ui/app/services/artifactUpload net::ERR_CONNECTION_RESET > Uncaught GWT Error: Cannot read property 'indexOf' of null > ---------------------------------------------------------- > > Key: ARTIF-707 > URL: https://issues.jboss.org/browse/ARTIF-707 > Project: Artificer > Issue Type: Bug > Components: UI > Affects Versions: 1.0.0.Beta1 > Reporter: Thomas Heute > Assignee: Brett Meyer > > While playing with the UI, I tried to upload some random artifacts (In that case I tried to upload artificer-1.0.0.Beta1.zip itself. > I get an error in the UI: > Uncaught GWT Error! > Exception caught: (TypeError) : Cannot read property 'indexOf' of null > and a message remains forever: > Importing Artifact(s) > Please wait while your import is processed... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 08:46:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 08:46:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-707) Uncaught GWT Error: Cannot read property 'indexOf' of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-707: ------------------------------ Fix Version/s: 1.0.0.Beta2 > Uncaught GWT Error: Cannot read property 'indexOf' of null > ---------------------------------------------------------- > > Key: ARTIF-707 > URL: https://issues.jboss.org/browse/ARTIF-707 > Project: Artificer > Issue Type: Bug > Components: UI > Affects Versions: 1.0.0.Beta1 > Reporter: Thomas Heute > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > While playing with the UI, I tried to upload some random artifacts (In that case I tried to upload artificer-1.0.0.Beta1.zip itself. > I get an error in the UI: > Uncaught GWT Error! > Exception caught: (TypeError) : Cannot read property 'indexOf' of null > and a message remains forever: > Importing Artifact(s) > Please wait while your import is processed... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 08:56:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 08:56:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-708) Support Java 8 In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-708: --------------------------------- Summary: Support Java 8 Key: ARTIF-708 URL: https://issues.jboss.org/browse/ARTIF-708 Project: Artificer Issue Type: Task Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project artificer-repository-hibernate: Compilation failure: Compilation failure: [ERROR] /home/theute/Projects/Artificer/artificer/repository/hibernate/src/main/java/org/artificer/repository/hibernate/HibernateEntityFactory.java:[60,59] cannot access javax.servlet.Filter [ERROR] class file for javax.servlet.Filter not found [ERROR] /home/theute/Projects/Artificer/artificer/repository/hibernate/src/main/java/org/artificer/repository/hibernate/query/ArtificerToHibernateQueryVisitor.java:[577,19] incomparable types: java.lang.Object and boolean [ERROR] /home/theute/Projects/Artificer/artificer/repository/hibernate/src/main/java/org/artificer/repository/hibernate/query/ArtificerToHibernateQueryVisitor.java:[579,26] incomparable types: java.lang.Object and boolean this is the JDK I use: theute at X1Carbon:artificer (master)$ java -version openjdk version "1.8.0_45" OpenJDK Runtime Environment (build 1.8.0_45-b14) OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 10:52:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 10:52:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-465) Investigate alternative methods for relationship resolution and reduced duplication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-465: ------------------------------ Summary: Investigate alternative methods for relationship resolution and reduced duplication (was: Investigate alternative methods for relationship resolution) > Investigate alternative methods for relationship resolution and reduced duplication > ----------------------------------------------------------------------------------- > > Key: ARTIF-465 > URL: https://issues.jboss.org/browse/ARTIF-465 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > Investigate increased automatic artifact relationships (ie, service A depends on service B), useful for impact analysis. Possibly include Java-specific improvements, such as custom annotations (and scanning). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 10:52:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 10:52:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-465) Investigate alternative methods for relationship resolution and reduced duplication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-465: ------------------------------ Fix Version/s: 1.1.0.Final > Investigate alternative methods for relationship resolution and reduced duplication > ----------------------------------------------------------------------------------- > > Key: ARTIF-465 > URL: https://issues.jboss.org/browse/ARTIF-465 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > Investigate increased automatic artifact relationships (ie, service A depends on service B), useful for impact analysis. Possibly include Java-specific improvements, such as custom annotations (and scanning). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 11:00:11 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 11:00:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-709) Allow artifact expansion to be enabled/disabled during each upload In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-709: --------------------------------- Summary: Allow artifact expansion to be enabled/disabled during each upload Key: ARTIF-709 URL: https://issues.jboss.org/browse/ARTIF-709 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Expansion is useful in some cases (especially API jars, etc.). However, in others, it's actually pretty harmful. Ex: pushing in a project's ZIP distro, a large WAR with all its dependency JARs, etc. Currently, Artificer would get overwhelmed with the amount of info to pull out. Suggestion: 1.) Expansion disabled by default 2.) Enable with checkbox on web UI, argument on CLI, argument on Java client, etc. 3.) If *not* expanded, the relationship builders should still kick in. So, the contents would still be parsed. If it contains, for example, a WSDL that imports an XSD or a Java class that impls an API interface, the relationships should still be created. But those relationships would point to the archive itself, rather than an expanded/derived artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 11:04:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 11:04:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-707) Uncaught GWT Error: Cannot read property 'indexOf' of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079213#comment-13079213 ] Brett Meyer commented on ARTIF-707: ----------------------------------- Chrome fails fast. Firefox appears to hang indefinitely on the "Importing Artifact(s)", but doesn't appear to actually fail. Figure out why Chrome immediately fails (filesize restriction, etc). But Firefox should probably be temporarily deferred. Instead, focus on ARTIF-709 first. The server may simply be choking on the sheer number of artifacts in that distro (it's expanding and deriving the WARs, the dependency JARs in the WARs, all schemas, etc.). Arguably, expansion should occur only for *contract* or *schema* archives, not impl archives. > Uncaught GWT Error: Cannot read property 'indexOf' of null > ---------------------------------------------------------- > > Key: ARTIF-707 > URL: https://issues.jboss.org/browse/ARTIF-707 > Project: Artificer > Issue Type: Bug > Components: UI > Affects Versions: 1.0.0.Beta1 > Reporter: Thomas Heute > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > While playing with the UI, I tried to upload some random artifacts (In that case I tried to upload artificer-1.0.0.Beta1.zip itself. > I get an error in the UI: > Uncaught GWT Error! > Exception caught: (TypeError) : Cannot read property 'indexOf' of null > and a message remains forever: > Importing Artifact(s) > Please wait while your import is processed... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 11:07:05 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 11:07:05 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-709) Allow artifact expansion to be enabled/disabled during each upload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-709: ------------------------------ Fix Version/s: 1.0.0.Beta2 > Allow artifact expansion to be enabled/disabled during each upload > ------------------------------------------------------------------ > > Key: ARTIF-709 > URL: https://issues.jboss.org/browse/ARTIF-709 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Expansion is useful in some cases (especially API jars, etc.). However, in others, it's actually pretty harmful. Ex: pushing in a project's ZIP distro, a large WAR with all its dependency JARs, etc. Currently, Artificer would get overwhelmed with the amount of info to pull out. > Suggestion: > 1.) Expansion disabled by default > 2.) Enable with checkbox on web UI, argument on CLI, argument on Java client, etc. > 3.) If *not* expanded, the relationship builders should still kick in. So, the contents would still be parsed. If it contains, for example, a WSDL that imports an XSD or a Java class that impls an API interface, the relationships should still be created. But those relationships would point to the archive itself, rather than an expanded/derived artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 11:22:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 11:22:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-707) Uncaught GWT Error: Cannot read property 'indexOf' of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079229#comment-13079229 ] Brett Meyer commented on ARTIF-707: ----------------------------------- I take part of that back. It looks like the upload call never actually reaches Artificer, so Firefox is failing also. Regardless, even if it did reach the server, ARTIF-709 would be a problem. > Uncaught GWT Error: Cannot read property 'indexOf' of null > ---------------------------------------------------------- > > Key: ARTIF-707 > URL: https://issues.jboss.org/browse/ARTIF-707 > Project: Artificer > Issue Type: Bug > Components: UI > Affects Versions: 1.0.0.Beta1 > Reporter: Thomas Heute > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > While playing with the UI, I tried to upload some random artifacts (In that case I tried to upload artificer-1.0.0.Beta1.zip itself. > I get an error in the UI: > Uncaught GWT Error! > Exception caught: (TypeError) : Cannot read property 'indexOf' of null > and a message remains forever: > Importing Artifact(s) > Please wait while your import is processed... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 11:45:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 11:45:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-707) Uncaught GWT Error: Cannot read property 'indexOf' of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079249#comment-13079249 ] Brett Meyer commented on ARTIF-707: ----------------------------------- Root cause: org.apache.commons.fileupload.FileUploadException: UT000020: Connection terminated as request was larger than 10485760 > Uncaught GWT Error: Cannot read property 'indexOf' of null > ---------------------------------------------------------- > > Key: ARTIF-707 > URL: https://issues.jboss.org/browse/ARTIF-707 > Project: Artificer > Issue Type: Bug > Components: UI > Affects Versions: 1.0.0.Beta1 > Reporter: Thomas Heute > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > While playing with the UI, I tried to upload some random artifacts (In that case I tried to upload artificer-1.0.0.Beta1.zip itself. > I get an error in the UI: > Uncaught GWT Error! > Exception caught: (TypeError) : Cannot read property 'indexOf' of null > and a message remains forever: > Importing Artifact(s) > Please wait while your import is processed... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 11:57:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 11:57:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-707) Uncaught GWT Error: Cannot read property 'indexOf' of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079257#comment-13079257 ] Brett Meyer commented on ARTIF-707: ----------------------------------- standalone-full.xml simply needs 'max-post-size="-1"' added to , effectively accepting a POST of any size. After that, it works fine. Actually, it's surprisingly quick. It does, however, result in ~ 500 artifacts, so ARTIF-709 is still needed. > Uncaught GWT Error: Cannot read property 'indexOf' of null > ---------------------------------------------------------- > > Key: ARTIF-707 > URL: https://issues.jboss.org/browse/ARTIF-707 > Project: Artificer > Issue Type: Bug > Components: UI > Affects Versions: 1.0.0.Beta1 > Reporter: Thomas Heute > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > While playing with the UI, I tried to upload some random artifacts (In that case I tried to upload artificer-1.0.0.Beta1.zip itself. > I get an error in the UI: > Uncaught GWT Error! > Exception caught: (TypeError) : Cannot read property 'indexOf' of null > and a message remains forever: > Importing Artifact(s) > Please wait while your import is processed... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 14:11:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 14:11:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-707) Uncaught GWT Error: Cannot read property 'indexOf' of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-707. ------------------------------- Resolution: Done > Uncaught GWT Error: Cannot read property 'indexOf' of null > ---------------------------------------------------------- > > Key: ARTIF-707 > URL: https://issues.jboss.org/browse/ARTIF-707 > Project: Artificer > Issue Type: Bug > Components: UI > Affects Versions: 1.0.0.Beta1 > Reporter: Thomas Heute > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > While playing with the UI, I tried to upload some random artifacts (In that case I tried to upload artificer-1.0.0.Beta1.zip itself. > I get an error in the UI: > Uncaught GWT Error! > Exception caught: (TypeError) : Cannot read property 'indexOf' of null > and a message remains forever: > Importing Artifact(s) > Please wait while your import is processed... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 14:42:02 2015 From: issues at jboss.org (Thomas Heute (JIRA)) Date: Mon, 15 Jun 2015 14:42:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-707) Uncaught GWT Error: Cannot read property 'indexOf' of null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079344#comment-13079344 ] Thomas Heute commented on ARTIF-707: ------------------------------------ Nice thanks. can't wait to see the 500 artifacts :) > Uncaught GWT Error: Cannot read property 'indexOf' of null > ---------------------------------------------------------- > > Key: ARTIF-707 > URL: https://issues.jboss.org/browse/ARTIF-707 > Project: Artificer > Issue Type: Bug > Components: UI > Affects Versions: 1.0.0.Beta1 > Reporter: Thomas Heute > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > While playing with the UI, I tried to upload some random artifacts (In that case I tried to upload artificer-1.0.0.Beta1.zip itself. > I get an error in the UI: > Uncaught GWT Error! > Exception caught: (TypeError) : Cannot read property 'indexOf' of null > and a message remains forever: > Importing Artifact(s) > Please wait while your import is processed... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 15:14:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Jun 2015 15:14:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-708) Support Java 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-708. ------------------------------- Fix Version/s: 1.0.0.Beta2 Resolution: Done > Support Java 8 > -------------- > > Key: ARTIF-708 > URL: https://issues.jboss.org/browse/ARTIF-708 > Project: Artificer > Issue Type: Task > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.1:compile > (default-compile) on project artificer-repository-hibernate: Compilation > failure: Compilation failure: > [ERROR] > /home/theute/Projects/Artificer/artificer/repository/hibernate/src/main/java/org/artificer/repository/hibernate/HibernateEntityFactory.java:[60,59] > cannot access javax.servlet.Filter > [ERROR] class file for javax.servlet.Filter not found > [ERROR] > /home/theute/Projects/Artificer/artificer/repository/hibernate/src/main/java/org/artificer/repository/hibernate/query/ArtificerToHibernateQueryVisitor.java:[577,19] > incomparable types: java.lang.Object and boolean > [ERROR] > /home/theute/Projects/Artificer/artificer/repository/hibernate/src/main/java/org/artificer/repository/hibernate/query/ArtificerToHibernateQueryVisitor.java:[579,26] > incomparable types: java.lang.Object and boolean > this is the JDK I use: > theute at X1Carbon:artificer (master)$ java -version > openjdk version "1.8.0_45" > OpenJDK Runtime Environment (build 1.8.0_45-b14) > OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 06:51:03 2015 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 16 Jun 2015 06:51:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-662) RTGov properties are not logged in elasticsearch for external invocations In-Reply-To: References: Message-ID: Gary Brown created RTGOV-662: -------------------------------- Summary: RTGov properties are not logged in elasticsearch for external invocations Key: RTGOV-662 URL: https://issues.jboss.org/browse/RTGOV-662 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Properties associated with an external invocation in switchyard are being reported in activity information, but not logged in the response time information stored in elasticsearch. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 06:54:02 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 16 Jun 2015 06:54:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-662) RTGov properties are not logged in elasticsearch for external invocations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-662: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1232188 > RTGov properties are not logged in elasticsearch for external invocations > ------------------------------------------------------------------------- > > Key: RTGOV-662 > URL: https://issues.jboss.org/browse/RTGOV-662 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > > Properties associated with an external invocation in switchyard are being reported in activity information, but not logged in the response time information stored in elasticsearch. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 10:28:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 10:28:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-710) Optimize Hibernate Search query In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-710: --------------------------------- Summary: Optimize Hibernate Search query Key: ARTIF-710 URL: https://issues.jboss.org/browse/ARTIF-710 Project: Artificer Issue Type: Enhancement Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Currently, if a full-text search method is found by the query visitor, it builds up a separate Hibernate Search query, with the search keyword as the only constraint. The resulting artifact IDs are then used as a "where id in (...)" constraint on the original query. It would be more performant to delay the Search query until execution of the original query. Several artifact fields could also be indexed and used to limit the full-text search's results. For instance, if the query starts with /s-ramp/xsd/XsdDocument, we could index 'model' and 'type'. Then, match those indexes using the model/type, helping to reduce the size of the eventual list of IDs. The same is probably true for other types of predicates. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 11:51:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 11:51:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-710) Optimize Hibernate Search query In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-710. ------------------------------- Resolution: Done For now, making a few assumptions. I only added the artifact model and type to the index. That should cover the vast majority of use cases. Also, with that in mind, the query didn't have to be delayed until the main query is executed, since when we hit the full-text predicate, we would have already hit the model/type path. > Optimize Hibernate Search query > ------------------------------- > > Key: ARTIF-710 > URL: https://issues.jboss.org/browse/ARTIF-710 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Currently, if a full-text search method is found by the query visitor, it builds up a separate Hibernate Search query, with the search keyword as the only constraint. The resulting artifact IDs are then used as a "where id in (...)" constraint on the original query. > It would be more performant to delay the Search query until execution of the original query. Several artifact fields could also be indexed and used to limit the full-text search's results. For instance, if the query starts with /s-ramp/xsd/XsdDocument, we could index 'model' and 'type'. Then, match those indexes using the model/type, helping to reduce the size of the eventual list of IDs. The same is probably true for other types of predicates. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 12:10:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 12:10:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-711) Performance enhancements In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-711: --------------------------------- Summary: Performance enhancements Key: ARTIF-711 URL: https://issues.jboss.org/browse/ARTIF-711 Project: Artificer Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Tracks necessary performance enhancements, discovered during profiling -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 14:41:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 14:41:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-712) Optimize ArtifactSet, PagedResult, etc. In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-712: --------------------------------- Summary: Optimize ArtifactSet, PagedResult, etc. Key: ARTIF-712 URL: https://issues.jboss.org/browse/ARTIF-712 Project: Artificer Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 ArtifactSet#list should never be used server-side unless absolutely necessary (feeds, etc.). Ex: PagedResult is currently handed the list (bad), instead of given an iterator (good). The latter would allow the BaseArtifactTypes to be visited/built on-demand, rather than all up-front. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 19:47:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 19:47:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-712) Refactor ArtifactSet, PagedResult, etc. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-712: ------------------------------ Summary: Refactor ArtifactSet, PagedResult, etc. (was: Optimize ArtifactSet, PagedResult, etc.) > Refactor ArtifactSet, PagedResult, etc. > --------------------------------------- > > Key: ARTIF-712 > URL: https://issues.jboss.org/browse/ARTIF-712 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > ArtifactSet#list should never be used server-side unless absolutely necessary (feeds, etc.). Ex: PagedResult is currently handed the list (bad), instead of given an iterator (good). The latter would allow the BaseArtifactTypes to be visited/built on-demand, rather than all up-front. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 19:48:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 19:48:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-712) Refactor ArtifactSet, PagedResult, etc. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-712: ------------------------------ Description: AbstractSet and its subclasses aren't really needed any more. It would be more performant to solely rely on PagedResult through the architecture and all clients. (was: ArtifactSet#list should never be used server-side unless absolutely necessary (feeds, etc.). Ex: PagedResult is currently handed the list (bad), instead of given an iterator (good). The latter would allow the BaseArtifactTypes to be visited/built on-demand, rather than all up-front.) > Refactor ArtifactSet, PagedResult, etc. > --------------------------------------- > > Key: ARTIF-712 > URL: https://issues.jboss.org/browse/ARTIF-712 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > AbstractSet and its subclasses aren't really needed any more. It would be more performant to solely rely on PagedResult through the architecture and all clients. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 19:50:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 19:50:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-712) Refactor ArtifactSet, PagedResult, etc. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-712. ------------------------------- Resolution: Done > Refactor ArtifactSet, PagedResult, etc. > --------------------------------------- > > Key: ARTIF-712 > URL: https://issues.jboss.org/browse/ARTIF-712 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > AbstractSet and its subclasses aren't really needed any more. It would be more performant to solely rely on PagedResult through the architecture and all clients. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 20:06:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 20:06:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-713) Persist each batch upload with one single transaction In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-713: --------------------------------- Summary: Persist each batch upload with one single transaction Key: ARTIF-713 URL: https://issues.jboss.org/browse/ARTIF-713 Project: Artificer Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Currently, each *item* in a batch is handled by a separate JDBC transaction. Instead, it would be far more performant to commit the *entire* batch in a single transaction. Further, from a user perspective, this setup makes more sense anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 20:51:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 20:51:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-713) Persist each batch upload with one single transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-713: ------------------------------ Fix Version/s: (was: 1.0.0.Beta2) > Persist each batch upload with one single transaction > ----------------------------------------------------- > > Key: ARTIF-713 > URL: https://issues.jboss.org/browse/ARTIF-713 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > Currently, each *item* in a batch is handled by a separate JDBC transaction. Instead, it would be far more performant to commit the *entire* batch in a single transaction. Further, from a user perspective, this setup makes more sense anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 20:53:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Jun 2015 20:53:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-713) Persist each batch upload with one single transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-713. ----------------------------- Resolution: Won't Fix For completeness, here's why this should never happen (forgot when I opened it): Persisting artifact A happens in one transaction, while querying for artifacts to potentially target with a relationship owned by A happens in another transaction. In order to allow items in a batch to be related to *each other*, the transaction needs to be committed after each item is persisted. Otherwise, the latter transaction isn't able to see it. Being able to support this would be extremely complicated and, ultimately, could require holding quite a bit of info in memory during batch execution. > Persist each batch upload with one single transaction > ----------------------------------------------------- > > Key: ARTIF-713 > URL: https://issues.jboss.org/browse/ARTIF-713 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > Currently, each *item* in a batch is handled by a separate JDBC transaction. Instead, it would be far more performant to commit the *entire* batch in a single transaction. Further, from a user perspective, this setup makes more sense anyway... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 12:07:04 2015 From: issues at jboss.org (Mark Tebong (JIRA)) Date: Wed, 17 Jun 2015 12:07:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-714) Error starting Artificer beta 1 - hibernate.search module not found In-Reply-To: References: Message-ID: Mark Tebong created ARTIF-714: --------------------------------- Summary: Error starting Artificer beta 1 - hibernate.search module not found Key: ARTIF-714 URL: https://issues.jboss.org/browse/ARTIF-714 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Environment: Windows. EAP 6.3 Reporter: Mark Tebong Assignee: Brett Meyer On start up of EAP, this is the error I get. The server eventually starts, but after log in, Artificer immediately gives error "Error Searching for Artifacts" and "Error Refreshing Ontology List". Thereafter, I can't really do much. It appears artificer-server did not deploy or start, due to the following error. 11:22:42,050 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.module.service."deployment.artificer-server.wa r".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.artificer-server.war".main: JBAS018759: Failed to load module: deploym ent.artificer-server.war:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 ] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-r edhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] Caused by: org.jboss.modules.ModuleNotFoundException: org.hibernate.search.orm:main at org.jboss.modules.Module.addPaths(Module.java:1050) [jboss-modules.jar:1.3.3.Final-redhat-1] at org.jboss.modules.Module.link(Module.java:1406) [jboss-modules.jar:1.3.3.Final-redhat-1] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1434) [jboss-modules.jar:1.3.3.Final-redhat-1] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:242) [jboss-modules.jar:1.3.3.Final-redhat-1] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:70) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 ] ... 5 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 12:09:04 2015 From: issues at jboss.org (Mark Tebong (JIRA)) Date: Wed, 17 Jun 2015 12:09:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-714) Error starting Artificer beta 1 - hibernate.search module not found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080454#comment-13080454 ] Mark Tebong commented on ARTIF-714: ----------------------------------- When I look at the file system, it does not appear the hibernate.search jar file(s) are installed. > Error starting Artificer beta 1 - hibernate.search module not found > -------------------------------------------------------------------- > > Key: ARTIF-714 > URL: https://issues.jboss.org/browse/ARTIF-714 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: Windows. EAP 6.3 > Reporter: Mark Tebong > Assignee: Brett Meyer > > On start up of EAP, this is the error I get. The server eventually starts, but after log in, Artificer immediately gives error "Error Searching for Artifacts" and "Error Refreshing Ontology List". Thereafter, I can't really do much. It appears artificer-server did not deploy or start, due to the following error. > 11:22:42,050 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.module.service."deployment.artificer-server.wa > r".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.artificer-server.war".main: JBAS018759: Failed to load module: deploym > ent.artificer-server.war:main > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 > ] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-r > edhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] > Caused by: org.jboss.modules.ModuleNotFoundException: org.hibernate.search.orm:main > at org.jboss.modules.Module.addPaths(Module.java:1050) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.Module.link(Module.java:1406) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.Module.relinkIfNecessary(Module.java:1434) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:242) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:70) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 > ] > ... 5 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 12:12:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 17 Jun 2015 12:12:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-714) Error starting Artificer beta 1 - hibernate.search module not found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080457#comment-13080457 ] Brett Meyer commented on ARTIF-714: ----------------------------------- Hey [~mtebong], is EAP 6.3 a hard requirement? Hibernate Search wasn't introduced into EAP until 6.4. Frankly, we were planning to stop support for EAP 6.0-6.3 entirely. But if there's a reason why users can't use EAP 6.4, I suppose we could temporarily consider providing Search... > Error starting Artificer beta 1 - hibernate.search module not found > -------------------------------------------------------------------- > > Key: ARTIF-714 > URL: https://issues.jboss.org/browse/ARTIF-714 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: Windows. EAP 6.3 > Reporter: Mark Tebong > Assignee: Brett Meyer > > On start up of EAP, this is the error I get. The server eventually starts, but after log in, Artificer immediately gives error "Error Searching for Artifacts" and "Error Refreshing Ontology List". Thereafter, I can't really do much. It appears artificer-server did not deploy or start, due to the following error. > 11:22:42,050 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.module.service."deployment.artificer-server.wa > r".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.artificer-server.war".main: JBAS018759: Failed to load module: deploym > ent.artificer-server.war:main > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 > ] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-r > edhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] > Caused by: org.jboss.modules.ModuleNotFoundException: org.hibernate.search.orm:main > at org.jboss.modules.Module.addPaths(Module.java:1050) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.Module.link(Module.java:1406) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.Module.relinkIfNecessary(Module.java:1434) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:242) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:70) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 > ] > ... 5 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 12:16:03 2015 From: issues at jboss.org (Mark Tebong (JIRA)) Date: Wed, 17 Jun 2015 12:16:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-714) Error starting Artificer beta 1 - hibernate.search module not found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080460#comment-13080460 ] Mark Tebong commented on ARTIF-714: ----------------------------------- It is not a hard requirement. I will download and install 6.4, then artificer beta 1. If it works, I'll close this bug (making the note), and if its stil an issue, I'll update bug. > Error starting Artificer beta 1 - hibernate.search module not found > -------------------------------------------------------------------- > > Key: ARTIF-714 > URL: https://issues.jboss.org/browse/ARTIF-714 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: Windows. EAP 6.3 > Reporter: Mark Tebong > Assignee: Brett Meyer > > On start up of EAP, this is the error I get. The server eventually starts, but after log in, Artificer immediately gives error "Error Searching for Artifacts" and "Error Refreshing Ontology List". Thereafter, I can't really do much. It appears artificer-server did not deploy or start, due to the following error. > 11:22:42,050 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.module.service."deployment.artificer-server.wa > r".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.artificer-server.war".main: JBAS018759: Failed to load module: deploym > ent.artificer-server.war:main > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 > ] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-r > edhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] > Caused by: org.jboss.modules.ModuleNotFoundException: org.hibernate.search.orm:main > at org.jboss.modules.Module.addPaths(Module.java:1050) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.Module.link(Module.java:1406) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.Module.relinkIfNecessary(Module.java:1434) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:242) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:70) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 > ] > ... 5 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 12:54:02 2015 From: issues at jboss.org (Mark Tebong (JIRA)) Date: Wed, 17 Jun 2015 12:54:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-714) Error starting Artificer beta 1 - hibernate.search module not found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Tebong closed ARTIF-714. ----------------------------- Resolution: Won't Fix For EAP 6.3 and before, you would need to manually install hibernate.search. It is recommended to use EAP 6.4+. > Error starting Artificer beta 1 - hibernate.search module not found > -------------------------------------------------------------------- > > Key: ARTIF-714 > URL: https://issues.jboss.org/browse/ARTIF-714 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: Windows. EAP 6.3 > Reporter: Mark Tebong > Assignee: Brett Meyer > > On start up of EAP, this is the error I get. The server eventually starts, but after log in, Artificer immediately gives error "Error Searching for Artifacts" and "Error Refreshing Ontology List". Thereafter, I can't really do much. It appears artificer-server did not deploy or start, due to the following error. > 11:22:42,050 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.module.service."deployment.artificer-server.wa > r".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.artificer-server.war".main: JBAS018759: Failed to load module: deploym > ent.artificer-server.war:main > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 > ] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-r > edhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25] > Caused by: org.jboss.modules.ModuleNotFoundException: org.hibernate.search.orm:main > at org.jboss.modules.Module.addPaths(Module.java:1050) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.Module.link(Module.java:1406) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.Module.relinkIfNecessary(Module.java:1434) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:242) [jboss-modules.jar:1.3.3.Final-redhat-1] > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:70) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19 > ] > ... 5 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 15:39:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 17 Jun 2015 15:39:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-715) Upgrade to Keycloak 1.2.0.Final and switch to using keycloak-server-overlay:zip In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-715: --------------------------------- Summary: Upgrade to Keycloak 1.2.0.Final and switch to using keycloak-server-overlay:zip Key: ARTIF-715 URL: https://issues.jboss.org/browse/ARTIF-715 Project: Artificer Issue Type: Task Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 16:20:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 17 Jun 2015 16:20:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-715) Upgrade to Keycloak 1.2.0.Final and switch to using keycloak-server-overlay:zip In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-715. ------------------------------- Resolution: Done > Upgrade to Keycloak 1.2.0.Final and switch to using keycloak-server-overlay:zip > ------------------------------------------------------------------------------- > > Key: ARTIF-715 > URL: https://issues.jboss.org/browse/ARTIF-715 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 16:21:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 17 Jun 2015 16:21:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-716) Remove claims for EAP 6.0-6.3 support In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-716: --------------------------------- Summary: Remove claims for EAP 6.0-6.3 support Key: ARTIF-716 URL: https://issues.jboss.org/browse/ARTIF-716 Project: Artificer Issue Type: Task Reporter: Brett Meyer Assignee: Brett Meyer Hibernate Search isn't in them (6.4 was the first time it was officially pulled in), among other gaps. It's not worth the effort to support them... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 16:44:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 17 Jun 2015 16:44:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-716) Remove claims for EAP 6.0-6.3 support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-716. ------------------------------- Fix Version/s: 1.0.0.Beta2 Resolution: Done > Remove claims for EAP 6.0-6.3 support > ------------------------------------- > > Key: ARTIF-716 > URL: https://issues.jboss.org/browse/ARTIF-716 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Hibernate Search isn't in them (6.4 was the first time it was officially pulled in), among other gaps. It's not worth the effort to support them... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 10:04:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Jun 2015 10:04:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-717) Implement a CQRS pattern, separating the JPA entities and a query DTO In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-717: --------------------------------- Summary: Implement a CQRS pattern, separating the JPA entities and a query DTO Key: ARTIF-717 URL: https://issues.jboss.org/browse/ARTIF-717 Project: Artificer Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Implement a CQRS pattern. The JPA entities should be used purely for writes and single-artifact reads. Queries should switch to using a new ArtifactSummary DTO with bare-bones data. All clients should reflect that as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 10:04:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Jun 2015 10:04:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-717) Implement a CQRS pattern, separating the JPA entities and a query DTO In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-717 started by Brett Meyer. ----------------------------------------- > Implement a CQRS pattern, separating the JPA entities and a query DTO > --------------------------------------------------------------------- > > Key: ARTIF-717 > URL: https://issues.jboss.org/browse/ARTIF-717 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Implement a CQRS pattern. The JPA entities should be used purely for writes and single-artifact reads. Queries should switch to using a new ArtifactSummary DTO with bare-bones data. All clients should reflect that as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 10:05:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Jun 2015 10:05:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-711) Performance enhancements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-711: ------------------------------ Description: Tracks necessary performance enhancements, discovered during profiling. Minor changes will be committed under this ticket. (was: Tracks necessary performance enhancements, discovered during profiling) > Performance enhancements > ------------------------ > > Key: ARTIF-711 > URL: https://issues.jboss.org/browse/ARTIF-711 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Tracks necessary performance enhancements, discovered during profiling. Minor changes will be committed under this ticket. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 11:37:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Jun 2015 11:37:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reopened ARTIF-674: ------------------------------- > Separate from the S-RAMP spec > ----------------------------- > > Key: ARTIF-674 > URL: https://issues.jboss.org/browse/ARTIF-674 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 2.0 > > > For 2.0, we might consider separating from the S-RAMP spec. IMO, the spec should be largely considered dead and abandoned. RH seems to be the only entity still "using" it. Further, many pieces are starting to hold things back, in addition to adding needless complexity. Instead of focusing on conformance, use only "the good parts". Claim that the project is "loosely based on S-RAMP". > Ideas: > REMOVE > - Atom binding: Instead, use pure JSON REST > - The web UI services: With the server services using JSON REST, we'd no longer need an additional service layer specifically for the web UI. > - All "s-ramp" namespaces > KEEP > - Model schemas and bindings. > - Query core syntax -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 11:39:16 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Jun 2015 11:39:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-674) Separate from the S-RAMP spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081171#comment-13081171 ] Brett Meyer commented on ARTIF-674: ----------------------------------- Re-opening for consideration in 2.0. I recently started a thread on the S-RAMP spec mailing list, asking whether or not the members were interested in continuing the work. It's been extremely silent since last year. It's looking more and more like the spec is dead. IBM and WSO2, the 2 other major players, confirmed they're out. Everyone else is silent. I've honestly stopped caring about conformance in Artificer 1.x. Most of the non-conformance is due to sheer necessity or performance problems caused by the nature of a few requirements. The issues could potentially be addressed in a new spec version, but there's 0 chance of a quorum. I'd rather keep what we have for 1.x (but not worry about conformance), then potentially strip it out entirely for 2.0. The amount of work to maintain is *not* worth it, I think. Further, the spec really ties our hands behind our backs with its model schemas and Atom-based craziness. The new models we're discussing, the general extensibility, and other things on the roadmap will require a more streamlined, simple JSON approach. We could theoretically attempt to maintain an Atom binding in addition to that, but I'd argue that it's pointless. > Separate from the S-RAMP spec > ----------------------------- > > Key: ARTIF-674 > URL: https://issues.jboss.org/browse/ARTIF-674 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 2.0 > > > For 2.0, we might consider separating from the S-RAMP spec. IMO, the spec should be largely considered dead and abandoned. RH seems to be the only entity still "using" it. Further, many pieces are starting to hold things back, in addition to adding needless complexity. Instead of focusing on conformance, use only "the good parts". Claim that the project is "loosely based on S-RAMP". > Ideas: > REMOVE > - Atom binding: Instead, use pure JSON REST > - The web UI services: With the server services using JSON REST, we'd no longer need an additional service layer specifically for the web UI. > - All "s-ramp" namespaces > KEEP > - Model schemas and bindings. > - Query core syntax -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 20:48:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Jun 2015 20:48:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-717) Implement a CQRS pattern, separating the JPA entities and a query DTO In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-717. ------------------------------- Resolution: Done > Implement a CQRS pattern, separating the JPA entities and a query DTO > --------------------------------------------------------------------- > > Key: ARTIF-717 > URL: https://issues.jboss.org/browse/ARTIF-717 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Implement a CQRS pattern. The JPA entities should be used purely for writes and single-artifact reads. Queries should switch to using a new ArtifactSummary DTO with bare-bones data. All clients should reflect that as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 20:49:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Jun 2015 20:49:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-711) Performance enhancements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-711. ------------------------------- Resolution: Done > Performance enhancements > ------------------------ > > Key: ARTIF-711 > URL: https://issues.jboss.org/browse/ARTIF-711 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Tracks necessary performance enhancements, discovered during profiling. Minor changes will be committed under this ticket. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 21:10:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Jun 2015 21:10:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-704) CLI: Disable's aesh's 'man' command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-704. ------------------------------- Resolution: Done > CLI: Disable's aesh's 'man' command > ----------------------------------- > > Key: ARTIF-704 > URL: https://issues.jboss.org/browse/ARTIF-704 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Ex: > artificer> man getMetaData > Exception when parsing/running: man getMetaData, null -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 21:30:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Jun 2015 21:30:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-700) Minor UI fixes for 1.0.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-700: ------------------------------ Description: - the source text box can be taller now that Overview is a separate tab - the login theme looks "weird" and isn't spaced out properly was:- the source text box can be taller now that Overview is a separate tab > Minor UI fixes for 1.0.0 > ------------------------ > > Key: ARTIF-700 > URL: https://issues.jboss.org/browse/ARTIF-700 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > - the source text box can be taller now that Overview is a separate tab > - the login theme looks "weird" and isn't spaced out properly -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 11:09:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 11:09:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-718) EAP 6.4: Hibernate Search fails to create indexes on startup In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-718: --------------------------------- Summary: EAP 6.4: Hibernate Search fails to create indexes on startup Key: ARTIF-718 URL: https://issues.jboss.org/browse/ARTIF-718 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Environment: EAP 6.4 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 {code} 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-7) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' 11:54:21,035 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes/org.artificer.repository.hibernate.entity.ArtificerArtifact' 11:54:21,037 ERROR [org.artificer.server.atom.workspaces.StoredQueryWorkspace] (http-/127.0.0.1:8080-7) Error getting the list of stored queries.: org.artificer.common.error.ArtificerServerException: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:87) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.repository.hibernate.HibernatePersistenceManager.getStoredQueries(HibernatePersistenceManager.java:468) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.server.atom.workspaces.StoredQueryWorkspace.configureWorkspace(StoredQueryWorkspace.java:57) [classes:] at org.artificer.server.atom.workspaces.AbstractWorkspace.(AbstractWorkspace.java:51) [classes:] at org.artificer.server.atom.workspaces.StoredQueryWorkspace.(StoredQueryWorkspace.java:46) [classes:] at org.artificer.server.atom.services.ServiceDocumentResource.get(ServiceDocumentResource.java:88) [classes:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_76] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_76] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_76] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_76] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.artificer.repository.filter.ServletCredentialsFilter.doFilter(ServletCredentialsFilter.java:45) [artificer-repository-1.0.0.Beta1.jar:1.0.0.Beta1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:264) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:238) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.artificer.server.filters.LocaleFilter.doFilter(LocaleFilter.java:59) [classes:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] Caused by: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:265) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:528) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:495) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:104) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:364) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:219) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:74) [hibernate-search-orm-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:52) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:575) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1799) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.EntityManagerFactoryImpl.(EntityManagerFactoryImpl.java:96) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:915) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:900) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:59) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.artificer.repository.hibernate.HibernateUtil.entityManager(HibernateUtil.java:109) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.repository.hibernate.HibernateUtil.access$000(HibernateUtil.java:48) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:62) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] ... 50 more Caused by: org.hibernate.search.SearchException: Unable to initialize directory provider: org.artificer.repository.hibernate.entity.ArtificerArtifact at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:91) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:212) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:99) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:261) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] ... 67 more Caused by: org.hibernate.search.SearchException: Unable to create index directory: /home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes for index org.artificer.repository.hibernate.entity.ArtificerArtifact at org.hibernate.search.store.impl.DirectoryProviderHelper.makeSanityCheckedDirectory(DirectoryProviderHelper.java:276) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.store.impl.DirectoryProviderHelper.getVerifiedIndexDir(DirectoryProviderHelper.java:258) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.store.impl.FSDirectoryProvider.initialize(FSDirectoryProvider.java:66) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:88) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] ... 70 more {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 11:10:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 11:10:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-719) EAP 6.4: CNFE on an Errai marshalling class In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-719: --------------------------------- Summary: EAP 6.4: CNFE on an Errai marshalling class Key: ARTIF-719 URL: https://issues.jboss.org/browse/ARTIF-719 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Environment: EAP 6.4 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 {code} 13:03:16,821 WARN [org.jboss.modules] (MSC service thread 1-7) Failed to define class org.jboss.errai.marshalling.server.impl.ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl in Module "deployment.artificer-ui.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/errai/marshalling/server/impl/ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl (Module "deployment.artificer-ui.war:main" from Service Module Loader) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:487) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:109) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:137) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:63) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_76] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_76] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] Caused by: java.lang.NoClassDefFoundError: org/jboss/errai/marshalling/client/api/GeneratedMarshaller at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_76] at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_76] at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.6.Final-redhat-1] ... 20 more Caused by: java.lang.ClassNotFoundException: org.jboss.errai.marshalling.client.api.GeneratedMarshaller from [Module "deployment.artificer-ui.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] ... 24 more {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 11:15:05 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 11:15:05 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-720) Inconsistencies in demos parent POM In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-720: --------------------------------- Summary: Inconsistencies in demos parent POM Key: ARTIF-720 URL: https://issues.jboss.org/browse/ARTIF-720 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 {code} [WARNING] Some problems were encountered while building the effective model for org.artificer.demos:artificer-demos-simple-client:jar:1.0.0.Beta1 [WARNING] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: commons-beanutils:commons-beanutils-core:jar -> version ${version.commons-beanutils} vs 1.8.3 @ org.artificer:artificer:1.0.0.Beta1, /home/sbunciak/.m2/repository/org/artificer/artificer/1.0.0.Beta1/artificer-1.0.0.Beta1.pom, line 752, column 19 {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 11:16:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 11:16:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-721) Don't use positional parameters with JPQL queries In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-721: --------------------------------- Summary: Don't use positional parameters with JPQL queries Key: ARTIF-721 URL: https://issues.jboss.org/browse/ARTIF-721 Project: Artificer Issue Type: Task Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 {code} 13:06:46,788 WARN [org.hibernate.hql.internal.ast.HqlSqlWalker] (http-localhost/127.0.0.1:8080-7) [DEPRECATION] Encountered positional parameter near line 1, column 105. Positional parameter are considered deprecated; use named parameters or JPA-style positional parameters instead. {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 11:35:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 11:35:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-721) Don't use positional parameters with JPQL queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-721. ------------------------------- Resolution: Done > Don't use positional parameters with JPQL queries > ------------------------------------------------- > > Key: ARTIF-721 > URL: https://issues.jboss.org/browse/ARTIF-721 > Project: Artificer > Issue Type: Task > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > {code} > 13:06:46,788 WARN [org.hibernate.hql.internal.ast.HqlSqlWalker] (http-localhost/127.0.0.1:8080-7) [DEPRECATION] Encountered positional parameter near line 1, column 105. Positional parameter are considered deprecated; use named parameters or JPA-style positional parameters instead. > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 11:35:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 11:35:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-720) Inconsistencies in demos parent POM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-720: ------------------------------ Description: [WARNING] Some problems were encountered while building the effective model for org.artificer.demos:artificer-demos-simple-client:jar:1.0.0.Beta1 [WARNING] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: commons-beanutils:commons-beanutils-core:jar -> version ${version.commons-beanutils} vs 1.8.3 @ org.artificer:artificer:1.0.0.Beta1, /home/sbunciak/.m2/repository/org/artificer/artificer/1.0.0.Beta1/artificer-1.0.0.Beta1.pom, line 752, column 19 was: {code} [WARNING] Some problems were encountered while building the effective model for org.artificer.demos:artificer-demos-simple-client:jar:1.0.0.Beta1 [WARNING] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: commons-beanutils:commons-beanutils-core:jar -> version ${version.commons-beanutils} vs 1.8.3 @ org.artificer:artificer:1.0.0.Beta1, /home/sbunciak/.m2/repository/org/artificer/artificer/1.0.0.Beta1/artificer-1.0.0.Beta1.pom, line 752, column 19 {code} > Inconsistencies in demos parent POM > ----------------------------------- > > Key: ARTIF-720 > URL: https://issues.jboss.org/browse/ARTIF-720 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > [WARNING] Some problems were encountered while building the effective model for org.artificer.demos:artificer-demos-simple-client:jar:1.0.0.Beta1 > [WARNING] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: commons-beanutils:commons-beanutils-core:jar -> version ${version.commons-beanutils} vs 1.8.3 @ org.artificer:artificer:1.0.0.Beta1, /home/sbunciak/.m2/repository/org/artificer/artificer/1.0.0.Beta1/artificer-1.0.0.Beta1.pom, line 752, column 19 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 11:41:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 11:41:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-720) Inconsistencies in demos parent POM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-720. ------------------------------- Resolution: Done > Inconsistencies in demos parent POM > ----------------------------------- > > Key: ARTIF-720 > URL: https://issues.jboss.org/browse/ARTIF-720 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > [WARNING] Some problems were encountered while building the effective model for org.artificer.demos:artificer-demos-simple-client:jar:1.0.0.Beta1 > [WARNING] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: commons-beanutils:commons-beanutils-core:jar -> version ${version.commons-beanutils} vs 1.8.3 @ org.artificer:artificer:1.0.0.Beta1, /home/sbunciak/.m2/repository/org/artificer/artificer/1.0.0.Beta1/artificer-1.0.0.Beta1.pom, line 752, column 19 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 11:42:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 11:42:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-719) EAP 6.4: CNFE on an Errai marshalling class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-719: ------------------------------ Description: 13:03:16,821 WARN [org.jboss.modules] (MSC service thread 1-7) Failed to define class org.jboss.errai.marshalling.server.impl.ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl in Module "deployment.artificer-ui.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/errai/marshalling/server/impl/ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl (Module "deployment.artificer-ui.war:main" from Service Module Loader) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:487) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:109) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:137) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:63) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_76] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_76] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] Caused by: java.lang.NoClassDefFoundError: org/jboss/errai/marshalling/client/api/GeneratedMarshaller at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_76] at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_76] at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.6.Final-redhat-1] ... 20 more Caused by: java.lang.ClassNotFoundException: org.jboss.errai.marshalling.client.api.GeneratedMarshaller from [Module "deployment.artificer-ui.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] ... 24 more was: {code} 13:03:16,821 WARN [org.jboss.modules] (MSC service thread 1-7) Failed to define class org.jboss.errai.marshalling.server.impl.ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl in Module "deployment.artificer-ui.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/errai/marshalling/server/impl/ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl (Module "deployment.artificer-ui.war:main" from Service Module Loader) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:487) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:109) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:137) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:63) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_76] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_76] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] Caused by: java.lang.NoClassDefFoundError: org/jboss/errai/marshalling/client/api/GeneratedMarshaller at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_76] at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_76] at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.6.Final-redhat-1] ... 20 more Caused by: java.lang.ClassNotFoundException: org.jboss.errai.marshalling.client.api.GeneratedMarshaller from [Module "deployment.artificer-ui.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] ... 24 more {code} > EAP 6.4: CNFE on an Errai marshalling class > ------------------------------------------- > > Key: ARTIF-719 > URL: https://issues.jboss.org/browse/ARTIF-719 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: EAP 6.4 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > 13:03:16,821 WARN [org.jboss.modules] (MSC service thread 1-7) Failed to define class org.jboss.errai.marshalling.server.impl.ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl in Module "deployment.artificer-ui.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/errai/marshalling/server/impl/ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl (Module "deployment.artificer-ui.war:main" from Service Module Loader) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:487) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:109) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:137) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:63) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_76] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_76] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] > Caused by: java.lang.NoClassDefFoundError: org/jboss/errai/marshalling/client/api/GeneratedMarshaller > at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_76] > at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_76] > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.6.Final-redhat-1] > ... 20 more > Caused by: java.lang.ClassNotFoundException: org.jboss.errai.marshalling.client.api.GeneratedMarshaller from [Module "deployment.artificer-ui.war:main" from Service Module Loader] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] > ... 24 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 11:56:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 11:56:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-719) EAP 6.4: CNFE on an Errai marshalling class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-719. ------------------------------- Resolution: Done > EAP 6.4: CNFE on an Errai marshalling class > ------------------------------------------- > > Key: ARTIF-719 > URL: https://issues.jboss.org/browse/ARTIF-719 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: EAP 6.4 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > 13:03:16,821 WARN [org.jboss.modules] (MSC service thread 1-7) Failed to define class org.jboss.errai.marshalling.server.impl.ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl in Module "deployment.artificer-ui.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/errai/marshalling/server/impl/ServerMarshallingFactoryImpl$Marshaller_for_java_lang_StackTraceElementImpl (Module "deployment.artificer-ui.war:main" from Service Module Loader) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:487) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:277) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:92) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.Module.loadModuleClass(Module.java:568) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:109) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:137) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349) [weld-core-1.1.28.Final-redhat-1.jar:1.1.28.Final-redhat-1] > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:63) [jboss-as-weld-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_76] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_76] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] > Caused by: java.lang.NoClassDefFoundError: org/jboss/errai/marshalling/client/api/GeneratedMarshaller > at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_76] > at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_76] > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.6.Final-redhat-1] > ... 20 more > Caused by: java.lang.ClassNotFoundException: org.jboss.errai.marshalling.client.api.GeneratedMarshaller from [Module "deployment.artificer-ui.war:main" from Service Module Loader] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] > ... 24 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 12:27:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 12:27:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-718) EAP 6.4: Hibernate Search fails to create indexes on startup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-718: ------------------------------ Description: 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-7) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' 11:54:21,035 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes/org.artificer.repository.hibernate.entity.ArtificerArtifact' 11:54:21,037 ERROR [org.artificer.server.atom.workspaces.StoredQueryWorkspace] (http-/127.0.0.1:8080-7) Error getting the list of stored queries.: org.artificer.common.error.ArtificerServerException: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:87) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.repository.hibernate.HibernatePersistenceManager.getStoredQueries(HibernatePersistenceManager.java:468) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.server.atom.workspaces.StoredQueryWorkspace.configureWorkspace(StoredQueryWorkspace.java:57) [classes:] at org.artificer.server.atom.workspaces.AbstractWorkspace.(AbstractWorkspace.java:51) [classes:] at org.artificer.server.atom.workspaces.StoredQueryWorkspace.(StoredQueryWorkspace.java:46) [classes:] at org.artificer.server.atom.services.ServiceDocumentResource.get(ServiceDocumentResource.java:88) [classes:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_76] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_76] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_76] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_76] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.artificer.repository.filter.ServletCredentialsFilter.doFilter(ServletCredentialsFilter.java:45) [artificer-repository-1.0.0.Beta1.jar:1.0.0.Beta1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:264) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:238) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.artificer.server.filters.LocaleFilter.doFilter(LocaleFilter.java:59) [classes:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] Caused by: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:265) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:528) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:495) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:104) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:364) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:219) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:74) [hibernate-search-orm-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:52) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:575) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1799) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.EntityManagerFactoryImpl.(EntityManagerFactoryImpl.java:96) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:915) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:900) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:59) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.artificer.repository.hibernate.HibernateUtil.entityManager(HibernateUtil.java:109) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.repository.hibernate.HibernateUtil.access$000(HibernateUtil.java:48) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:62) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] ... 50 more Caused by: org.hibernate.search.SearchException: Unable to initialize directory provider: org.artificer.repository.hibernate.entity.ArtificerArtifact at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:91) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:212) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:99) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:261) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] ... 67 more Caused by: org.hibernate.search.SearchException: Unable to create index directory: /home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes for index org.artificer.repository.hibernate.entity.ArtificerArtifact at org.hibernate.search.store.impl.DirectoryProviderHelper.makeSanityCheckedDirectory(DirectoryProviderHelper.java:276) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.store.impl.DirectoryProviderHelper.getVerifiedIndexDir(DirectoryProviderHelper.java:258) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.store.impl.FSDirectoryProvider.initialize(FSDirectoryProvider.java:66) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:88) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] ... 70 more was: {code} 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-7) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' 11:54:21,035 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes/org.artificer.repository.hibernate.entity.ArtificerArtifact' 11:54:21,037 ERROR [org.artificer.server.atom.workspaces.StoredQueryWorkspace] (http-/127.0.0.1:8080-7) Error getting the list of stored queries.: org.artificer.common.error.ArtificerServerException: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:87) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.repository.hibernate.HibernatePersistenceManager.getStoredQueries(HibernatePersistenceManager.java:468) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.server.atom.workspaces.StoredQueryWorkspace.configureWorkspace(StoredQueryWorkspace.java:57) [classes:] at org.artificer.server.atom.workspaces.AbstractWorkspace.(AbstractWorkspace.java:51) [classes:] at org.artificer.server.atom.workspaces.StoredQueryWorkspace.(StoredQueryWorkspace.java:46) [classes:] at org.artificer.server.atom.services.ServiceDocumentResource.get(ServiceDocumentResource.java:88) [classes:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_76] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_76] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_76] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_76] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.artificer.repository.filter.ServletCredentialsFilter.doFilter(ServletCredentialsFilter.java:45) [artificer-repository-1.0.0.Beta1.jar:1.0.0.Beta1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:264) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:238) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.artificer.server.filters.LocaleFilter.doFilter(LocaleFilter.java:59) [classes:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] Caused by: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:265) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:528) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:495) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:104) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:364) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:219) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:74) [hibernate-search-orm-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:52) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:575) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1799) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.EntityManagerFactoryImpl.(EntityManagerFactoryImpl.java:96) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:915) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:900) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:59) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] at org.artificer.repository.hibernate.HibernateUtil.entityManager(HibernateUtil.java:109) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.repository.hibernate.HibernateUtil.access$000(HibernateUtil.java:48) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:62) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] ... 50 more Caused by: org.hibernate.search.SearchException: Unable to initialize directory provider: org.artificer.repository.hibernate.entity.ArtificerArtifact at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:91) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:212) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:99) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:261) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] ... 67 more Caused by: org.hibernate.search.SearchException: Unable to create index directory: /home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes for index org.artificer.repository.hibernate.entity.ArtificerArtifact at org.hibernate.search.store.impl.DirectoryProviderHelper.makeSanityCheckedDirectory(DirectoryProviderHelper.java:276) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.store.impl.DirectoryProviderHelper.getVerifiedIndexDir(DirectoryProviderHelper.java:258) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.store.impl.FSDirectoryProvider.initialize(FSDirectoryProvider.java:66) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:88) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] ... 70 more {code} > EAP 6.4: Hibernate Search fails to create indexes on startup > ------------------------------------------------------------ > > Key: ARTIF-718 > URL: https://issues.jboss.org/browse/ARTIF-718 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: EAP 6.4 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' > 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-7) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' > 11:54:21,035 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes/org.artificer.repository.hibernate.entity.ArtificerArtifact' > 11:54:21,037 ERROR [org.artificer.server.atom.workspaces.StoredQueryWorkspace] (http-/127.0.0.1:8080-7) Error getting the list of stored queries.: org.artificer.common.error.ArtificerServerException: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:87) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernatePersistenceManager.getStoredQueries(HibernatePersistenceManager.java:468) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.server.atom.workspaces.StoredQueryWorkspace.configureWorkspace(StoredQueryWorkspace.java:57) [classes:] > at org.artificer.server.atom.workspaces.AbstractWorkspace.(AbstractWorkspace.java:51) [classes:] > at org.artificer.server.atom.workspaces.StoredQueryWorkspace.(StoredQueryWorkspace.java:46) [classes:] > at org.artificer.server.atom.services.ServiceDocumentResource.get(ServiceDocumentResource.java:88) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_76] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_76] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_76] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_76] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.artificer.repository.filter.ServletCredentialsFilter.doFilter(ServletCredentialsFilter.java:45) [artificer-repository-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:264) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:238) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.artificer.server.filters.LocaleFilter.doFilter(LocaleFilter.java:59) [classes:] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] > Caused by: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:265) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:528) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:495) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:104) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:364) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:219) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:74) [hibernate-search-orm-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:52) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:575) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1799) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.EntityManagerFactoryImpl.(EntityManagerFactoryImpl.java:96) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:915) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:900) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:59) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.artificer.repository.hibernate.HibernateUtil.entityManager(HibernateUtil.java:109) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernateUtil.access$000(HibernateUtil.java:48) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:62) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > ... 50 more > Caused by: org.hibernate.search.SearchException: Unable to initialize directory provider: org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:91) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:212) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:99) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:261) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > ... 67 more > Caused by: org.hibernate.search.SearchException: Unable to create index directory: /home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes for index org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.store.impl.DirectoryProviderHelper.makeSanityCheckedDirectory(DirectoryProviderHelper.java:276) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.DirectoryProviderHelper.getVerifiedIndexDir(DirectoryProviderHelper.java:258) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.FSDirectoryProvider.initialize(FSDirectoryProvider.java:66) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:88) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > ... 70 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 12:30:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 12:30:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-718) hibernate.search.default.indexBase default uses relative path In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-718: ------------------------------ Summary: hibernate.search.default.indexBase default uses relative path (was: EAP 6.4: Hibernate Search fails to create indexes on startup) > hibernate.search.default.indexBase default uses relative path > ------------------------------------------------------------- > > Key: ARTIF-718 > URL: https://issues.jboss.org/browse/ARTIF-718 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: EAP 6.4 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' > 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-7) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' > 11:54:21,035 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes/org.artificer.repository.hibernate.entity.ArtificerArtifact' > 11:54:21,037 ERROR [org.artificer.server.atom.workspaces.StoredQueryWorkspace] (http-/127.0.0.1:8080-7) Error getting the list of stored queries.: org.artificer.common.error.ArtificerServerException: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:87) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernatePersistenceManager.getStoredQueries(HibernatePersistenceManager.java:468) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.server.atom.workspaces.StoredQueryWorkspace.configureWorkspace(StoredQueryWorkspace.java:57) [classes:] > at org.artificer.server.atom.workspaces.AbstractWorkspace.(AbstractWorkspace.java:51) [classes:] > at org.artificer.server.atom.workspaces.StoredQueryWorkspace.(StoredQueryWorkspace.java:46) [classes:] > at org.artificer.server.atom.services.ServiceDocumentResource.get(ServiceDocumentResource.java:88) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_76] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_76] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_76] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_76] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.artificer.repository.filter.ServletCredentialsFilter.doFilter(ServletCredentialsFilter.java:45) [artificer-repository-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:264) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:238) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.artificer.server.filters.LocaleFilter.doFilter(LocaleFilter.java:59) [classes:] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] > Caused by: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:265) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:528) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:495) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:104) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:364) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:219) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:74) [hibernate-search-orm-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:52) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:575) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1799) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.EntityManagerFactoryImpl.(EntityManagerFactoryImpl.java:96) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:915) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:900) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:59) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.artificer.repository.hibernate.HibernateUtil.entityManager(HibernateUtil.java:109) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernateUtil.access$000(HibernateUtil.java:48) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:62) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > ... 50 more > Caused by: org.hibernate.search.SearchException: Unable to initialize directory provider: org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:91) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:212) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:99) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:261) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > ... 67 more > Caused by: org.hibernate.search.SearchException: Unable to create index directory: /home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes for index org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.store.impl.DirectoryProviderHelper.makeSanityCheckedDirectory(DirectoryProviderHelper.java:276) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.DirectoryProviderHelper.getVerifiedIndexDir(DirectoryProviderHelper.java:258) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.FSDirectoryProvider.initialize(FSDirectoryProvider.java:66) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:88) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > ... 70 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 12:31:05 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 12:31:05 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-718) hibernate.search.default.indexBase default uses relative path In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081771#comment-13081771 ] Brett Meyer commented on ARTIF-718: ----------------------------------- By default, artificer.properties uses: 'hibernate.search.default.indexBase = lucene/indexes' But that's entirely dependent on the location from which you start EAP/Wildfly. Realistically, there is *not* a good default to use that will work for everyone. Instead, I've better highlighted this property in the doc's "Server Configuration" section. > hibernate.search.default.indexBase default uses relative path > ------------------------------------------------------------- > > Key: ARTIF-718 > URL: https://issues.jboss.org/browse/ARTIF-718 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: EAP 6.4 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' > 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-7) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' > 11:54:21,035 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes/org.artificer.repository.hibernate.entity.ArtificerArtifact' > 11:54:21,037 ERROR [org.artificer.server.atom.workspaces.StoredQueryWorkspace] (http-/127.0.0.1:8080-7) Error getting the list of stored queries.: org.artificer.common.error.ArtificerServerException: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:87) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernatePersistenceManager.getStoredQueries(HibernatePersistenceManager.java:468) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.server.atom.workspaces.StoredQueryWorkspace.configureWorkspace(StoredQueryWorkspace.java:57) [classes:] > at org.artificer.server.atom.workspaces.AbstractWorkspace.(AbstractWorkspace.java:51) [classes:] > at org.artificer.server.atom.workspaces.StoredQueryWorkspace.(StoredQueryWorkspace.java:46) [classes:] > at org.artificer.server.atom.services.ServiceDocumentResource.get(ServiceDocumentResource.java:88) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_76] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_76] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_76] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_76] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.artificer.repository.filter.ServletCredentialsFilter.doFilter(ServletCredentialsFilter.java:45) [artificer-repository-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:264) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:238) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.artificer.server.filters.LocaleFilter.doFilter(LocaleFilter.java:59) [classes:] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] > Caused by: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:265) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:528) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:495) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:104) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:364) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:219) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:74) [hibernate-search-orm-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:52) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:575) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1799) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.EntityManagerFactoryImpl.(EntityManagerFactoryImpl.java:96) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:915) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:900) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:59) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.artificer.repository.hibernate.HibernateUtil.entityManager(HibernateUtil.java:109) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernateUtil.access$000(HibernateUtil.java:48) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:62) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > ... 50 more > Caused by: org.hibernate.search.SearchException: Unable to initialize directory provider: org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:91) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:212) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:99) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:261) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > ... 67 more > Caused by: org.hibernate.search.SearchException: Unable to create index directory: /home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes for index org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.store.impl.DirectoryProviderHelper.makeSanityCheckedDirectory(DirectoryProviderHelper.java:276) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.DirectoryProviderHelper.getVerifiedIndexDir(DirectoryProviderHelper.java:258) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.FSDirectoryProvider.initialize(FSDirectoryProvider.java:66) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:88) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > ... 70 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 12:32:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 12:32:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-718) hibernate.search.default.indexBase default uses relative path In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-718. ------------------------------- Resolution: Done > hibernate.search.default.indexBase default uses relative path > ------------------------------------------------------------- > > Key: ARTIF-718 > URL: https://issues.jboss.org/browse/ARTIF-718 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Environment: EAP 6.4 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' > 11:54:21,034 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-7) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes' > 11:54:21,035 INFO [org.hibernate.search.store.impl.DirectoryProviderHelper] (http-/127.0.0.1:8080-8) HSEARCH000041: Index directory not found, creating: '/home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes/org.artificer.repository.hibernate.entity.ArtificerArtifact' > 11:54:21,037 ERROR [org.artificer.server.atom.workspaces.StoredQueryWorkspace] (http-/127.0.0.1:8080-7) Error getting the list of stored queries.: org.artificer.common.error.ArtificerServerException: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:87) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernatePersistenceManager.getStoredQueries(HibernatePersistenceManager.java:468) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.server.atom.workspaces.StoredQueryWorkspace.configureWorkspace(StoredQueryWorkspace.java:57) [classes:] > at org.artificer.server.atom.workspaces.AbstractWorkspace.(AbstractWorkspace.java:51) [classes:] > at org.artificer.server.atom.workspaces.StoredQueryWorkspace.(StoredQueryWorkspace.java:46) [classes:] > at org.artificer.server.atom.services.ServiceDocumentResource.get(ServiceDocumentResource.java:88) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_76] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_76] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_76] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_76] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.artificer.repository.filter.ServletCredentialsFilter.doFilter(ServletCredentialsFilter.java:45) [artificer-repository-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:264) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:238) [overlord-commons-auth-2.0.14.Final.jar:2.0.14.Final] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.artificer.server.filters.LocaleFilter.doFilter(LocaleFilter.java:59) [classes:] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_76] > Caused by: org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:265) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:528) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:495) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:104) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:364) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:219) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:143) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.hcore.impl.HibernateSearchSessionFactoryObserver.sessionFactoryCreated(HibernateSearchSessionFactoryObserver.java:74) [hibernate-search-orm-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.internal.SessionFactoryObserverChain.sessionFactoryCreated(SessionFactoryObserverChain.java:52) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:575) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1799) [hibernate-core-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.EntityManagerFactoryImpl.(EntityManagerFactoryImpl.java:96) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:915) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:900) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:59) [hibernate-entitymanager-4.2.18.Final-redhat-2.jar:4.2.18.Final-redhat-2] > at org.artificer.repository.hibernate.HibernateUtil.entityManager(HibernateUtil.java:109) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernateUtil.access$000(HibernateUtil.java:48) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > at org.artificer.repository.hibernate.HibernateUtil$HibernateTask.execute(HibernateUtil.java:62) [artificer-repository-hibernate-1.0.0.Beta1.jar:1.0.0.Beta1] > ... 50 more > Caused by: org.hibernate.search.SearchException: Unable to initialize directory provider: org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:91) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:212) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:99) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:261) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > ... 67 more > Caused by: org.hibernate.search.SearchException: Unable to create index directory: /home/sbunciak/runtimes/artificer-jboss-eap-6.4/bin/lucene/indexes for index org.artificer.repository.hibernate.entity.ArtificerArtifact > at org.hibernate.search.store.impl.DirectoryProviderHelper.makeSanityCheckedDirectory(DirectoryProviderHelper.java:276) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.DirectoryProviderHelper.getVerifiedIndexDir(DirectoryProviderHelper.java:258) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.FSDirectoryProvider.initialize(FSDirectoryProvider.java:66) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:88) [hibernate-search-engine-4.6.0.Final-redhat-2.jar:4.6.0.Final-redhat-2] > ... 70 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 13:20:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 13:20:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-722) Solely use Hibernate Search if query is limited to full-text search and indexed columns In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-722: --------------------------------- Summary: Solely use Hibernate Search if query is limited to full-text search and indexed columns Key: ARTIF-722 URL: https://issues.jboss.org/browse/ARTIF-722 Project: Artificer Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. This idea could be expanded to include most built-in properties. Name, description, content hash, etc. could all be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 13:22:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 13:22:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-722) Solely use Hibernate Search if query is limited to full-text search and indexed columns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-722: ------------------------------ Description: Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. This idea implies that all properties included in ArtifactSummary would need to be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. was: Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. This idea could be expanded to include most built-in properties. Name, description, content hash, etc. could all be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. > Solely use Hibernate Search if query is limited to full-text search and indexed columns > --------------------------------------------------------------------------------------- > > Key: ARTIF-722 > URL: https://issues.jboss.org/browse/ARTIF-722 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: > /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] > Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. > This idea implies that all properties included in ArtifactSummary would need to be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 17:09:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 17:09:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-722) Solely use Hibernate Search if query is limited to full-text search and indexed columns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-722: ------------------------------ Parent: ARTIF-711 Issue Type: Sub-task (was: Enhancement) > Solely use Hibernate Search if query is limited to full-text search and indexed columns > --------------------------------------------------------------------------------------- > > Key: ARTIF-722 > URL: https://issues.jboss.org/browse/ARTIF-722 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: > /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] > Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. > This idea implies that all properties included in ArtifactSummary would need to be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 17:46:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Jun 2015 17:46:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-722) Solely use Hibernate Search if query is limited to full-text search and indexed columns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-722 started by Brett Meyer. ----------------------------------------- > Solely use Hibernate Search if query is limited to full-text search and indexed columns > --------------------------------------------------------------------------------------- > > Key: ARTIF-722 > URL: https://issues.jboss.org/browse/ARTIF-722 > Project: Artificer > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: > /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] > Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. > This idea implies that all properties included in ArtifactSummary would need to be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 11:25:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 11:25:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-722) Solely use Hibernate Search if query is limited to full-text search and indexed columns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-722: ------------------------------ Parent: (was: ARTIF-711) Issue Type: Feature Request (was: Sub-task) > Solely use Hibernate Search if query is limited to full-text search and indexed columns > --------------------------------------------------------------------------------------- > > Key: ARTIF-722 > URL: https://issues.jboss.org/browse/ARTIF-722 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: > /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] > Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. > This idea implies that all properties included in ArtifactSummary would need to be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 11:25:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 11:25:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-722) Solely use Hibernate Search if query is limited to full-text search and indexed columns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-722 stopped by Brett Meyer. ----------------------------------------- > Solely use Hibernate Search if query is limited to full-text search and indexed columns > --------------------------------------------------------------------------------------- > > Key: ARTIF-722 > URL: https://issues.jboss.org/browse/ARTIF-722 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: > /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] > Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. > This idea implies that all properties included in ArtifactSummary would need to be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 11:25:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 11:25:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-722) Solely use Hibernate Search if query is limited to full-text search and indexed columns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-722: ------------------------------ Fix Version/s: (was: 1.0.0.Beta2) > Solely use Hibernate Search if query is limited to full-text search and indexed columns > --------------------------------------------------------------------------------------- > > Key: ARTIF-722 > URL: https://issues.jboss.org/browse/ARTIF-722 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: > /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] > Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. > This idea implies that all properties included in ArtifactSummary would need to be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 11:28:10 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 11:28:10 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-722) Solely use Hibernate Search if query is limited to full-text search and indexed columns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082244#comment-13082244 ] Brett Meyer commented on ARTIF-722: ----------------------------------- WIP: https://github.com/ArtificerRepo/artificer/compare/master...brmeyer:ARTIF-722 If we go this route, it will have to wait until we no longer support EAP 6 (or can upgrade to Hibernate 4.3.x). The DelayedPredicate concept relies on SPI that changed between 4.2/4.3. There may be a better way to do it, but... Realistically, I'm not sure how useful this is. With proper indexing at the DB level, the queries tend to be fast anyway. Users will also almost always be using paging, further reducing the necessity for this level of improvement. Re-visit sometime in the future. > Solely use Hibernate Search if query is limited to full-text search and indexed columns > --------------------------------------------------------------------------------------- > > Key: ARTIF-722 > URL: https://issues.jboss.org/browse/ARTIF-722 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Now that queries return a summary DTO, if a query only contains full-text search and columns indexed by Lucene, Hibernate Search can be solely used. There is no need to also execute the SQL query. For example: > /s-ramp/xsd/XsdDocument[xp2:matches(., 'FizzBuzz')] > Since 'model' and 'type' are both indexed, this could be accomplished entirely with the Lucene query, skipping SQL. > This idea implies that all properties included in ArtifactSummary would need to be indexed as well. SQL would be needed only when custom properties, ontologies, or relationships are required. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 12:32:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 12:32:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-700) Minor UI fixes for 1.0.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-700 started by Brett Meyer. ----------------------------------------- > Minor UI fixes for 1.0.0 > ------------------------ > > Key: ARTIF-700 > URL: https://issues.jboss.org/browse/ARTIF-700 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > - the source text box can be taller now that Overview is a separate tab > - the login theme looks "weird" and isn't spaced out properly -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 12:41:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 12:41:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-700) Minor UI fixes for 1.0.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-700. ------------------------------- Resolution: Done > Minor UI fixes for 1.0.0 > ------------------------ > > Key: ARTIF-700 > URL: https://issues.jboss.org/browse/ARTIF-700 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > - the source text box can be taller now that Overview is a separate tab > - the login theme looks "weird" and isn't spaced out properly -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:21:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 14:21:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-723) Web UI upload status never completes for large files In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-723: --------------------------------- Summary: Web UI upload status never completes for large files Key: ARTIF-723 URL: https://issues.jboss.org/browse/ARTIF-723 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Upload a large distro (example, the actual Artificer distro ZIP). It's expanded and processed correctly, but the upload status never completes. Timeout? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:23:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 14:23:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-724) Creation timestamp not always persisted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082321#comment-13082321 ] Brett Meyer commented on ARTIF-724: ----------------------------------- Although we should guarantee it's persisted, also check for nulls in QueryResultSet (just in case). > Creation timestamp not always persisted > --------------------------------------- > > Key: ARTIF-724 > URL: https://issues.jboss.org/browse/ARTIF-724 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > To reproduce: > 1.) Upload the Artificer distro zip > 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl > 3.) stack: > ... > Caused by: java.lang.NullPointerException > at java.util.Calendar.setTime(Calendar.java:1770) > at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) > at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) > at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) > ... 45 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:23:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 14:23:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-724) Creation timestamp not always persisted In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-724: --------------------------------- Summary: Creation timestamp not always persisted Key: ARTIF-724 URL: https://issues.jboss.org/browse/ARTIF-724 Project: Artificer Issue Type: Bug Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 To reproduce: 1.) Upload the Artificer distro zip 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl 3.) stack: ... Caused by: java.lang.NullPointerException at java.util.Calendar.setTime(Calendar.java:1770) at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) ... 45 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:25:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 14:25:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-725) Use new 'expandedFromArchivePath' field, rather than custom property In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-725: --------------------------------- Summary: Use new 'expandedFromArchivePath' field, rather than custom property Key: ARTIF-725 URL: https://issues.jboss.org/browse/ARTIF-725 Project: Artificer Issue Type: Enhancement Affects Versions: 1.0.0.Beta1 Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Currently, if an artifact is expanded, it populates a 'expanded.from.archive.path' custom property. Instead, move this to a new field on the Artifact itself. Note that, for now, this will need to be bound to an expansion entry. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:28:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 14:28:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-499) Include another filter for Expanded (similar to Derived) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reopened ARTIF-499: ------------------------------- Taking back what I said. Definitely needed, especially for large archives... > Include another filter for Expanded (similar to Derived) > -------------------------------------------------------- > > Key: ARTIF-499 > URL: https://issues.jboss.org/browse/ARTIF-499 > Project: Artificer > Issue Type: Enhancement > Reporter: Eric Wittmann > Assignee: Brett Meyer > > Reported by David via his 0.5.0.Beta1 testing: > "S-ramp Artifacts --> include another column called Expanded. > Then with this we can filter the original items (for example jars, war) from the files that are expanded from those Original Artifacts uploaded. > I continue thinking that when there are many artifadts uploaded it is difficult to filter and have an easy understanding of the artifact result list. For example you see a file kmodule.xml, and you do not know to what artifact it belongs. You need to enter in the artifact to have this information. And when the number of artifacts in s-ramp is so big, then you see many many files, that you have no idea about them. > If we include this expanded column and also filter field then we could have a view of the original artifacts (with no artifact parent property). > I will prepare a html mock with my idea..." -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:28:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 14:28:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-499) Include another filter for Expanded (similar to Derived) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-499: ------------------------------ Fix Version/s: 1.0.0.Beta2 > Include another filter for Expanded (similar to Derived) > -------------------------------------------------------- > > Key: ARTIF-499 > URL: https://issues.jboss.org/browse/ARTIF-499 > Project: Artificer > Issue Type: Enhancement > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Reported by David via his 0.5.0.Beta1 testing: > "S-ramp Artifacts --> include another column called Expanded. > Then with this we can filter the original items (for example jars, war) from the files that are expanded from those Original Artifacts uploaded. > I continue thinking that when there are many artifadts uploaded it is difficult to filter and have an easy understanding of the artifact result list. For example you see a file kmodule.xml, and you do not know to what artifact it belongs. You need to enter in the artifact to have this information. And when the number of artifacts in s-ramp is so big, then you see many many files, that you have no idea about them. > If we include this expanded column and also filter field then we could have a view of the original artifacts (with no artifact parent property). > I will prepare a html mock with my idea..." -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:30:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 14:30:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-709) Allow artifact expansion to be enabled/disabled during each upload In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-709: ------------------------------ Fix Version/s: (was: 1.0.0.Beta2) > Allow artifact expansion to be enabled/disabled during each upload > ------------------------------------------------------------------ > > Key: ARTIF-709 > URL: https://issues.jboss.org/browse/ARTIF-709 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Expansion is useful in some cases (especially API jars, etc.). However, in others, it's actually pretty harmful. Ex: pushing in a project's ZIP distro, a large WAR with all its dependency JARs, etc. Currently, Artificer would get overwhelmed with the amount of info to pull out. > Suggestion: > 1.) Expansion disabled by default > 2.) Enable with checkbox on web UI, argument on CLI, argument on Java client, etc. > 3.) If *not* expanded, the relationship builders should still kick in. So, the contents would still be parsed. If it contains, for example, a WSDL that imports an XSD or a Java class that impls an API interface, the relationships should still be created. But those relationships would point to the archive itself, rather than an expanded/derived artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:31:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 14:31:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-709) Allow artifact expansion to be dynamically configurable during runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-709: ------------------------------ Summary: Allow artifact expansion to be dynamically configurable during runtime (was: Allow artifact expansion to be enabled/disabled during each upload) > Allow artifact expansion to be dynamically configurable during runtime > ---------------------------------------------------------------------- > > Key: ARTIF-709 > URL: https://issues.jboss.org/browse/ARTIF-709 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Expansion is useful in some cases (especially API jars, etc.). However, in others, it's actually pretty harmful. Ex: pushing in a project's ZIP distro, a large WAR with all its dependency JARs, etc. Currently, Artificer would get overwhelmed with the amount of info to pull out. > Suggestion: > 1.) Expansion disabled by default > 2.) Enable with checkbox on web UI, argument on CLI, argument on Java client, etc. > 3.) If *not* expanded, the relationship builders should still kick in. So, the contents would still be parsed. If it contains, for example, a WSDL that imports an XSD or a Java class that impls an API interface, the relationships should still be created. But those relationships would point to the archive itself, rather than an expanded/derived artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:34:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 14:34:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-709) Allow artifact expansion to be dynamically configurable during runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-709: ------------------------------ Description: Expansion is useful and necessary, especially for relationship definitions. However, in some contexts, it can expand too much. Ex: uploading a large WAR, how do we differentiate between 3rd party dependency JARs (probably shouldn't be expanded) and application-provided JARs (should be expanded)? The answer could be some sort of UI interactivity that allows users to configure the expansion (nested lists with checkboxes?) prior to persisting... was: Expansion is useful in some cases (especially API jars, etc.). However, in others, it's actually pretty harmful. Ex: pushing in a project's ZIP distro, a large WAR with all its dependency JARs, etc. Currently, Artificer would get overwhelmed with the amount of info to pull out. Suggestion: 1.) Expansion disabled by default 2.) Enable with checkbox on web UI, argument on CLI, argument on Java client, etc. 3.) If *not* expanded, the relationship builders should still kick in. So, the contents would still be parsed. If it contains, for example, a WSDL that imports an XSD or a Java class that impls an API interface, the relationships should still be created. But those relationships would point to the archive itself, rather than an expanded/derived artifact. > Allow artifact expansion to be dynamically configurable during runtime > ---------------------------------------------------------------------- > > Key: ARTIF-709 > URL: https://issues.jboss.org/browse/ARTIF-709 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Expansion is useful and necessary, especially for relationship definitions. However, in some contexts, it can expand too much. Ex: uploading a large WAR, how do we differentiate between 3rd party dependency JARs (probably shouldn't be expanded) and application-provided JARs (should be expanded)? > The answer could be some sort of UI interactivity that allows users to configure the expansion (nested lists with checkboxes?) prior to persisting... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 15:35:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 15:35:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-726) If an archive is deleted, also delete its expanded artifacts In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-726: --------------------------------- Summary: If an archive is deleted, also delete its expanded artifacts Key: ARTIF-726 URL: https://issues.jboss.org/browse/ARTIF-726 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 17:18:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Jun 2015 17:18:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-725) Use new 'expandedFromArchivePath' field, rather than custom property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-725: ------------------------------ Description: Currently, if an artifact is expanded, it populates a 'expanded.from.archive.path' custom property. Instead, move this to a new field on the Artifact itself. Note that, for now, this will need to be bound to an expansion entry. Add to the web UI's artifact details. was:Currently, if an artifact is expanded, it populates a 'expanded.from.archive.path' custom property. Instead, move this to a new field on the Artifact itself. Note that, for now, this will need to be bound to an expansion entry. > Use new 'expandedFromArchivePath' field, rather than custom property > -------------------------------------------------------------------- > > Key: ARTIF-725 > URL: https://issues.jboss.org/browse/ARTIF-725 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Currently, if an artifact is expanded, it populates a 'expanded.from.archive.path' custom property. Instead, move this to a new field on the Artifact itself. Note that, for now, this will need to be bound to an expansion entry. > Add to the web UI's artifact details. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 12:21:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 12:21:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-725) Use new 'expandedFromArchivePath' field, rather than custom property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-725 started by Brett Meyer. ----------------------------------------- > Use new 'expandedFromArchivePath' field, rather than custom property > -------------------------------------------------------------------- > > Key: ARTIF-725 > URL: https://issues.jboss.org/browse/ARTIF-725 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Currently, if an artifact is expanded, it populates a 'expanded.from.archive.path' custom property. Instead, move this to a new field on the Artifact itself. Note that, for now, this will need to be bound to an expansion entry. > Add to the web UI's artifact details. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 12:21:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 12:21:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-726) If an archive is deleted, also delete its expanded artifacts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-726 started by Brett Meyer. ----------------------------------------- > If an archive is deleted, also delete its expanded artifacts > ------------------------------------------------------------ > > Key: ARTIF-726 > URL: https://issues.jboss.org/browse/ARTIF-726 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 12:21:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 12:21:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-499) Include another filter for Expanded (similar to Derived) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-499 started by Brett Meyer. ----------------------------------------- > Include another filter for Expanded (similar to Derived) > -------------------------------------------------------- > > Key: ARTIF-499 > URL: https://issues.jboss.org/browse/ARTIF-499 > Project: Artificer > Issue Type: Enhancement > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Reported by David via his 0.5.0.Beta1 testing: > "S-ramp Artifacts --> include another column called Expanded. > Then with this we can filter the original items (for example jars, war) from the files that are expanded from those Original Artifacts uploaded. > I continue thinking that when there are many artifadts uploaded it is difficult to filter and have an easy understanding of the artifact result list. For example you see a file kmodule.xml, and you do not know to what artifact it belongs. You need to enter in the artifact to have this information. And when the number of artifacts in s-ramp is so big, then you see many many files, that you have no idea about them. > If we include this expanded column and also filter field then we could have a view of the original artifacts (with no artifact parent property). > I will prepare a html mock with my idea..." -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 13:40:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 13:40:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-725) Use new 'expandedFromArchivePath' field, rather than custom property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-725. ------------------------------- Resolution: Done > Use new 'expandedFromArchivePath' field, rather than custom property > -------------------------------------------------------------------- > > Key: ARTIF-725 > URL: https://issues.jboss.org/browse/ARTIF-725 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Currently, if an artifact is expanded, it populates a 'expanded.from.archive.path' custom property. Instead, move this to a new field on the Artifact itself. Note that, for now, this will need to be bound to an expansion entry. > Add to the web UI's artifact details. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 13:40:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 13:40:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-726) If an archive is deleted, also delete its expanded artifacts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-726. ------------------------------- Resolution: Done > If an archive is deleted, also delete its expanded artifacts > ------------------------------------------------------------ > > Key: ARTIF-726 > URL: https://issues.jboss.org/browse/ARTIF-726 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 13:59:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 13:59:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-645) Allow users to supply extensions through a new plugin architecture In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-645: ------------------------------ Description: The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: - extension contract impls (ArtifactBuilder, TypeDetector, etc.) - JPA entities - UI elements (custom metadata displays, custom actions, etc.) - endpoint bindings (again, /s-ramp/model/type) Eric's demo: https://bluejeans.com/s/82tW/ The architecture should allow plugins to be deployed as JARs within Wildfly. In addition, our built-in plugins should also be delivered that way, allowing users to opt-in (rather than always take the performance hit of needlessly using the Switchyard/Teiid/RTGov plugins). was: The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: - extension contract impls (ArtifactBuilder, TypeDetector, etc.) - JPA entities - UI elements (custom metadata displays, custom actions, etc.) - endpoint bindings (again, /s-ramp/model/type) Eric's demo: https://bluejeans.com/s/82tW/ > Allow users to supply extensions through a new plugin architecture > ------------------------------------------------------------------ > > Key: ARTIF-645 > URL: https://issues.jboss.org/browse/ARTIF-645 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > The illustrious [~eric.wittmann] demoed his plugin architecture within APIMan, which allows users to contribute, among other things, UI components (!!!). A similar structure could be extremely valuable for Artificer. Things a plugin could contribute: > - extension contract impls (ArtifactBuilder, TypeDetector, etc.) > - JPA entities > - UI elements (custom metadata displays, custom actions, etc.) > - endpoint bindings (again, /s-ramp/model/type) > Eric's demo: https://bluejeans.com/s/82tW/ > The architecture should allow plugins to be deployed as JARs within Wildfly. In addition, our built-in plugins should also be delivered that way, allowing users to opt-in (rather than always take the performance hit of needlessly using the Switchyard/Teiid/RTGov plugins). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 14:37:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 14:37:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-724) Creation timestamp NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-724: ------------------------------ Description: To reproduce: 1.) Upload the Artificer distro zip 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl 3.) click Relationships tab 4.) stack: ... Caused by: java.lang.NullPointerException at java.util.Calendar.setTime(Calendar.java:1770) at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) ... 45 more was: To reproduce: 1.) Upload the Artificer distro zip 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl 3.) stack: ... Caused by: java.lang.NullPointerException at java.util.Calendar.setTime(Calendar.java:1770) at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) ... 45 more > Creation timestamp NPE > ---------------------- > > Key: ARTIF-724 > URL: https://issues.jboss.org/browse/ARTIF-724 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > To reproduce: > 1.) Upload the Artificer distro zip > 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl > 3.) click Relationships tab > 4.) stack: > ... > Caused by: java.lang.NullPointerException > at java.util.Calendar.setTime(Calendar.java:1770) > at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) > at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) > at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) > ... 45 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 14:37:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 14:37:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-724) Creation timestamp NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-724: ------------------------------ Summary: Creation timestamp NPE (was: Creation timestamp not always persisted) > Creation timestamp NPE > ---------------------- > > Key: ARTIF-724 > URL: https://issues.jboss.org/browse/ARTIF-724 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > To reproduce: > 1.) Upload the Artificer distro zip > 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl > 3.) stack: > ... > Caused by: java.lang.NullPointerException > at java.util.Calendar.setTime(Calendar.java:1770) > at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) > at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) > at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) > ... 45 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 16:10:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 16:10:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-724) Creation timestamp NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-724 started by Brett Meyer. ----------------------------------------- > Creation timestamp NPE > ---------------------- > > Key: ARTIF-724 > URL: https://issues.jboss.org/browse/ARTIF-724 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > To reproduce: > 1.) Upload the Artificer distro zip > 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl > 3.) click Relationships tab > 4.) stack: > ... > Caused by: java.lang.NullPointerException > at java.util.Calendar.setTime(Calendar.java:1770) > at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) > at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) > at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) > ... 45 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 16:10:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 16:10:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-724) Creation timestamp NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-724 stopped by Brett Meyer. ----------------------------------------- > Creation timestamp NPE > ---------------------- > > Key: ARTIF-724 > URL: https://issues.jboss.org/browse/ARTIF-724 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > To reproduce: > 1.) Upload the Artificer distro zip > 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl > 3.) click Relationships tab > 4.) stack: > ... > Caused by: java.lang.NullPointerException > at java.util.Calendar.setTime(Calendar.java:1770) > at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) > at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) > at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) > ... 45 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 16:10:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 16:10:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-724) Creation timestamp NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTIF-724 started by Brett Meyer. ----------------------------------------- > Creation timestamp NPE > ---------------------- > > Key: ARTIF-724 > URL: https://issues.jboss.org/browse/ARTIF-724 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > To reproduce: > 1.) Upload the Artificer distro zip > 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl > 3.) click Relationships tab > 4.) stack: > ... > Caused by: java.lang.NullPointerException > at java.util.Calendar.setTime(Calendar.java:1770) > at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) > at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) > at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) > ... 45 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 16:11:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 16:11:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-724) Creation timestamp NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-724. ------------------------------- Resolution: Done > Creation timestamp NPE > ---------------------- > > Key: ARTIF-724 > URL: https://issues.jboss.org/browse/ARTIF-724 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > To reproduce: > 1.) Upload the Artificer distro zip > 2.) click on wstx-wsba-1.1-wsdl-200702.wsdl > 3.) click Relationships tab > 4.) stack: > ... > Caused by: java.lang.NullPointerException > at java.util.Calendar.setTime(Calendar.java:1770) > at org.artificer.client.query.QueryResultSet.summary(QueryResultSet.java:176) > at org.artificer.client.query.QueryResultSet.access$000(QueryResultSet.java:34) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:153) > at org.artificer.client.query.QueryResultSet$DelegatingIterator.next(QueryResultSet.java:128) > at org.artificer.ui.server.services.util.RelationshipResolver.resolveAll(RelationshipResolver.java:86) > ... 45 more -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 16:23:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 16:23:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-723) Web UI upload status never completes for large files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-723: ------------------------------ Fix Version/s: (was: 1.0.0.Beta2) > Web UI upload status never completes for large files > ----------------------------------------------------- > > Key: ARTIF-723 > URL: https://issues.jboss.org/browse/ARTIF-723 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > Upload a large distro (example, the actual Artificer distro ZIP). It's expanded and processed correctly, but the upload status never completes. Timeout? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 16:23:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Jun 2015 16:23:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-723) Web UI upload status never completes for large files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-723. ----------------------------- Resolution: Cannot Reproduce Bug > Web UI upload status never completes for large files > ----------------------------------------------------- > > Key: ARTIF-723 > URL: https://issues.jboss.org/browse/ARTIF-723 > Project: Artificer > Issue Type: Bug > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > Upload a large distro (example, the actual Artificer distro ZIP). It's expanded and processed correctly, but the upload status never completes. Timeout? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:43:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:43:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-702) CLI: first use of getMetaData is slow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-702: ------------------------------ Fix Version/s: 1.0.0.Beta2 > CLI: first use of getMetaData is slow > ------------------------------------- > > Key: ARTIF-702 > URL: https://issues.jboss.org/browse/ARTIF-702 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > (12:12:47 PM) ewittman: getMetaData is super slow the first time you use it (this is an old bug) > (12:12:58 PM) ewittman: I think it takes a long time to build the jaxb context iirc -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:44:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:44:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-552) Support relationships with no target In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-552. ----------------------------- Resolution: Won't Fix > Support relationships with no target > ------------------------------------ > > Key: ARTIF-552 > URL: https://issues.jboss.org/browse/ARTIF-552 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > 2.1.2 > "It is possible for a relationship of a given Relationship Type not to have a target, which is termed a "relationship with no targets". In this case there is only one relationship instance with that Relationship Type for a given Source. Such relationships have a target cardinality of "0". If there is a relationship instance with a given Relationship Type that does have a target, then there CANNOT also be a relationship instance with that Relationship Type which has no target." -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:46:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:46:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-659) Test and support Java 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-659. ----------------------------- Resolution: Duplicate Issue > Test and support Java 8 > ----------------------- > > Key: ARTIF-659 > URL: https://issues.jboss.org/browse/ARTIF-659 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:47:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:47:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-599) Batch upload through linked artifacts in a multipart POST/PUT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-599. ----------------------------- Resolution: Won't Fix > Batch upload through linked artifacts in a multipart POST/PUT > ------------------------------------------------------------- > > Key: ARTIF-599 > URL: https://issues.jboss.org/browse/ARTIF-599 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > {quote} > 2.3.5.2.1 Using Batch POST > RFC 2387, "The MIME Multipart/Related Content-type" describes how to perform a multipart POST of binary documents. S-RAMP builds on this RFC to extend the IETF draft document "ATOM Multi-part Media Resource Creation" to support the simultaneous publishing of a collection of non-dependent and dependent resources and their associated metadata. With this approach it is possible, for example, to publish an XSD document which imports two other XSD documents by including it as well as its dependencies in a single POST to the repository. > The Batch POST method requires an atom entry document as the root body part. This root atom entry document points to any dependent atom entry documents contained in other body parts using atom:link elements with an href attribute whose value is the Content-ID of the relevant body part. It also points at the actual document content by specifying the Content-ID of the relevant body part as the value of the src attribute in the atom:content element of the atom entry document. This approach provides complete linkage between a document and its dependencies and all corresponding binary resources. > {quote} > Although we implement the archive-based method of batch uploading, we do not currently support plain multipart for multiple artifacts. > Support for both POST and updating through PUT is necessary. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:49:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:49:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-613) RTGov ArtifactBuilders In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-613. ----------------------------- Resolution: Won't Fix > RTGov ArtifactBuilders > ---------------------- > > Key: ARTIF-613 > URL: https://issues.jboss.org/browse/ARTIF-613 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Gary Brown > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:50:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:50:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-152) Create Event Processor Network derived artifact handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-152. ----------------------------- Resolution: Won't Fix > Create Event Processor Network derived artifact handler > ------------------------------------------------------- > > Key: ARTIF-152 > URL: https://issues.jboss.org/browse/ARTIF-152 > Project: Artificer > Issue Type: Sub-task > Components: Core > Reporter: Gary Brown > Assignee: Gary Brown > > Derive EPN as a Policy Document, from the war deployable artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:50:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:50:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-153) Create Active Collection Source derived artifact handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-153. ----------------------------- Resolution: Won't Fix > Create Active Collection Source derived artifact handler > -------------------------------------------------------- > > Key: ARTIF-153 > URL: https://issues.jboss.org/browse/ARTIF-153 > Project: Artificer > Issue Type: Sub-task > Components: Core > Reporter: Gary Brown > Assignee: Gary Brown > > Derive Active collection source configuration from the deployable war artifact. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:50:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:50:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-154) Create Information Processor derived artifact handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-154. ----------------------------- Resolution: Won't Fix > Create Information Processor derived artifact handler > ----------------------------------------------------- > > Key: ARTIF-154 > URL: https://issues.jboss.org/browse/ARTIF-154 > Project: Artificer > Issue Type: Sub-task > Components: Core > Reporter: Gary Brown > Assignee: Gary Brown > > Derive information processor configuration from the deployable war artifact. > When information types and context/property expressions stored in the repo, need to enhance this deriver to establish the appropriate relationships. But initial version should just represent the configuration as a specific type. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:50:04 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:50:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-308) Artifact Details: Make Relationship sections collapsible In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-308. ----------------------------- Resolution: Out of Date > Artifact Details: Make Relationship sections collapsible > --------------------------------------------------------- > > Key: ARTIF-308 > URL: https://issues.jboss.org/browse/ARTIF-308 > Project: Artificer > Issue Type: Feature Request > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > > The relationships tab on the artifact details page organizes the relationships into sections. Make the sections collapsible. Some JS to help with this: > http://jsfiddle.net/T8t2r/3/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 00:51:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 00:51:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-498) Provide a mechanism to consume "seed data" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-498. ----------------------------- Resolution: Won't Fix > Provide a mechanism to consume "seed data" > ------------------------------------------ > > Key: ARTIF-498 > URL: https://issues.jboss.org/browse/ARTIF-498 > Project: Artificer > Issue Type: Enhancement > Reporter: Eric Wittmann > Assignee: Brett Meyer > > This is a feature request from David based on his testing of 1.3.0.Beta1 of dtgov: > "Would be very nice for the user, that the first time dtgov is executed, the cli-commands file is loaded and all the dtgov artifacts are installed in s-ramp." > I think the idea is that currently the user must do this manually after installing and launching s-ramp/dtgov. Instead, it would be interesting to have a way to consume this data on startup. I'm adding this as a suggested enhancment to s-ramp. If we decide this feature is not appropriate for s-ramp, then we should move it to a DTGov feature request and consider it in that context. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 12:37:09 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 12:37:09 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-727) Add non-blocking upload endpoints In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-727: --------------------------------- Summary: Add non-blocking upload endpoints Key: ARTIF-727 URL: https://issues.jboss.org/browse/ARTIF-727 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Uploading large archives can take a while, due to expansion, processing, and derivation. For instance, uploading the entire Artificer distro ZIP takes around 4 minutes. While that's reasonable (at least in my opinion), all of our upload endpoints are currently blocking. Blocking may be desirable for some client apps, so definitely don't remove that. But, adding additional, non-blocking methods to the web service, java client, cli, web browser, and ejb would be helpful. The non-blocking method should at least block until the primary artifact is persisted, returning its metadata. But the rest should be async. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 13:11:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 13:11:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-728) Add upload endpoint that takes a local file path In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-728: --------------------------------- Summary: Add upload endpoint that takes a local file path Key: ARTIF-728 URL: https://issues.jboss.org/browse/ARTIF-728 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer On the server and all clients, add a new upload endpoint that takes a local file path, instead of an InputStream/byte[]. If the file is available on/to the server's machine, there should be no reason why we can't simply use it, rather than pass it through the web service. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 16:59:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 16:59:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to BMT JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-690: ------------------------------ Summary: Switch to BMT JTA (was: Switch to CMT JTA) > Switch to BMT JTA > ----------------- > > Key: ARTIF-690 > URL: https://issues.jboss.org/browse/ARTIF-690 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > Rather than simply using JDBC transactions at the persistence level, switch to using CMT JTA at the REST/EJB level. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 17:00:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 17:00:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to BMT JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-690: ------------------------------ Description: Rather than simply using JDBC transactions, switch to using BMT JTA (was: Rather than simply using JDBC transactions at the persistence level, switch to using CMT JTA at the REST/EJB level.) > Switch to BMT JTA > ----------------- > > Key: ARTIF-690 > URL: https://issues.jboss.org/browse/ARTIF-690 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > Rather than simply using JDBC transactions, switch to using BMT JTA -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 17:00:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 17:00:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to BMT JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-690: ------------------------------ Comment: was deleted (was: WIP: https://github.com/brmeyer/s-ramp/tree/ARTIF-690 (simply the JPA config)) > Switch to BMT JTA > ----------------- > > Key: ARTIF-690 > URL: https://issues.jboss.org/browse/ARTIF-690 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > Rather than simply using JDBC transactions, switch to using BMT JTA -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 17:00:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 17:00:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to BMT JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-690: ------------------------------ Comment: was deleted (was: Note that the EJB services currently include a BMT annotation!) > Switch to BMT JTA > ----------------- > > Key: ARTIF-690 > URL: https://issues.jboss.org/browse/ARTIF-690 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.1.0.Final > > > Rather than simply using JDBC transactions, switch to using BMT JTA -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 17:03:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 17:03:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-729) Enable query caching and hibernate-infinispan 2LC by default In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-729: --------------------------------- Summary: Enable query caching and hibernate-infinispan 2LC by default Key: ARTIF-729 URL: https://issues.jboss.org/browse/ARTIF-729 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 Profiling has shown that repeated queries are a huge CPU hot spot. Example: when uploading the Artificer distro ZIP itself, the HibernateRelationshipFactory makes repeated queries (by UUID) to set up relationship targets. Since many of them are repeats (ex: find the parent distro artifact), the query cache and 2LC would be immensely helpful. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 17:29:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 17:29:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-690) Switch to BMT JTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-690. ------------------------------- Fix Version/s: 1.0.0.Beta2 (was: 1.1.0.Final) Resolution: Done > Switch to BMT JTA > ----------------- > > Key: ARTIF-690 > URL: https://issues.jboss.org/browse/ARTIF-690 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Rather than simply using JDBC transactions, switch to using BMT JTA -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 17:29:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Jun 2015 17:29:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-729) Enable query caching and hibernate-infinispan 2LC by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-729. ------------------------------- Resolution: Done > Enable query caching and hibernate-infinispan 2LC by default > ------------------------------------------------------------ > > Key: ARTIF-729 > URL: https://issues.jboss.org/browse/ARTIF-729 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Profiling has shown that repeated queries are a huge CPU hot spot. Example: when uploading the Artificer distro ZIP itself, the HibernateRelationshipFactory makes repeated queries (by UUID) to set up relationship targets. Since many of them are repeats (ex: find the parent distro artifact), the query cache and 2LC would be immensely helpful. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 11:39:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 25 Jun 2015 11:39:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-702) CLI: first use of getMetaData is slow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated ARTIF-702: ------------------------------ Fix Version/s: (was: 1.0.0.Beta2) > CLI: first use of getMetaData is slow > ------------------------------------- > > Key: ARTIF-702 > URL: https://issues.jboss.org/browse/ARTIF-702 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > (12:12:47 PM) ewittman: getMetaData is super slow the first time you use it (this is an old bug) > (12:12:58 PM) ewittman: I think it takes a long time to build the jaxb context iirc -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 11:39:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 25 Jun 2015 11:39:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-702) CLI: first use of getMetaData is slow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed ARTIF-702. ----------------------------- Resolution: Cannot Reproduce Bug > CLI: first use of getMetaData is slow > ------------------------------------- > > Key: ARTIF-702 > URL: https://issues.jboss.org/browse/ARTIF-702 > Project: Artificer > Issue Type: Enhancement > Affects Versions: 1.0.0.Beta1 > Reporter: Brett Meyer > Assignee: Brett Meyer > > (12:12:47 PM) ewittman: getMetaData is super slow the first time you use it (this is an old bug) > (12:12:58 PM) ewittman: I think it takes a long time to build the jaxb context iirc -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 11:44:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 25 Jun 2015 11:44:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-499) Include another filter for Expanded (similar to Derived) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083934#comment-13083934 ] Brett Meyer commented on ARTIF-499: ----------------------------------- Use a drop down with 4 options: - All - Primary (Origin) - Primary (Expanded From Archive) - Derived > Include another filter for Expanded (similar to Derived) > -------------------------------------------------------- > > Key: ARTIF-499 > URL: https://issues.jboss.org/browse/ARTIF-499 > Project: Artificer > Issue Type: Enhancement > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Reported by David via his 0.5.0.Beta1 testing: > "S-ramp Artifacts --> include another column called Expanded. > Then with this we can filter the original items (for example jars, war) from the files that are expanded from those Original Artifacts uploaded. > I continue thinking that when there are many artifadts uploaded it is difficult to filter and have an easy understanding of the artifact result list. For example you see a file kmodule.xml, and you do not know to what artifact it belongs. You need to enter in the artifact to have this information. And when the number of artifacts in s-ramp is so big, then you see many many files, that you have no idea about them. > If we include this expanded column and also filter field then we could have a view of the original artifacts (with no artifact parent property). > I will prepare a html mock with my idea..." -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 15:19:03 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 25 Jun 2015 15:19:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-499) Include another filter for Expanded (similar to Derived) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-499. ------------------------------- Resolution: Done > Include another filter for Expanded (similar to Derived) > -------------------------------------------------------- > > Key: ARTIF-499 > URL: https://issues.jboss.org/browse/ARTIF-499 > Project: Artificer > Issue Type: Enhancement > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > > Reported by David via his 0.5.0.Beta1 testing: > "S-ramp Artifacts --> include another column called Expanded. > Then with this we can filter the original items (for example jars, war) from the files that are expanded from those Original Artifacts uploaded. > I continue thinking that when there are many artifadts uploaded it is difficult to filter and have an easy understanding of the artifact result list. For example you see a file kmodule.xml, and you do not know to what artifact it belongs. You need to enter in the artifact to have this information. And when the number of artifacts in s-ramp is so big, then you see many many files, that you have no idea about them. > If we include this expanded column and also filter field then we could have a view of the original artifacts (with no artifact parent property). > I will prepare a html mock with my idea..." -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 14:09:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 29 Jun 2015 14:09:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-730) Support Wildfly 9 In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-730: --------------------------------- Summary: Support Wildfly 9 Key: ARTIF-730 URL: https://issues.jboss.org/browse/ARTIF-730 Project: Artificer Issue Type: Task Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta3 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 30 13:49:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Jun 2015 13:49:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-731) Add 'trashed' to most artifact DB indexes In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-731: --------------------------------- Summary: Add 'trashed' to most artifact DB indexes Key: ARTIF-731 URL: https://issues.jboss.org/browse/ARTIF-731 Project: Artificer Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta3 The indexes should include the 'trashed', since 'trashed=false' is used on all queries -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 30 13:50:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Jun 2015 13:50:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-731) Add 'trashed' to most artifact DB indexes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-731. ------------------------------- Resolution: Done > Add 'trashed' to most artifact DB indexes > ----------------------------------------- > > Key: ARTIF-731 > URL: https://issues.jboss.org/browse/ARTIF-731 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta3 > > > The indexes should include the 'trashed', since 'trashed=false' is used on all queries -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 30 14:02:01 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Jun 2015 14:02:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-732) Allow nested artifact expansion In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-732: --------------------------------- Summary: Allow nested artifact expansion Key: ARTIF-732 URL: https://issues.jboss.org/browse/ARTIF-732 Project: Artificer Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta3 Ex: Upload a dist ZIP which contains two WARs. Currently, the root ZIP will be the "expandedFromArchive" target for all artifacts, even the artifacts expanded from the WARs. Instead, ArtifactServiceImpl#upload should allow nested expansion, where each level of "expandedFromArchive" relationship creates an expansion chain. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 30 15:07:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Jun 2015 15:07:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-733) Improve expansion/derivation relationship lookups In-Reply-To: References: Message-ID: Brett Meyer created ARTIF-733: --------------------------------- Summary: Improve expansion/derivation relationship lookups Key: ARTIF-733 URL: https://issues.jboss.org/browse/ARTIF-733 Project: Artificer Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta3 When an expanded or derived artifact is persisted, it typically results in a slew of query-by-UUID hits on the DB, often ones that are repetitious. Instead, hold a map of UUIDs and artifacts in memory for that unit of work, reducing the lookups. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 30 15:08:02 2015 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Jun 2015 15:08:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (ARTIF-733) Improve expansion/derivation relationship lookups In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARTIF-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved ARTIF-733. ------------------------------- Resolution: Done > Improve expansion/derivation relationship lookups > ------------------------------------------------- > > Key: ARTIF-733 > URL: https://issues.jboss.org/browse/ARTIF-733 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta3 > > > When an expanded or derived artifact is persisted, it typically results in a slew of query-by-UUID hits on the DB, often ones that are repetitious. Instead, hold a map of UUIDs and artifacts in memory for that unit of work, reducing the lookups. -- This message was sent by Atlassian JIRA (v6.3.15#6346)