Re: Naming a new support bundle

[Konrad Windszus]

Hi Robert,
as far as I know for retrieving the GAVs there is only the web console plugin 
at 
https://github.com/apache/felix/blob/trunk/webconsole-plugins/packageadmin/src/main/java/org/apache/felix/webconsole/plugins/packageadmin/internal/WebConsolePlugin.java#L280,
 which is looking up the GAV for one specific package.
Just pay attention that:
a) OSGi bundles not created by the maven-bundle-plugin will not carry the 
pom.properties files
b) One bundle may contain several GAVs (by embedding other artifacts)

Also I would think that such a servlet may also be useful to create a 
dependency management section within a pom (for depending on the version of the 
dependency which is actually used in Sling). I would prefer to have that  
servlet at Felix in the form of another web console.
Konrad


> Am 16.02.2016 um 22:33 schrieb Robert Munteanu :
> 
> Hi,
> 
> In the light of SLING-3605 [0] which will bring the Eclipse tooling the
> ability to automagically configure debugging to use the sources of the
> bundles deployed on a Sling instance, I will need to create a new
> tooling/support bundle.
> 
> For now, this bundle will expose a servlet which returns a list of all
> bundles installed in a Sling runtime, together with source lookup
> hints.
> 
> The only source lookup hints that I have at the moment are the Maven
> GAV coordinates. These are located inside the bundle in a file named
> /META-INF/maven/${artifactId}/pom.properties.
> 
> I did not see a way to retrieve this using existing HTTP APIs or the
> web console so I'm going to create my own.
> 
> Two questions:
> 
> a) Is there already a way to retrieve this info that I missed?
> b) What would be a good bundle symbolic name for this bundle?
> 
> For b) I am considering org.apache.sling.tooling.support.introspection
> or org.apache.sling.tooling.support.info , but maybe someone has a
> better suggestion :-)
> 
> Thanks,
> 
> Robert
> 
> 
> [0]: https://issues.apache.org/jira/browse/SLING-3605

Naming a new support bundle

[Robert Munteanu]

Hi,

In the light of SLING-3605 [0] which will bring the Eclipse tooling the
ability to automagically configure debugging to use the sources of the
bundles deployed on a Sling instance, I will need to create a new
tooling/support bundle.

For now, this bundle will expose a servlet which returns a list of all
bundles installed in a Sling runtime, together with source lookup
hints.

The only source lookup hints that I have at the moment are the Maven
GAV coordinates. These are located inside the bundle in a file named
/META-INF/maven/${artifactId}/pom.properties.

I did not see a way to retrieve this using existing HTTP APIs or the
web console so I'm going to create my own.

Two questions:

a) Is there already a way to retrieve this info that I missed?
b) What would be a good bundle symbolic name for this bundle?

For b) I am considering org.apache.sling.tooling.support.introspection
or org.apache.sling.tooling.support.info , but maybe someone has a
better suggestion :-)

Thanks,

Robert


[0]: https://issues.apache.org/jira/browse/SLING-3605

[jira] [Commented] (SLING-3605) Debug based on bundles deployed on the server

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148867#comment-15148867
 ] 

Robert Munteanu commented on SLING-3605:


The current plan is :

# install a custom servlet which inspects the bundles in the Sling instance for 
a file named 'pom.properties' located under '/META-INF/maven' and prints the 
GAV entries as JSON
# Enhance the {{OsgiClient}} to retrieve the list of Maven artifacts deployed 
in a Sling instance
# In the {{JVMDebuggerConnection}} retrieve the list of Maven Artifacts
# For each artifact trigger a download of the -sources jar
# add each downloaded sources jar as an ExternalArchiveSourceContainer

I have this prototyped in a local checkout, but I still need to figure out step 
4.

> Debug based on bundles deployed on the server
> -
>
> Key: SLING-3605
> URL: https://issues.apache.org/jira/browse/SLING-3605
> Project: Sling
>  Issue Type: New Feature
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> During an offline discussion with [~mpetria] the following item came up: when 
> debugging a Sling application with a large number of bundles, it's hard to 
> synchronise sources between the workspace and the server. It would be good to 
> be able to debug the application based on the information that we have about 
> the running bundles ( e.g. if they are Maven artifacts we can retrieve the 
> sources and associated them to the project ).
> Not trivial but worth looking into.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-3605) Debug based on bundles deployed on the server

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu reassigned SLING-3605:
--

Assignee: Robert Munteanu

> Debug based on bundles deployed on the server
> -
>
> Key: SLING-3605
> URL: https://issues.apache.org/jira/browse/SLING-3605
> Project: Sling
>  Issue Type: New Feature
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> During an offline discussion with [~mpetria] the following item came up: when 
> debugging a Sling application with a large number of bundles, it's hard to 
> synchronise sources between the workspace and the server. It would be good to 
> be able to debug the application based on the information that we have about 
> the running bundles ( e.g. if they are Maven artifacts we can retrieve the 
> sources and associated them to the project ).
> Not trivial but worth looking into.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5485) Remove Launchpad API dependency from Discovery Base

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148699#comment-15148699
 ] 

Carsten Ziegeler commented on SLING-5485:
-

yes, I think this is just about unwanted log messages in the end

> Remove Launchpad API dependency from Discovery Base
> ---
>
> Key: SLING-5485
> URL: https://issues.apache.org/jira/browse/SLING-5485
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Base 1.1.2
>Reporter: Oliver Lietz
>
> see SLING-2968 and [discussion on 
> dev@|http://mail-archives.apache.org/mod_mbox/sling-dev/201512.mbox/%3c56614f80.9040...@apache.org%3e]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5485) Remove Launchpad API dependency from Discovery Base

[Oliver Lietz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148691#comment-15148691
 ] 

Oliver Lietz commented on SLING-5485:
-

This is the code from {{BaseViewChecker}} we're talking about:

{noformat}
/**
 * Issue a heartbeat.
 * 
 * This action consists of first updating the local properties,
 * then issuing a cluster-local heartbeat (within the repository)
 * and then a remote heartbeat (to all the topology connectors
 * which announce this part of the topology to others)
 */
protected void issueHeartbeat() {
updateProperties();

issueConnectorPings();
}

protected abstract void updateProperties();

/** Issue a remote heartbeat using the topology connectors **/
protected void issueConnectorPings() {
if (getConnectorRegistry() == null) {
logger.error("issueConnectorPings: connectorRegistry is null");
return;
}
if (!startupFinished) {
logger.debug("issueConnectorPings: not issuing remote heartbeat 
yet, startup not yet finished");
return;
}
if (logger.isDebugEnabled()) {
logger.debug("issueConnectorPings: pinging outgoing topology 
connectors (if there is any) for "+slingId);
}
getConnectorRegistry().pingOutgoingConnectors(forcePing);
forcePing = false;
}
{noformat}

The instance is pinging itself (_local_) over a _remote_ (HTTP) connection and 
takes _startup finished_ into account to prevent error messages as shown in 
SLING-2968.

Taking _startup finished_ into account does not work for _remote_ instances and 
error responses can happen (for what ever reasons) and should be handled 
gracefully in any case.

So it seems SLING-2968 is about not polluting the log only, right?

If that's the case we should discuss if {{SlingRequestProcessorImpl}} uses the 
right level for logging the missing {{ServletResolver}} – IMHO _info_ (or at 
most _warn_) is appropriate (as a missing service is a normal case when Sling 
starts up and not an error).

> Remove Launchpad API dependency from Discovery Base
> ---
>
> Key: SLING-5485
> URL: https://issues.apache.org/jira/browse/SLING-5485
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Base 1.1.2
>Reporter: Oliver Lietz
>
> see SLING-2968 and [discussion on 
> dev@|http://mail-archives.apache.org/mod_mbox/sling-dev/201512.mbox/%3c56614f80.9040...@apache.org%3e]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Sling Resource Resolver 1.4.2, JCR Resource 2.7.2, and Servlets Resolver 2.4.2

[Oliver Lietz]

On Monday 15 February 2016 13:51:47 Carsten Ziegeler wrote:
> Hi,
> 
> These are mainly bug fix releases:
> 
> Resource Resolver 1.4.2 (10 issues)
> https://issues.apache.org/jira/browse/SLING/fixforversion/12334452

+1

> JCR Resource 2.7.2 (5 issues)
> https://issues.apache.org/jira/browse/SLING/fixforversion/12334453

+1

> Servlets Resolver 2.4.2 (1 issue)
> https://issues.apache.org/jira/browse/SLING/fixforversion/12334794

+1

O.

[jira] [Commented] (SLING-920) Sling Jenkins setup

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148271#comment-15148271
 ] 

Bertrand Delacretaz commented on SLING-920:
---

I have added {{-Dsling.testing.timeout.multiplier=4}} to the 
{{sling-trunk-1.7}} and {{sling-trunk-1.8}} builds after seeing several "test 
not ready" timeout errors in {{ResourceBuilderIT.}} This will increase the 
timeout set by {{RBIT_TeleporterCustomizer}} as well as any tests that use the 
{{TimeoutsProvider}}.

> Sling Jenkins setup
> ---
>
> Key: SLING-920
> URL: https://issues.apache.org/jira/browse/SLING-920
> Project: Sling
>  Issue Type: Task
>  Components: Testing
>Reporter: Bertrand Delacretaz
>
> Use this issue to record changes to the Jenkins setup at 
> https://builds.apache.org/view/S-Z/view/Sling/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)