[JBoss JIRA] (JBOSGI-614) Allow Maven URLs to be configured to resolve external bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-614?page=com.atlassian.jira.plugin... ]
Thomas Diesler resolved JBOSGI-614.
-----------------------------------
Resolution: Done
Fixed in jbosgi-repository-3.0.0.CR3
You can now set a property 'org.jboss.osgi.repository.maven.base.urls' with a list of base URL's
> Allow Maven URLs to be configured to resolve external bundles
> -------------------------------------------------------------
>
> Key: JBOSGI-614
> URL: https://issues.jboss.org/browse/JBOSGI-614
> Project: JBoss OSGi
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Repository
> Affects Versions: Continuing
> Environment: All
> Reporter: Ulrich Romahn
> Assignee: Thomas Diesler
> Fix For: JBossOSGi 2.0.0
>
>
> Currently, JBoss OSGi allows to provide a Maven URI for a package which will then be resolved by the deployer according to the following rules:
> 1. check if the artifact is present in a local Maven repo (.m2)
> 2. if not, download the artifact from a remote Maven repo
> Currently, the class MavenArtifactRepository has two Maven repository URLs hardcoded:
> JBOSS_NEXUS_BASE = "http://repository.jboss.org/nexus/content/groups/public";
> MAVEN_CENTRAL_BASE = "http://repo1.maven.org/maven2";
> It should be possible to configure those URLs using some configuration mechanism. This is especially important in a real production environment where access to external URLs may be blocked by a firewall and an internal Nexus repo should be used to proxy a "stable set" of artifacts to be used for production.
> The following configuration options should be possible:
> 1. as it is right now
> 2. switch off external resolution completely. Only artifacts currently present on the local filesystem (.m2) should be resolved and loaded
> 3. Configure Maven URLs in addition to the hardcoded ones above
> 4. Configure Maven URLs as complete replacements to the hardcoded ones above
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (JBOSGI-647) StorageState seem to get left over druing debug/test cycles and hot deployment
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-647?page=com.atlassian.jira.plugin... ]
Thomas Diesler edited comment on JBOSGI-647 at 5/3/13 1:57 AM:
---------------------------------------------------------------
Duplicates JBOSGI-613
Should be fixed in wildly-8.0.0.Alpha1
was (Author: thomas.diesler):
Duplicates JBOSGI-613
> StorageState seem to get left over druing debug/test cycles and hot deployment
> ------------------------------------------------------------------------------
>
> Key: JBOSGI-647
> URL: https://issues.jboss.org/browse/JBOSGI-647
> Project: JBoss OSGi
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Core Framework
> Environment: EAP 6.1-beta
> Reporter: Darryl Miles
> Assignee: Thomas Diesler
> Priority: Minor
>
> When developing for JBoss EAP 6.1-beta under Eclipse IDE after a number of deploys the number of StorageState seem to get left over for the same bundle names, but with unique instance/deployment id's.
> Also I don't believe the the OSGi bundles made any use of the storage API directly so I am thinking that the setup/provisioning of such data areas could be delayed until first use and also be cleaned up entirely if no write access was made into the area.
> This is an example of what is occurring after a number of published and JBoss AS restarts, some of which will be when the OSGi aware bundle maybe deployed.
> 17:42:33,740 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=26,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,743 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=28,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,745 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=34,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,747 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=36,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,748 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=38,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,751 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=40,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBOSGI-647) StorageState seem to get left over druing debug/test cycles and hot deployment
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-647?page=com.atlassian.jira.plugin... ]
Thomas Diesler edited comment on JBOSGI-647 at 5/3/13 1:57 AM:
---------------------------------------------------------------
Duplicates JBOSGI-613
Should be fixed in wildfly-8.0.0.Alpha1
was (Author: thomas.diesler):
Duplicates JBOSGI-613
Should be fixed in wildly-8.0.0.Alpha1
> StorageState seem to get left over druing debug/test cycles and hot deployment
> ------------------------------------------------------------------------------
>
> Key: JBOSGI-647
> URL: https://issues.jboss.org/browse/JBOSGI-647
> Project: JBoss OSGi
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Core Framework
> Environment: EAP 6.1-beta
> Reporter: Darryl Miles
> Assignee: Thomas Diesler
> Priority: Minor
>
> When developing for JBoss EAP 6.1-beta under Eclipse IDE after a number of deploys the number of StorageState seem to get left over for the same bundle names, but with unique instance/deployment id's.
> Also I don't believe the the OSGi bundles made any use of the storage API directly so I am thinking that the setup/provisioning of such data areas could be delayed until first use and also be cleaned up entirely if no write access was made into the area.
> This is an example of what is occurring after a number of published and JBoss AS restarts, some of which will be when the OSGi aware bundle maybe deployed.
> 17:42:33,740 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=26,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,743 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=28,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,745 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=34,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,747 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=36,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,748 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=38,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,751 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=40,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBOSGI-647) StorageState seem to get left over druing debug/test cycles and hot deployment
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-647?page=com.atlassian.jira.plugin... ]
Thomas Diesler resolved JBOSGI-647.
-----------------------------------
Resolution: Duplicate Issue
Duplicates JBOSGI-613
> StorageState seem to get left over druing debug/test cycles and hot deployment
> ------------------------------------------------------------------------------
>
> Key: JBOSGI-647
> URL: https://issues.jboss.org/browse/JBOSGI-647
> Project: JBoss OSGi
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Core Framework
> Environment: EAP 6.1-beta
> Reporter: Darryl Miles
> Assignee: Thomas Diesler
> Priority: Minor
>
> When developing for JBoss EAP 6.1-beta under Eclipse IDE after a number of deploys the number of StorageState seem to get left over for the same bundle names, but with unique instance/deployment id's.
> Also I don't believe the the OSGi bundles made any use of the storage API directly so I am thinking that the setup/provisioning of such data areas could be delayed until first use and also be cleaned up entirely if no write access was made into the area.
> This is an example of what is occurring after a number of published and JBoss AS restarts, some of which will be when the OSGi aware bundle maybe deployed.
> 17:42:33,740 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=26,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,743 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=28,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,745 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=34,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,747 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=36,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,748 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=38,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
> 17:42:33,751 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=40,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBOSGI-647) StorageState seem to get left over druing debug/test cycles and hot deployment
by Darryl Miles (JIRA)
Darryl Miles created JBOSGI-647:
-----------------------------------
Summary: StorageState seem to get left over druing debug/test cycles and hot deployment
Key: JBOSGI-647
URL: https://issues.jboss.org/browse/JBOSGI-647
Project: JBoss OSGi
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Core Framework
Environment: EAP 6.1-beta
Reporter: Darryl Miles
Assignee: Thomas Diesler
Priority: Minor
When developing for JBoss EAP 6.1-beta under Eclipse IDE after a number of deploys the number of StorageState seem to get left over for the same bundle names, but with unique instance/deployment id's.
Also I don't believe the the OSGi bundles made any use of the storage API directly so I am thinking that the setup/provisioning of such data areas could be delayed until first use and also be cleaned up entirely if no write access was made into the area.
This is an example of what is occurring after a number of published and JBoss AS restarts, some of which will be when the OSGi aware bundle maybe deployed.
17:42:33,740 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=26,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
17:42:33,743 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=28,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
17:42:33,745 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=34,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
17:42:33,747 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=36,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
17:42:33,748 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=38,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
17:42:33,751 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-1) Created storage state: StorageState[id=40,rev=0,startlevel=1,started=true,location=com-domain-jpa-0.0.1-SNAPSHOT.jar]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBOSGI-641) Verify that Felix Web Console works with R5
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-641?page=com.atlassian.jira.plugin... ]
Thomas Diesler edited comment on JBOSGI-641 at 5/2/13 10:34 AM:
----------------------------------------------------------------
Web Console 3.1.8 works fine
{code}
<capability name="org.apache.felix:org.apache.felix.metatype:1.0.6"/>
<capability name="org.apache.felix:org.apache.felix.webconsole:3.1.8" startlevel="1"/>
{code}
was (Author: thomas.diesler):
Web Console 3.1.8 works fine
{code}
<capability name="org.apache.felix:org.apache.felix.webconsole:3.1.8" startlevel="1"/>
{code}
> Verify that Felix Web Console works with R5
> -------------------------------------------
>
> Key: JBOSGI-641
> URL: https://issues.jboss.org/browse/JBOSGI-641
> Project: JBoss OSGi
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Distribution
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: JBossOSGi 2.0.0
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBOSGI-614) Allow Maven URLs to be configured to resolve external bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-614?page=com.atlassian.jira.plugin... ]
Work on JBOSGI-614 started by Thomas Diesler.
> Allow Maven URLs to be configured to resolve external bundles
> -------------------------------------------------------------
>
> Key: JBOSGI-614
> URL: https://issues.jboss.org/browse/JBOSGI-614
> Project: JBoss OSGi
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Repository
> Affects Versions: Continuing
> Environment: All
> Reporter: Ulrich Romahn
> Assignee: Thomas Diesler
> Fix For: JBossOSGi 2.0.0
>
>
> Currently, JBoss OSGi allows to provide a Maven URI for a package which will then be resolved by the deployer according to the following rules:
> 1. check if the artifact is present in a local Maven repo (.m2)
> 2. if not, download the artifact from a remote Maven repo
> Currently, the class MavenArtifactRepository has two Maven repository URLs hardcoded:
> JBOSS_NEXUS_BASE = "http://repository.jboss.org/nexus/content/groups/public";
> MAVEN_CENTRAL_BASE = "http://repo1.maven.org/maven2";
> It should be possible to configure those URLs using some configuration mechanism. This is especially important in a real production environment where access to external URLs may be blocked by a firewall and an internal Nexus repo should be used to proxy a "stable set" of artifacts to be used for production.
> The following configuration options should be possible:
> 1. as it is right now
> 2. switch off external resolution completely. Only artifacts currently present on the local filesystem (.m2) should be resolved and loaded
> 3. Configure Maven URLs in addition to the hardcoded ones above
> 4. Configure Maven URLs as complete replacements to the hardcoded ones above
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBOSGI-601) Log remote maven repository access at info level
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/JBOSGI-601?page=com.atlassian.jira.plugin... ]
Thomas Diesler resolved JBOSGI-601.
-----------------------------------
Resolution: Done
Done
{code}
16:09:00,754 INFO [org.jboss.osgi.repository] (MSC service thread 1-2) JBOSGI020400: Find maven providers for: MavenCoordinates[org.apache.felix:org.apache.felix.webconsole:jar:3.1.8]
16:09:02,098 INFO [org.jboss.osgi.repository] (MSC service thread 1-2) JBOSGI020401: Found maven resource: URLResource[org.apache.felix.webconsole:3.1.8]
16:09:05,497 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: org.apache.felix.log:1.0.0
16:09:05,499 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: jboss-osgi-logging:1.0.0
16:09:05,501 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: org.apache.felix.configadmin:1.2.8
16:09:05,503 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: jboss-as-osgi-configadmin:8.0.0.Alpha1-SNAPSHOT
16:09:05,506 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: org.apache.felix.webconsole:3.1.8
16:09:05,658 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011011: Starting bundles for start level: 1
16:09:05,660 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011002: Bundle started: jboss-as-osgi-http:8.0.0.Alpha1-SNAPSHOT
16:09:05,660 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011002: Bundle started: jboss-as-osgi-jpa:8.0.0.Alpha1-SNAPSHOT
16:09:05,670 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011002: Bundle started: org.apache.felix.log:1.0.0
16:09:05,678 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011002: Bundle started: jboss-osgi-logging:1.0.0
16:09:05,693 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011002: Bundle started: org.apache.felix.configadmin:1.2.8
16:09:05,703 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011002: Bundle started: jboss-as-osgi-configadmin:8.0.0.Alpha1-SNAPSHOT
16:09:05,763 INFO [org.jboss.web] (MSC service thread 1-2) JBAS018210: Register web context: /system/console
16:09:05,785 INFO [org.jboss.as.undertow] (MSC service thread 1-2) JBAS018210: Register web context: /system/console
16:09:05,785 INFO [org.jboss.as.osgi] (MSC service thread 1-2) JBAS011913: Register HttpService alias: /system/console
16:09:05,787 INFO [org.jboss.web] (MSC service thread 1-2) JBAS018210: Register web context: /system/console/res
16:09:05,788 INFO [org.jboss.as.undertow] (MSC service thread 1-2) JBAS018210: Register web context: /system/console/res
16:09:05,789 INFO [org.jboss.as.osgi] (MSC service thread 1-2) JBAS011913: Register HttpService alias: /system/console/res
{code}
> Log remote maven repository access at info level
> ------------------------------------------------
>
> Key: JBOSGI-601
> URL: https://issues.jboss.org/browse/JBOSGI-601
> Project: JBoss OSGi
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Repository
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: JBossOSGi 2.0.0
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months