Re: Resource to json serializing

[Steven Walters]

>
> >... First question being, which JSON library do we support? As we settled on
> > johnzon, I assume thats the one...
>
> It looks like the Johnzon Mapper module [2] should support what I need
> but I haven't found real documentation about it so far. I'll have a
> look a might switch the graphql-core to it if I like what I see.

though Johnzon Mapper can handle generic data types like deeply nested maps,
such as what is returned by graphql-java, but the controls here are
rather limited.
Most of the functionality is tuned to well-defined POJOs and not something
generic such as a sling Resource or JCR Node.
I've been using Mapper by itself and combined with graphql-java for 3+ years,
filing bugs and PRs on Mapper along the way.
For graphql-java + any JSON serializer, it simplifies down
to null, Map, and GraphQLScalarType serializations.

If one would want to use Mapper within Sling generically, this would
likely entail
having a org.apache.johnzon.mapper.ObjectConverter.Writer implementation to
handle serializing Resources as JSON properly.
This Writer implementation would then handle the control as to *what
to write* on a
Resource, such as which properties and which resource/node children, leaving the
*how to write* to the Mapper configuration.

>From a rather quick attempt at seeing if such a Writer exists, I did
not find anything
but instead found many direct uses of JSON-P instead.
Whether this is a benefit or nuisance lies in how much of the JSON-P logic is
shared or duplicated. I've not gone deep enough to have any foundation for
evaluating sling here.

Utilizing Mapper would allow simplify configuring how to serialize
property values
types (e.g. java.time types as ISO 8601) by registering Adapters or
Writers to serialize
those types.
The configuration could then be shared by all components within the
system needing
to serialize (deserialize) and then possibly allow for one-time
overrides by accepting an optional
Mapper instance when serializing.

Re: "java.lang.VerifyError"

[Steven Walters]

This error is usually caused by an old version of ASM that is used for
writing the implementation of the bind/unbind methods of references if
such functions do not already exist.

This usually stems from the use of an old maven-scr-plugin, and
upgrading to a newer one will most usually fix this, or you can write
the java code for bind/unbind yourself (so they are not auto-generated
incorrectly).

I don't remember what all was in Sling8, so not sure if you could
migrate to the now preferred OSGi R6/DS 1.3 annotations instead...


On Tue, Jan 31, 2017 at 7:28 AM, lancedolan  wrote:
> Sort of solved:
>
> adding -noverify to the JVM arguments stops this error from occurring.
>
> However, I don't fully understand the cause and I'm also nervous about
> forward compatibility... I wonder how this could prevent us from moving to
> future Java versions. It just seems like a bad smell that stable behaviour
> depends on an esoteric JVM flag.
>
>
>
> --
> View this message in context: 
> http://apache-sling.73963.n3.nabble.com/java-lang-VerifyError-tp407p4070001.html
> Sent from the Sling - Users mailing list archive at Nabble.com.

Re: How to create Rest APIs for non-JCR data in Sling 8??

[Steven Walters]

On Sat, Jan 28, 2017 at 6:27 AM, lancedolan  wrote:
> Hi friends,
>
> I've tried routing questions through stackoverflow to cut down my mails to
> this list. I'm losing lots of time on this one, though, and am stuck.
>
> I need to create APIs which don't represent Sling Resources. Example:
> /services/images/123123123
> that image will exist somewhere else.
>
> Bertrand suggests creating a ResourceProvider, as in the example here [1].
> However, that uses the spi package which is not in version 2.9.0 of
> org.apache.sling.api, and thus, not available to me in Sling 8.
>
> I did find a ResourceProvider interface to implement though, and created
> this code:
>
> /**
>  * Created by lancedolan on 1/27/17.
>  */
> @Component
> @Service(value=ResourceProvider.class)
> @Properties({
> @Property(name = ResourceProvider.ROOTS, value = "things"),
> @Property(name = ResourceProvider.OWNS_ROOTS, value = "true")
> })
> public class ImageResourceProvider implements ResourceProvider {
>
> /** If this provider required a context this would be more elaborate,
>  *  but for this simple example we don't need one.
>  */
> public static class DoesNotNeedAContext {
> };
>
> @Override
> public Resource getResource(ResourceResolver resourceResolver, String
> path) {
> Resource returnResource = new SyntheticResource(resourceResolver,
> path, "edlio/microservice/image");
> returnResource.getValueMap().put("myProp" , "myValue");
> return returnResource;
> }
>
> @Override
> public Resource getResource(ResourceResolver resourceResolver,
> HttpServletRequest httpServletRequest, String path) {
> return getResource(resourceResolver , path);
> }
>
> @Override
> public Iterator listChildren(Resource resource) {
> return null;
> }
> }
>
>
> The result is that I get a 403 response. How do I control the authentication
> for resources that don't actually exist? The fact that I'm not getting 404
> means that my ResourceProvider is at least registering successfully.
>
> Finally, I'd much prefer to use Jersey if possible... Anybody have success
> getting Jersey to work in Sling 8? I dumped a bunch of time into it and gave
> up after class not found errors for classes that should be found [2].
>
> The ultimate goal is just to provide a restful API in Sling 8 and the
> static-path-declaration of SlingSafeMethodsServlet just doesn't cut it.
>
> Thanks a million guys...

The Sling paradigm for this is to create resources through the
resource provider,
and then create/register a servlet to respond to the resource type
you're creating (not a static path).

So from your above code, you'd create an additional servlet registered
to the resourceType "edlio/microservice/image" (instead of registered
to a static path) and implement GET inside it.

Without the corresponding servlet, this is most likely being served by
the default GET servlet, which will not particularly understand how to
deal with these resources, thus the errors.

Re: Sling Servlet using OSGI R6 annotations

[Steven Walters]

On Mon, Nov 28, 2016 at 8:19 PM, Júnior  wrote:
> Hi,
>
> I'm trying to register a servlet using the OSGI r6 annotations but It is
> not working.
>
> Follow the configurations I am using:
>
> R6
>
> *@Component(service=Servlet.class,*
>
> *property = { *
>
> * "sling.servlet.methods=GET",*
>
> * "sling.servlet.paths=/system/mypath1",*
>
> * "sling.servlet.paths=/system/mypath2",*
>
> *   },*
>
> *immediate=true*
>
> *)*
>
>
> But When I use the @SlingServlet annotation it works:
>
> *@SlingServlet(paths={"/system/mypath1", "/system/mypath2"},
> methods={"GET"})*
>
> Am I missing some configuration?
>
> Does someone have an example of this kind of configuration?

Which version of maven-bundle-plugin (or bnd-maven-plugin) are you
using in your build?
If I recall correctly, the R6 annotations require the use of the 3.x
versions of either of the plugins to have the annotations be processed
appropriately.

Re: Creating lots of nodes

[Steven Walters]

On Fri, Oct 28, 2016 at 11:55 PM, Christoph Thodte
 wrote:
> Hello!
>
> What is the best and fast way to create a lot of resources in Sling? I import 
> 200.000 data rows in jcr. My importer is very fast for the 30.000 nodes than 
> it will be very slow down. I commit my resourceresolver ervery 100 resources. 
> The committing is fine but the time for creation of the resource is increased 
> very fast. After 40.000 nodes the time is around 20min for creation of 100 
> nodes.
>
> What is the problem? How can I speed up. Can anyone support or explain this?
> As datastore I use the mongodb. With tar it's slower than mongo. I use Sling 
> API not the JCR Api. That's the problem?

I've not seen any particular performance difference in the past
between using the Sling API vs the JCR API for massive data creation
like this.

Can you elaborate a bit more on how you're organizing the data that
you're creating within Sling?

That is, in the past there have been known performance problems with
having a large number of direct children nodes/resources under a
single parent within the JCR.
So just wondering how you're structuring the data as you're creating
it within Sling.
Without such information, it's mostly grabbing at straws to guess what
your problem may be.

Re: Adding jcr:created date to resource

[Steven Walters]

A) Sling expects the mixin types to passed as their raw String values
and not as the JCR NameValue type.

The fact that the JCR NameValue type is being utilized instead is
causing the error you are seeing as the Sling functionality converted
it to a String (incorrectly) causing it to become invalid to the JCR
expectations causing an exception on trying to add the corrupted mixin
type.

B) jcr:created is specifically handled by the JCR system, so Sling
refuses to be the writer/modifier of the property, silently ignoring
any attempts at setting/modifying the value.

Therefore, once you remove the attempt at setting jcr:created and
correct the jcr:mixinTypes value, you should be allowed to create the
resource.
>From there, the JCR system should automatically add the jcr:created
due to the mixin Type.

On Tue, Sep 20, 2016 at 9:46 PM, Roy Teeuwen  wrote:
> Hello all,
>
> I am trying to create an nt:unstructured resource programatically, which 
> contains a jcr:created property, but I don’t seem to find a way to add this 
> programatically, nor how to add a jcr:mixinType (which would make it 
> possible).
>
> I tried the following, but it isn’t working:
>
> Resource myResource = resourceResolver.getResource("/myresource");
> Map properties = new HashMap();
> properties.put("jcr:primaryType", "nt:unstructured”);
> properties.put("jcr:mixinTypes", new NameValue[] 
> {NameValue.valueOf("mix:created")});
> properties.put(“jcr:created”, Calendar.getInstance());
> Resource dummy = resourceResolver.create(myResource, "dummy", properties);
> resourceResolver.commit();
>
> I get the following exception:
>
> java.lang.IllegalArgumentException: Value can't be stored in the repository: 
> org.apache.jackrabbit.value.NameValue@0
>
>
> Can anyone tell me on how to add this on creation time?
>
> Thanks!
> Roy

Re: Outbound Link Mangling

[Steven Walters]

This is the namespace mangling feature in the Sling Resource Resolver
Factory configuration:


Namespace Mangling

Defines whether namespace prefixes of resource names inside the path
(e.g. "jcr:" in "/home/path/jcr:content") are mangled or not. Mangling
means that any namespace prefix contained in the path is replaced as
per the generic substitution pattern "/([^:]+):/_$1_/" when calling
the "map" method of the resource resolver. Likewise the "resolve"
methods will unmangle such namespace prefixes according to the
substituation pattern "/_([^_]+)_/$1:/". This feature is provided
since there may be systems out there in the wild which cannot cope
with URLs containing colons, even though they are perfectly valid
characters in the path part of URI references with a scheme. The
default value of this property if no configuration is provided is
"true". (resource.resolver.manglenamespaces)


As indicated in the description, the option is on by default, so
turning it off should fix your issue here.

This is a feature that is meant for JCR namespaces appearing in paths,
as they are prefixed by colons, such as "jcr:content" getting mangled
into "_jcr_content" that is often seen in AEM content trees.
As such, you may need to validate that turning this off isn't going to
cause other issues in return.

On Tue, Aug 9, 2016 at 10:37 PM, Christopher Rockwell
 wrote:
> Hi all.
>
> I’m having trouble with outbound links within AEM containing colons (:) 
> within the URL hash. The problem seems to stem from Sling URL mangling. I 
> created a Stackoverflow question with the details- see link below. I’m hoping 
> folks on the list can take a look and provide some suggestions.
>
> http://stackoverflow.com/questions/38752586/outbound-links-with-colon-in-hash-get-mangled
>  
> 
>
> Thanks!
> Chris Rockwell
> University of Michigan
> Web Services, Sr. Application Developer
> cmroc...@umich.edu ,
>
>

Re: Querying vs iterating

[Steven Walters]

Hopefully other people chime in here, I've only had bad experiences
with utilizing queries and have often resulted in personally never
using them - so I always end up iterating/navigating myself.

Theoretically if you have a REALLY GOOD index then you may get some
similar performances, but if your index(es) are inefficient, then it's
just wasted CPU cycles (you'd wish those CPU cycles were going to a
good cause, but they're not).

the transition of Sling (and AEM) to Oak from Jackrabbit 2.x made this
experience worse with the awkward indexing policies/process in Oak,
and the fact that Oak never seemed to ever use multiple indexes.
Oak always seemed to calculates the costs of the entire query against
all the available indexes and only chooses the ONE best index.
This sounds like a good idea in theory, but then most DBMS I've used
in the past utilize ALL the indexes they can - not just one.

So basically i guess this comes to be "If you have a good index (in
that it can apply to ALL the conditions/attributes/properties of your
query) then using a query should be fine, otherwise iterate yourself"
having any condition missing from the index can be fatal in
performance, such as lacking the evaluatePathRestrictions = true,
which without it is basically death of the system if you have a lot of
content.

But really, I hope some other people with more positive experiences
can provide some better advice.

On Thu, Jun 16, 2016 at 11:08 PM, Roy Teeuwen <r...@teeuwen.be> wrote:
> Ok, it would be handy to have an estimate on the approximate amount / levels 
> of resources when to go for iterating vs querying :).
>
> Greets
> Roy
>> On 16 Jun 2016, at 16:06, Steven Walters <kemu...@gmail.com> wrote:
>>
>> if you know there are that few resources, then I say iterating would be
>> better performing than XPath / JCR-SQL2 queries.
>> This is primarily from past experience speaking in that queries have
>> generally turned out (often MUCH) slower than directly iterating if you
>> know what you're actually looking for.
>>
>>
>> On Thu, Jun 16, 2016 at 10:28 PM, Roy Teeuwen <r...@teeuwen.be> wrote:
>>
>>> Hello all,
>>>
>>> Lets say I got a resource with around 10-20 child/grand-child resources,
>>> not going deeper than 3 levels max. What is the most performant when
>>> searching for the child resources containing a specific property (the
>>> property is configurable with OSGi, so hard to put an index on it).
>>> Iterating the child / grand-child resources until you find it or making an
>>> xpath/jcr-sql2 query? When would one option start to be more performant
>>> than the other.
>>>
>>> Thanks!
>>> Roy
>

Re: sling without a jcrResourceProvider

[Steven Walters]

I've seen this API (mentioned) before, and I don't understand why it
has to get passed onto the ResourceProvider to handle the logic.
It could instead be ResourceProvider agnostic, so always
available/functioning no matter what providers are around/in use.

Continuing to depend on ResourceProviders for such functionality
(especially a query language this basic that could just be done
through standard Sling resource visitation/navigation/iteration)
doesn't seem all that beneficial, it just seems to add more complexity
to the ResourceProviders that already have enough complexity as they
are.

On Thu, Jun 16, 2016 at 10:43 PM, Carsten Ziegeler <cziege...@apache.org> wrote:
> Jason E Bailey wrote
>> Which api proposal is that?
>>
>
> https://issues.apache.org/jira/browse/SLING-4752
>
> Carsten
>
>> --
>> Jason
>>
>>
>>
>> On Thu, Jun 16, 2016, at 01:14 AM, Carsten Ziegeler wrote:
>>> Steven Walters wrote
>>>> The other providers sling manages in its codebase don't appear to
>>>> get much
>>>> TLC, such as that they're all still using the older deprecated
>>>> ResourceProvider system, instead of the new one (which the JCR
>>>> ResourceProvider does use).
>>>>
>>>> Also, it appears that a number of the sling
>>>> components/functionalities
>>>> still require the JCR, such as
>>>> * Eventing/Jobs, by mandating node types and using JCR queries to
>>>>   retrieve
>>>> them.
>>>> * Generic Sling Post Servlet functionality, in that the
>>>> import/contentloader functionality of it still utilizes the JCR
>>>> APIs for
>>>> the creation of data.
>>>>
>>>> This is just some things I've seen so far from working on my own
>>>> ResourceProvider as well.
>>>>
>>>> So some portions of Sling can work without JCR but it still
>>>> remains that
>>>> some portions of functionality still cannot work without JCR
>>>> currently.
>>>>
>>>> The Sling Post functionality will be on the easier side to alter to
>>>> be JCR
>>>> independent, but Eventing will require more thought as to what to
>>>> do about
>>>> the queries.
>>>>
>>>
>>> We have a proposal for an API extension to solve that problem. Only
>>> thing missing is someone implementing it :)
>>>
>>> Carsten
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>>
>>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Querying vs iterating

[Steven Walters]

if you know there are that few resources, then I say iterating would be
better performing than XPath / JCR-SQL2 queries.
This is primarily from past experience speaking in that queries have
generally turned out (often MUCH) slower than directly iterating if you
know what you're actually looking for.


On Thu, Jun 16, 2016 at 10:28 PM, Roy Teeuwen  wrote:

> Hello all,
>
> Lets say I got a resource with around 10-20 child/grand-child resources,
> not going deeper than 3 levels max. What is the most performant when
> searching for the child resources containing a specific property (the
> property is configurable with OSGi, so hard to put an index on it).
> Iterating the child / grand-child resources until you find it or making an
> xpath/jcr-sql2 query? When would one option start to be more performant
> than the other.
>
> Thanks!
> Roy

Re: Using the resource resolver

[Steven Walters]

In the end, this primarily depends on the behavior of the underlying
ResourceProviders that funnel into the ResourceResolver.

For instance, if the ResourceProvider(s) support MVCC, then the data
available when the ResourceResolver was opened will be "stuck" to the
moment in time it was opened at, not seeing any of the updated data
since it was opened.
One way to resolve this, as already suggested, is to receive the
ResourceResolver as a parameter - this passes the burden of its life
onto "someone else", making it "not your problem".
Another way to resolve this is to call refresh() on the resolver
instance periodically, so as to retrieve the updates of data in the
system from other sources, if there are any.


If the ResourceProvider(s) do not support MVCC (which usually means
that refresh() actually does nothing) then a natural side effect is
that one would get the updated system data automatically without
needing to invoke refresh().
This route (not calling refresh and expecting updates to come in) is
most usually error-prone, since the most commonly used provider, Oak,
does support MVCC.
The NoSQL providers likely do also support MVCC due to the underlying
NoSQL server engines supporting MVCC, but not I've not confirmed this.


On Wed, Jun 15, 2016 at 12:30 AM, Paul McMahon  wrote:
> I generally follow the practice of having the resource resolver passed in if 
> possible. If the whatever is calling the service is triggered by some sort of 
> HTTP request it's always best to just have the resource resolver passed in - 
> in which case the resource resolver is only around for the life the request 
> and gets disposed of automatically by the system.
> If I do have to leverage a resource resolver that you get from the factory I 
> tend to try and dispose of them in the same method I created it.
> Paul McMahon
>   From: Roy Teeuwen 
>  To: users@sling.apache.org
>  Sent: Tuesday, June 14, 2016 11:19 AM
>  Subject: Using the resource resolver
>
> Hello all,
>
> I am wondering on the usage of the resource resolver and on how long it 
> should stay open. Lets say I have the following implementation:
>
> @Component
> @Service(SomeService.class)
> public class SomeServiceImpl implements SomeService {
>
> @Reference
>  private ResourceResolverFactory resourceResolverFactory;
>
> private ResourceResolver resourceResolver;
>
> @Activate
> protected synchronized void activate(Map properties) 
> throws Exception {
>   try {
> resourceResolver = 
> resourceResolverFactory.getAdministrativeResourceResolver(null);
> } catch (LoginException e) {
> LOG.error("Failed to get admin resourceresolver", e);
> throw e;
> }
> }
>
>  @Deactivate
> protected synchronized void deactivate(Map properties) 
> throws Exception {
> if (resourceResolver != null && resourceResolver.isLive()) {
> resourceResolver.close();
> }
> }
>
>   public void doSomething(String path) {
> Resource resource = resourceResolver.getResource(path);
>   //do something
> }
> }
>
>
> Is there anything wrong on using this? Knowing that this means the 
> resourceresolver will stay open for possible months/years…
> Or should one try and make the resourceresolver opening as short as possible? 
> Knowing that the method will be called around 1000-2000 times an hour.
>
> Another solution is of course passing the resourceResolver to do the 
> doSomething, but then the question still remains, how long should you keep a 
> resourceresolver open
>
> Greetings,
> Roy
>
>

Re: Fake request/response classes

[Steven Walters]

On Mon, Dec 21, 2015 at 10:30 AM, Stefan Seifert  wrote:
>
>>I know. But I don't want to deploy the Sling mocks library as a bundle
>>along with my Sling-based application to the OSGI container (haven't
>>checked if it's a bundle at all). I also don't want to embedd this jar file
>>into a custom bundle just because I need these few classes.
>
> sling-mocks is definitely not supposed to be deployed in an OSGi container 
> (and will fail due to unresolvable internal dependencies if tried to). it's 
> only supposed for unit test environment.
>
> refactoring the servlet api mocks from sling-mock to a separate and 
> lightweight bundle would be an option. imho it should be a separate bundle 
> instead of including them in the sling API.
>
> here are the classes
> https://svn.apache.org/repos/asf/sling/trunk/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/servlet
>
> most of them have no dependencies except some to commons-lang and guava which 
> could be eliminated if required.
>
> if there is need for using them standalone please create a ticket.
>
> stefan

Since this is about utilizing the SlingRequestProcessor [1], some
handy/convenient light-weight implementations of request and response
would be pretty beneficial here.
I've seen quite a number of projects end up having to make their own
implementations of the request and response classes to utilize the
request processor, which is the path Jörg here is implicating he's
needing to go down currently as well.

I think it'd be something for the Sling project to look at evaluating
here to make SlingRequestProcessor's usage more convenient going
forward.
Or at least, that's my opinion.

- Steven

[1] 
https://sling.apache.org/apidocs/sling8/org/apache/sling/engine/SlingRequestProcessor.html

Re: Fake request/response classes

[Steven Walters]

Jörg,

On Mon, Dec 21, 2015 at 9:10 AM, Jörg Hoh  wrote:
>
> Hi Bertrand
>
> 2015-12-21 13:56 GMT+01:00 Bertrand Delacretaz :
>
> >
> > Would the Sling mocks MockSlingHttpServletRequest and response work
> > for you? Or shall we maybe refactor them to inherit from new non-Sling
> > HttpServletRequest/Response mocks that are more generally usable?
> >
> > -Bertrand
> >
> > [1]
> > https://svn.apache.org/repos/asf/sling/trunk/testing/mocks/sling-mock/src/main/java/org/apache/sling/testing/mock/sling/servlet/
> >
>
> These would be sufficient. But I would like to have them in a "mainline"
> bundle and not in a codebase, which I normally use to run unittests.
>
> Jörg

Bertrand's referenced code is a portion of the Sling project's "Sling
Mocks" module that gets released to maven as a jar like other Sling
modules.
See the documentation for Sling mocks at [1] for further detail on how
to add it to a maven project and example usages.

- Steven

[1] https://sling.apache.org/documentation/development/sling-mock.html

Re: Custom queue

[Steven Walters]

On Tue, Nov 24, 2015 at 5:18 PM, Roll, Kevin  wrote:
>
> I have implemented a job as described here:
>
> https://sling.apache.org/documentation/bundles/apache-sling-eventing-and-job-handling.html
>
> @Component(immediate = true)
> @Service(value = JobConsumer.class)
> @Property(name = JobConsumer.PROPERTY_TOPICS, value = 
> ImageManagerUploadJob.JOB_TOPIC)
> public final class ImageManagerUploadJob implements JobConsumer
> {
>
> I wish to have this Job handled by a custom queue that processes jobs 
> sequentially, i.e. on a single thread. Forgive my densitude but I'm not 
> understanding how/where to apply the properties given on that documentation 
> page. It sounds like I define a queue and then associate the job with it? I 
> haven't been able to find an example of this. I'd like this all to be in code 
> so it always works without tinkering with stuff in the OSGi container. Thanks!
>

You need to create a new configuration from the factory-style
configuration "Apache Sling Job Queue Configuration"
(org.apache.sling.event.jobs.QueueConfiguration) to create a new queue
that has the desired topic(s) associated to it to have your jobs be
processed within that queue and its configuration parameters.

You could possibly have this configuration in "code" by either of
1) Accessing the org.osgi.service.cm.ConfigurationAdmin service and
creating a configuration via this mechanism, such as in a
BundleActivator .
2) Utilizing Sling's JCR Content Loader [1] and JCR Installer Provider
[2] mechanisms to have a sling:OsgiConfig content node be
automatically created & installed when the jar bundle starts.

There may be other possible routes depending on if other 3rd
party/external plugins/frameworks are within your Sling instance.

[1] 
https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html
[2] https://sling.apache.org/documentation/bundles/jcr-installer-provider.html

Regards,
Steven

sling-maven-plugin install goal issues

[Steven Walters]

I'm trying to use the sling-maven-plugin install as described at [0].
I'm now encountering a scenario where I can not use the goal to
install a bundle in a particularly desired way.

Previously, this was being used successfully within the environment to
place the bundles under the /apps/install folder within the JCR.
So this was configured in the pom.xml such as

  ${server}/apps/install
  true
  ${sling.user}
  ${sling.pass}

The target system here was a 5.x version of CQ/AEM.

However, we're now upgrading to a newer version of AEM, 6.1, and in
6.1 the functionality does not consistently work.
this is because Adobe has decided that the org.apache.sling.jcr.webdav
bundle should not always be installed.
This bundle appears to be providing the functionality that supports
the usePut = true in sling-maven-plugin, so this effectively makes
usePut = true unable to be utilized reliably any longer.

So on trying to switch to usePut = false, in this mode it seems to be
assuming POSTs to the Felix Web Console. I can not see a way to alter
this assumptive behavior to utilize the SlingPostServlet style of file
uploads such as in [1] to resolve this.

Is there any way to utilize SlingPostServlet within the
sling-maven-plugin to install the bundles?

Thanks,
Steven.

[0] - http://sling.apache.org/site/sling.html#Sling-install
[1] - 
http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#file-uploads

Re: sling-maven-plugin install goal issues

[Steven Walters]

Yes, this was a surprise to find that the plugin for/by Sling would
ignore basic Sling provided functionalities, in this scenario always
utilizing/assuming functionality of Felix instead.

Would the developers/maintainers be open to an enhancement to the
plugin to support this scenario?

On Wed, Oct 28, 2015 at 11:22 AM, Jason Bailey  wrote:
> I'm reading Steven's concern as that the Sling plugin is not assuming the use 
> of the Sling post handler.  Which is preventing the use of the POST command 
> to the desired location.
>
> Which is kind of odd.
>

Re: Uploaded file MIME type

[Steven Walters]

On Wed, Oct 7, 2015 at 2:46 PM, Roll, Kevin  wrote:

> I am trying to upload a PNG file to the repository, using the
> SlingPostServlet. The problem I am encountering is that the field
> jcr:mimeType on the automatically created node ends up being "image/x-png",
> which is causing me a lot of trouble downstream because "x-" indicates a
> non-standard MIME type. Is this expected? Where does the "x-" come from?
> Referencing the documentation at
>
>
> https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html
>
>
>   *   jcr:mimeType -- The MIME type from the original file submission (if
> contained in the file body part) or derived from the original file name
> Even if I provide a file name of "whatever.png" I still get a MIME type of
> "image/x-png", so this doesn't work. I'm not sure I understand how to put
> the MIME type into my POST in order to set it explicitly. How can I work
> around this issue?
>
> As a point of interest I am almost certain that I was getting the correct
> type a few months ago. I haven't been able to determine what change, if
> any, introduced this issue.
>
> Thanks!
>
>
Have you checked to see what the mime type registry has in place for the
png extension? There's quite a number of rules for auto-selecting the
mimetype, so reviewing the details on [1] would be my suggestion here.
The mimetype registry may have changed without your knowledge, so
confirming that it is correct (has the expected value) would be a first
step.

[1]
https://sling.apache.org/documentation/bundles/mime-type-support-commons-mime.html


-- 
Steven

Re: Control JcrInstaller (OsgiInstaller) Behavior of Bundle Updating vs Installing

[Steven Walters]

On Mon, Sep 21, 2015 at 1:26 PM, Carsten Ziegeler 
wrote:

> Unfortunately, the OSGi installer does not support this use case, and
> the same goes with the web console from Apache Felix.
>
> Actually, this feature has been requested several times, but so far we
> never did anything. I think the easiest way would be to make the
> distinction based on the major version:
> - same major version -> update
> - different major version -> install
>

I think the suggested change to the default behavior makes sense.

Granted there are some scenarios where I could see this being rather
complicated such as if a bundle had a minor version bump but incremented
its package by a major version, such as a bundle incrementing from "2.0" to
"2.1", but package X increments from "2.0" to "3.0" (I do hope there is no
one actually doing this in practice however).


>
> If that behaviour is not sufficient, we can think about further
> controlling it. While the OSGi installer has the ability to get passed
> additional parameters for an artifact, which could be used to further
> control this behaviour, the problem is how to specify this? When
> artifacts are installed from the file system there is basically no nice
> way to do this. For the JCR repository, properties could maybe add
> somewhere?
>
> Carsten
>


As for further control or refinement, which can be useful for more
particular scenarios or possibly for particular vendor desired behaviorisms
(Adobe perhaps for AEM surrounding their Hotfix and SP system, which may be
useful for their existing "fileinstallpatch" installer)
for the JCR side, properties could be on the watched folder or on the
nt:files to indicate the behavior of what should happen to bundles if
needing to override the default.

For the file system side, this can either be either by altering the
sling.fileinstall.dir property behavior some.
the property already accepts commas for lists of paths, so extending the
grammar a bit more to allow an extra delimiter such as : or ; to indicate
the override mode to apply for that folder, such as

/sling/watch/folder/a:install,/sling/watch/folder/b:update,/sling/watch/folder/c

Or there could be some particular file (whether purely by name, or by a
name and defined by its contents) within the watch folders that refine the
behaviorisms, and this could work for both JCR and file system modes.


Such a behavioral change does open up some interesting scenarios though,
such as the following

1) "Gap version update"
Prerequisites:
Bundle "X" is within folder "foo" at version "5.0"
Folder "foo" is set to always update,

Bundle "X" is also installed at folder "bar" at version "7.0"
Folder "bar" is set to default behavior

Steps:
Bundle "X" at version "6.0" is placed into folder "foo"

Possible expectation:
Bundle "X" at "5.0" is updated to "6.0"

Such an expectation seems reasonable, at least to me.


2) "Update to already existing major version, though of a higher minor"
Prerequisites:
Same as above

Steps:
Bundle "X" at version "7.1" is placed into folder "foo"

Possible expectations:
a) Bundle "X" at "5.0" is updated to "7.1"
b) Bundle "X" at "7.0" (within "bar") is updated to "7.1"
c) Unable to decide which to update -> do nothing.

Here, the interesting choice is which bundle would get the update: the one
in the same folder, or the one that matched the major version?
Either routes have their merits, but which should it be? That is, what
would be the "matching algorithm" be for existing bundles to be updated?

Route "a" takes an approach of "same folder as existing bundle so it should
update any bundle in its own co-located folder first, before updating
'outside' bundles"
Route "b" is more along the lines of "select any bundle matching same major
version, before matching against other versions"

Route "c" is always a valid option, and may be a route to go down for a
while until a more discussed and agreed upon solution arises for such a
scenario.

-Steven