Re: import and export JCR data

2017-02-07 Thread lancedolan
If it's not composum, then it's file-vault or JCR related, which is even more
concerning. 

I'm pretty confident this isn't user error. I've given consulting
demonstrations, teaching others the ins and outs of file-vault XML-to-node
translation, the various complex rules one can combine, and also written
code that dynamically assembles valid file vault packages to be POSTed to
CRX package manager, which I believe also uses file vault under the hood...
I'm really quite aware, in general, of how this thing should work. Of course
I could be missing something, but if this is user error, then it's something
esoteric and imperceptible, something very different than the CRX and file
vault I'm used to.

Here's what I'm doing:

1) click "+" to create new package
2) click filter tab and "+" to create new filter
3) give root path "/content" and save with default Replace Import Mode and
empty filter set
4) Click Build

Result: empty content directory in the package. Nothing in the log file. 

I suppose as a next step I can split all com.composum logs to a separate log
and set that to DEBUG level and watch for things... Maybe do the same with
org.apache.jackrabbit.vault. 

One plausible possibility seems that my /content data might be in some
invalid state such that file vault can't/won't read it?? I'm really grasping
at possibilities at this point.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/import-and-export-JCR-data-tp4069390p4070161.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: How to export Sling data?

2017-02-07 Thread lancedolan
Sorry, double post.

See
http://apache-sling.73963.n3.nabble.com/import-and-export-JCR-data-td4069390.html



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-export-Sling-data-tp4070157p4070158.html
Sent from the Sling - Users mailing list archive at Nabble.com.


How to export Sling data?

2017-02-07 Thread lancedolan
Hi All, 


Does anybody have some terminal commands or procedure they follow for
exporting data without composum? I've downloaded this "jackrabbit-filevault"
project, and I've tried some different terminal commands after reading the
documentation. Not sure what I'm doing. 

Does anybody here export data from JCR without composum? What's the process?


* 
For those curious, why not Composum? 
It is demonstrating a severe defect preventing me from building a jcr
package [https://github.com/ist-dresden/composum/issues/60]. Even if that
defect is solved, this instability is concerning enough that we need a
separate reliable process for exporting data



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-export-Sling-data-tp4070157.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: import and export JCR data

2017-02-07 Thread lancedolan
Hi All,


Does anybody have some terminal commands or procedure they follow for
exporting data without composum? I've downloaded this "jackrabbit-filevault"
project, and I've tried some different terminal commands after reading the
documentation. Not sure what I'm doing.


*
For those curious, why not Composum?
It is demonstrating a severe defect preventing me from building a jcr
package [https://github.com/ist-dresden/composum/issues/60]. Even if that
defect is solved, this instability is concerning enough that we need a
separate reliable process for exporting data.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/import-and-export-JCR-data-tp4069390p4070156.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Components each process twice

2017-02-02 Thread lancedolan
This response is good enough for me. The fact that the community hasn't
largely said "yea we see it all the time and it's normal" tells me I'm
probably causing this myself somewhere, and I'll have to look into it. I
just didn't want to lose a day figuring out the root cause if this was known
normal sling behaviour, or that sometime it just needs to render a component
twice to for its own reasons.

Curious that I've observed this on other projects from other devs - we must
be falling for the same pitfall.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Components-each-process-twice-tp4070042p4070081.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??

2017-01-31 Thread lancedolan
Aha! Solved Here's my solution for posterity.

While Jersey would have been a preferred, more feature-rich solution, I just
couldn't get the OSGI-Jersey stuff working.

The solution: 

- ResourceProvider listens for all requests to a particular path, and
returns a false "Resource" object, which doesn't actually exist in the JCR,
but it does have a resourceType

- A Servlet registers to render that resourceType.

Between these two, you've essentially got a Servlet that listens to a all
requests that fall under a particular Path :)

Registering a Servlet for a resourceType is pretty elementary, but for
posterity looking to get this ResourceProvider working in Sling 8, here's
how I did it. I expect there are better ways, but this is demonstrative:


/**
 * Created by lancedolan on 1/27/17.
 */
@Component
@Service(value=ResourceProvider.class)
@Properties({
@Property(name = ResourceProvider.ROOTS, value = "service/image"),
@Property(name = ResourceProvider.OWNS_ROOTS, value = "true")
})
public class ImageResourceProvider implements ResourceProvider  {

//@Override
public Resource getResource(ResourceResolver resourceResolver, String
path) {

AbstractResource abstractResource;
abstractResource = new AbstractResource() {
@Override
public String getResourceType() {
return ImageTypeServlet.RESOURCE_TYPE;
}

@Override
public String getResourceSuperType() {
return null;
}

@Override
public String getPath() {
return path;
}

@Override
public ResourceResolver getResourceResolver() {
return resourceResolver;
}

@Override
public ResourceMetadata getResourceMetadata() {
return new ResourceMetadata();
}
};

return abstractResource;
}

//@Override
public Resource getResource(ResourceResolver resourceResolver,
HttpServletRequest httpServletRequest, String path) {
return getResource(resourceResolver , path);
}

//@Override
public Iterator listChildren(Resource resource) {
return null;
}
}

And then you just create your own servlet, analogous to my ImageTypeServlet
which contains a static final String RESOURCE_TYPE



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4070023.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??

2017-01-31 Thread lancedolan
Henry Saginor-2 wrote
> Hi Lance,
> 
> I think a better practice is to register your servlet with a resource type
> instead of path.

This requires creating a node per resource. Please see my prior post where I
disqualify all solutions that involve creating nodes. My entire requirement
is that I'm creating a service that serves data that isn't in the JCR. I
truly do appreciate your taking the time out of your day to try to help me,
though, so I hope you don't feel slighted! :) I have been lead AEM Architect
on Sling applications that serve millions of users globally and am already
familiar with the fundamentals of Sling resource and script resolution :)
This is just my first time needing to serve up "virtual" resources of very
large number like this, such that a dynamic-URL service is absolutely the
only solution.

Update: I've made progress with the ResourceProvider solution! It seems the
403 response I was getting was actually result of my ResourceProvider
successfully returning SyntheticResource, which Sling then responded with a
403 for...  It seems all I need to learn is how to properly instantiate a
Resource object and return it :)

It seems I need to learn about this ResourceWrapper class and how to create
ResourceMetadata



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4070022.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: "java.lang.VerifyError"

2017-01-30 Thread lancedolan
That's the solution, thank you!

My maven-scr-plugin version had fallen badly out of date by re-building from
an archetype... bumped to latest version and I no longer need the -noverify
argument.

Thanks again :D



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/java-lang-VerifyError-tp407p4070003.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: "java.lang.VerifyError"

2017-01-30 Thread lancedolan
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.


"java.lang.VerifyError"

2017-01-30 Thread lancedolan
Has anybody run into this before? I'm tempted to thing it's a defect in Sling
8.

I write a @Service for OSGI, and it has a @Reference to another service,
such as a ResourceResolverFactory, and deploy it to Sling the same way I
have for several years, and it fails to get the Reference, with the
following: 

Error during instantiation of the implementation object
(java.lang.VerifyError: Expecting a stackmap frame at branch target 13
Exception Details:
  Location:
   
com/edliohelloworld/image_microservice/ImageServlet.unbindResolverFactory(Lorg/apache/sling/api/resource/ResourceResolverFactory;)V
@5: if_acmpne
  Reason:
Expected stackmap frame at this location.
  Bytecode:
0x000: 2ab4 002c 2ba6 0008 2a01 b500 2cb1 
)
java.lang.VerifyError: Expecting a stackmap frame at branch target 13
Exception Details:
  Location:
   
com/edliohelloworld/image_microservice/ImageServlet.unbindResolverFactory(Lorg/apache/sling/api/resource/ResourceResolverFactory;)V
@5: if_acmpne
  Reason:
Expected stackmap frame at this location.
  Bytecode:
0x000: 2ab4 002c 2ba6 0008 2a01 b500 2cb1 


Steps to reproduce:

- Running on Java 8 HotSpot JVM
- Download latest Sling 8 from http://sling.apache.org/downloads.cgi. You
can use either standalone or "Web Application," I've confirmed on both.
- Start the Sling server
- Write and Compile a simple OSGI bundle using the maven-bundle-plugin
- Include the following Servlet

@SlingServlet(
paths = "/myservice/image",
methods = {"GET" , "POST"})
public class ImageServlet extends SlingSafeMethodsServlet{

@Reference
ResourceResolverFactory resolverFactory;

@Override
protected void doGet(SlingHttpServletRequest request,
SlingHttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html");

PrintWriter out = response.getWriter();

out.println("
" + "HELLO WITH A  " + resolverFactory + " FROM SERVLET" + "
");

}

}

You'll get the error on deployment of the bundle, and the servlet will not
register, and you'll get a 404 when attempting to hit the servlet. If you
comment out the @Reference annotation, so that Sling doesn't try to inject
the ResourceResolverFactory, then the Servlet will register, but of course
the resolverFactory will be null.

I also tested by writing my own *very* simple hello world service, and that
gets the same java.lang.VerifyError on instantiation.

My best guess is that I need to use a different JVM version or some JVM
arguments so that it doesn't do this verification??






--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/java-lang-VerifyError-tp407.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??

2017-01-30 Thread lancedolan
I guess, even if we use SlingSafeMethodsServlet and request parameter, I
still have this problem of securing the servlet... I've put a servlet at
paths = "/myservice/image" , and created a node at /myservice with an ACL
that denies jcr: all to everyone and anonymous, and yet anonymous can still
GET /myservice/image. It seems authentication still succeeds, as my Servlet
can see the user ID on the request, but the authorization via Effective
Policies isn't happening.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4069998.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??

2017-01-30 Thread lancedolan
I'm surprised at all the tech opinions this raised :)

First, there's a couple popular suggestions happening which aren't going in
the right direction, so I'll get that out of the way quick:

1) Any solution that involves me creating a JCR node and binding by resource
type is infeasible. I'm not willing to create a JCR node for each Resource
on the proxied datasource. If I have a million images on S3, and I'm trying
to expose them via /service/image, I'm not willing to create a million nodes
underneath /services/image, nor am I willing to keep that in sync, nor am I
capable of predicting all of the possible images that could be requested in
order to create those nodes. That's a ridiculous amount of work when the
goal is just to make all requests at a dynamic path route to a single
method.

2) Some have also said not to use Sling for this... I appreciate the time
and thought, but that isn't helpful and I must do this in Sling. These
services need access to the JCR for other purposes, and I also want the same
authentication/authorization handlers handling these services as my other
requests to the JCR. There will be a /home principal which is allowed to
access this /service.

If we can't solve this, we'll just use SlingSafeMethodsServlet and use
request parameters instead (ie. /service/image?id=123123 ). This will make
us cringe but we'll bear it.

I'd *really* like to continue down the ResourceProvider path by providing a
path, as shown in my code above. If I can just get past this 403 error, I'm
good! The effective policies of my ResourceProvider at /things should just
inherit "/", which is everyone=jcr:all so it doesn't seem that creating a
node with an ACL on it will help.. I'll continue to play a bit.

As for the Spring suggestions: Thank you, I'll consider this! It seems like
a lot of library to bring in when we'd only use a tiny part of the
functionality And anyhow, doesn't Spring just use Jersey under the hood
to provide endpoints?


Bertrand Delacretaz wrote
> We might need to release Sling 9 soon

Yes please :)


Bertrand Delacretaz wrote
> Maybe we just need to flesh out examples like Henry's in actual samples.
> Lance, would that help you?

Isn't his suggestion one involving creating a JCR node for all possible
request paths? So, for /service/{id} which could service a million
unpredictable ids, then I'd need to create a million nodes with names that I
can't predict?



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4069997.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??

2017-01-27 Thread lancedolan
These APIs I'm looking to build are likely to use other OSGI services I've
written, and perhaps even write to the JCR for other reasons. Imagine doing
a GET /api/images/my-new-image.jpg and the image lives in Amazon S3, but you
want to write some audit data into the JCR.

I'm still thinking through the overall solution, and have considered you're
suggestion, but I don't want to give up on building APIs inside of
OSGI/Sling unless I really need to.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4069949.html
Sent from the Sling - Users mailing list archive at Nabble.com.


RE: Not-sticky sessions with Sling?

2017-01-18 Thread lancedolan
Jason Bailey wrote
> Couldn't this be simplified to simply stating that the sticky session
> cookie only lasts for x amount of seconds? 


WHOAAA!! 

Bertrand, probably hold the phone on everything else I suggested in my last
post - this solution is insanely simple, embarrassingly obvious in
hindsight, and us architects on our side can see no problem with this
solution.

We actually had no idea that there is a expiration by seconds setting in AWS
elastic load balancer. We just checked the interface and found the setting.
Obviously in the good old days of F5 we could do whatever we want, but we're
married to AWS now and had no idea we could do this.

Thank you Jason, you might have just saved me some unsavory development
task, whilst helping me Keep It Simple, Stupid.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069731.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Not-sticky sessions with Sling?

2017-01-18 Thread lancedolan
Chetan is making things crystal clear for us. 

Our next steps are:

1) Learn what the MAXIMUM "inconsistency window" could be. 
Is it possible to delay past 5 seconds? 10 Seconds? 60? What determines
this? Only server load? I'll ask on the JCR forum and also experiment. 

2) Design and test a solution almost exactly as Bertrand described. 
Sling responds to POST/PUT/DELETE with a JCR revision. Sling will behave
differently when the Request contains a JCR revision more recent than it's
current. I have no idea what I'm getting into or how hard this will be. 

Bertrand, I'd feel selfish taking you up on your offer to build this for me.
Yet I'd be a fool to not at least partner with you to get it done. Should we
correspond outside this mail list? 
Perhaps you could point me to the files you would edit to get this done and
I could try to do it myself? I imagine a solution where you can configure,
through OSGI, whether Sling will do one of the following:

A) Ignore JCR revision in Request, and function as it does today (Default
setting)
B) Block until it has caught up to JCR revision in Request
C) Call some other custom handler? This way we can do custom things like
send a redirect to enhance the user experience during a block. In a product
like ours, 5 or 10 second blocks aren't acceptable without user feedback. 

I also don't know how to determine the current Sling instance's Revision, or
how to compute whether one revision is "more recent" than another.

-

Responding to a couple other minor points:


Felix Meschberger-3 wrote
> I suggest you go with something else, which does *not* need the repository
> for persistence. This means you might want to investigate your own
> authentication handler ...

Thank you Felix :) I've actually done this work recently and it's working
great! We have "stateless" authentication now, but are now dealing with the
unacceptable inconsistency that Chetan warned about. 
That's the question on the table: In a write-operation-heavy application,
how do we provide a "read-your-writes" consistent experience on an
eventually-consistent solution (Sling cluster), when traditional 
sticky-sessions are an invalid solution because your userbase is large
enough to demand server-scaling several times throughout the day.


chetan mehrotra wrote
> I can understand issue around when existing Sling server is removed
> from the pool. However adding a new instance should not cause existing
> users to be reassigned

When adding an instance, we purposely invalidate all sticky sessions and
users will get re-assigned to a new Sling instance, so that the new server
actually improves performance.
Imagine a farm of 4 app servers that has been SLAMMED and isn't performing
well. Adding 1 or 100 new servers to that farm won't improve performance if
every user is "stuck" to the previous 4 servers.
If we don't do this invalidation and re-assignment on scaling-up, it can
takes hours potentially for a scale-up to positively impact an overloaded
cluster. 


Bertrand Delacretaz wrote
> But Lance could patch [1] to experiment with different values, right?
> 
> [1]
> http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java

Thank you for pointing me to the code Bertrand :) On new information from
Chetan, I'm losing interest in changing that value. Perhaps setting
aSyncDelay to 0 or some small number will cause it to perform slower but be
more consistent... 
However, my tentative assessment is that the interval would just be
"checked" more often, but it will also get skipped more often, due to "local
cache invalidation, computing the external changes for observation" as
Chetan put it. 
I would love to be wrong about this and I'll ask on the JCR forum.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069730.html
Sent from the Sling - Users mailing list archive at Nabble.com.


RE: Not-sticky sessions with Sling?

2017-01-17 Thread lancedolan
Thi is tempting, but I know in my dev-instinct that we won't have the
time to solve all the unsolved in that effort. Thank you for suggesting
though :)



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069712.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Not-sticky sessions with Sling?

2017-01-17 Thread lancedolan
lancedolan wrote
> I must know what determines the duration of this revision catch-up time
> ... 

While I don't know where to look in src code to answer this, I did run a
very revealing experiment.

It pretty much always takes 1 second exactly for a Sling instance to get the
latest revision, and thus the latest data. When not 1 second, it takes 2
seconds exactly. If you increase load on the server, the likelihood of
taking 2 seconds increases, and you also begin to see it take exactly 3
seconds in some rare cases. Increasing load increases the number of seconds
before a "sync," however it's always near-exactly a second interval.

It seems impossible for this to be a natural coincidence - I smell a setting
somewhere (or perhaps hardcode value) which is telling Sling to check the
latest JCR revision on 1 second intervals. When that window can't be hit, it
checks on the next second interval, and so on. 

Is there a Sling dev who can tell me whether this is configurable? I have a
load of questions about this discovery:

- Am I wrong? (I'll be shocked)
- Perhaps we can speed it up? 
- What event is causing it to "miss the window" and wait until the next 1
second synch interval?
- If we do decrease the interval, will that just increase the likelihood of
taking more intervals anyhow?
- Is there a maximum number of 1 second intervals before the things just
gets the latest??

progress.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069711.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Not-sticky sessions with Sling?

2017-01-17 Thread lancedolan
Bertrand Delacretaz wrote
> That would be a pity, as I suppose you're starting to like Sling now ;-)

Ma you have no idea haha! I've got almost every dev in the office all
excited about this now haha. However, it seems our hands are tied.

I wrote local consistency test scripts which POST and immediately GET a
property, checking for consistency. 

Results on a 2-member Sling cluster and localhost mongodb:

-0% consistency with 50ms delay between POST and GET
-35% to 50% consistency with 1 second delay between POST and GET 
-90% consistency with 2 second delay
-98% to 100% consistency after 3 seconds delay.

So yes, you are all correct. 

True, we could use sticky sessions to avoid inconsistency... but only until
we scale our server-farm up or down, which we do daily So sticky
sessions doesn't really solve anything for us.

If you already understand how scaling nullifies the benefit of sticky
sessions, you can skip past this paragraph and move onto the next:
Each time we scale, users will lose their "stickiness." We have thousands of
write users ("authors"). Hundreds concurrently. Compare that to typical AEM
projects have less than 10 authors, and rarely more than 1 concurrently
(I've got several global-scale AEM implementations under my belt). For us,
it's a requirement that we add or remove app servers multiple times per day,
optimizing between AWS costs and performance. Each time we remove an
instance, those users will go to a new Sling instance, and experience the
inconsistency. Each time we add an instance, we will invalidate all
stickiness and users will get re-assigned to a new Sling instance, and
experience the inconsistency. If we don't do this invalidation and
re-assignment on scaling-up, it can takes hours potentially for a scale-up
to positively impact an overloaded cluster where all users are permanently
stuck to their current app server instance.

As you can see, we need to deal with the inconsistency problem, regardless
of whether we use sticky sessions.

I have some ideas, but none are appealing, and would benefit greatly from
your guys' knowledge:

1) Race condition
If this delay to "catch up" to latest revision is mostly predictable, it
doesn't grow as the repo grows in size, or if it doesn't change due to other
variables, we can measure it and then account for it reliably with
user-feedback (loading screen or whatever). This *might* be a race condition
we can live with. 

My results above show as much as 3 or 4 seconds to "catch up."  I must know
what determines the duration of this revision catch-up time. Is it a
function of repo size? Does the delay grow as the repo size grows? Does the
delay grow as usage increases? Does the delay grow as the number of Sling
instances in the cluster grow? Does the delay grow as network latency grows
(I'm testing all on the same machine with practically no latency compared to
a distributed production deployment). Is there any Sling dev, who is
familiar with the algorithm that Sling uses to select a "newer" revision,
who could answer this for me? ... perhaps it's just polling on a predictable
time period! :) 

2) Browser knows what revision it's on.
The browser could know what JCR Revision it's on, learning that revision
after every POST or PUT, perhaps in some response header. When its future
requests are sent to a Sling instance on an older revision, it could wait
until that instance "catches up." This sounds like a horrible example of
client code operating on knowledge of underlying implementation details, and
we're not at all excited about the chaos to implement it. That being said,
can we programmatically check the revision that the current Sling instance
is reading from?

3) "Pause" during scale-up or scale-down.
Each time we add or remove a sling instance, all users experience a "pause"
screen while their new Sling Instance "catches up." This is essentially the
same as the race condition in #1, except we'd constrain users to only
experience this when we scale up or down. However, we are *extremely*
unhappy to impact our users just because we're scaling up or down,
especially when we must do so frequently. 

Anybody have any other ideas?

Other questions:

1) When a brand new Sling instance discovers an existing JCR (Mongo), does
it automatically and immediately go to the latest head revision? Or is there
some progression through the revisions, and it takes time for the Sling
instance to catch up to the latest?

2) Is there any reason, BESIDES JCR CONSISTENCY, why a Sling cluster must be
deployed with sticky-sessions? What other problems would we introduce by not
having sticky sessions?

I seem to have used this email to track my own thoughts more than anything,
my sincere thanks if you've taken the time to read the whole thing.




--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069709.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Not-sticky sessions with Sling?

2017-01-17 Thread lancedolan
Ok First of all - I GENUINELY appreciate the heck out of your time, and
patience!! 

... and THIS is really interesting:

If THIS is true:


chetan mehrotra wrote
> If you are running a cluster with Sling on Oak/Mongo then sticky 
> sessions would be required due to eventual consistent nature of 
> repository.

and THIS is true:


chetan mehrotra wrote
> Cluster which involves multiple datastores (tar) 
> is also eventually consistent. 

Then why is adobe recommending it's multi-million-dollar projects to go
stateless with the encapsulated token here, if those architectures are
*also* eventually:
https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html

If "being eventual" is the reason we can't go stateless, then how is adobe
getting away with it if we know their architecture is also eventual?? What
am I missing? I understand that the documentation I linked is a distributed
segment store architecture and mine is a share documentstore datastore, but
what is the REASON for them allowing a stateless (not sticky) architecture,
if the REASON is not eventual consistency ? Both architectures are eventual.

Again, thanks for your patience and sticking with me on this one... whoa
pun!



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069698.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Not-sticky sessions with Sling?

2017-01-16 Thread lancedolan
This is really disappointing for us. Through this revisioning, Oak has turned
a datastore that is consistent by default into a datastore that is not :p
It's ironic that the cluster which involves multiple datastores (tar), and
thus should have a harder time being consistent, is the one that can
accomplish consistency... and the cluster that involves a single shared
source of truth (mongo/rdbms), and should have the easiest time being
consistent, is not. Hehe. Ahh this probably shoots down our entire Sling
proof of concept project. 

Our next step is to measure the consequences of moving forward with
Sling+Oak+Mongo and not-sticky sessions. I'm going to try to test this, and
get an empirical answer, by deploying to some AWS instances. I'll develop a
custom AuthenticationHandler so that authentication is stateless and then
we'll try to see how bad the "delay" might be. However, I would love a
theoretical answer as well, if you've got one :) 


chetan mehrotra wrote
>  sticky 
> ... sticky sessions would be required due to eventual consistent nature of 
> repository. 

Okay, but if we disable stick sessions ANYHOW (because in our environment we
must), how much time delay are we talking, do you think, in realistic
practice? We might be able to solve this by giving user-feedback that covers
up for the sync delay. When a user clicks save, they might just go to a
different screen, providing enough time for things to sync up. It might be a
race condition, but that might be acceptable if we can choose that
architecture on good information. I think that, in theory, the answer to
"worst case scenario" for eventual consistency is always "forever," but
really... How long could a Sling instance take to get to the latest
revision? More importantly, is it a function of Repo size, or repo activity?
If the repo grows in size (number of nodes) and grows in use (number of
writes/sec) does this impact how frequently Sling Cluster instances grab the
most recent revision?

Less importantly... Myself and colleagues are really curious as to why
jackrabbit is implemented this way. Is there a performance benefit to being
eventually, when the shared datastore is actually consistent? What's the
reasoning for not always hitting the latest data?  Also... Is there any way
to force all reads to read the most recent revision, perhaps through some
configuration? A performance cost for this might be tolerable



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069661.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Not-sticky sessions with Sling?

2017-01-13 Thread lancedolan
Alright, this is a deal breaker for our business (if sling absolutely
requires sticky sessions). I hope you're not offended that I'm not 100%
convinced yet. I understand you do development on the sling project and are
well qualified on the topic. To be honest, however, I don't understand fully
what you said in your last post and I also know that AEM 6.1 can do what I'd
like, which is really just Sling+Oak. If they can do it, I don't understand
why we can't.

ref:
https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html

I'd hate to throw away all the awesome progress we've made with Sling so far
when I know that AEM, which is just sling + jackrabbit, can accomplish
app-server-agnostic authentication, and thus avoid sticky sessions.

Although I don't understand this "head revision" that you've described, and
that's inexperience on my part, I am confident that you're telling me that
when there is only one Mongo instance in existence, and all Sling instances
get data from it, that directly after "sling-instance-1" writes
"myProperty=myValue" to the JCR, then "sling-instances-2" could get the
value of "myProperty" from somewhere else - some old value. This only seems
possible to me if one of the following is true:

A) the Sling instances are caching values from Mongo (perhaps Sling or Oak
is doing that?) 
B) There are separate versions of that property stored in Mongo (perhaps
this is what you meant by the word revision) and it's possible for a
sling-instance to be reading an old version of a property from Mongo.
C) Mongo isn't consistent.

We know from mongo documentation that C isn't true - Mongo is consistent
when reading from the primary replica set. So it must be that A or B is
going on? And if so, what is your guess about how AEM 6, which is Sling+Oak,
avoids this pitfall when they very clearly support the stateless
architecture  (ie not-sticky) that I'm planning?




--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069605.html
Sent from the Sling - Users mailing list archive at Nabble.com.


RE: How to change run mode in Sling8

2017-01-12 Thread lancedolan
Update: Ok, I get it now. Thank you - this is really slick. 


For posterity:

The "source code" for the "Sling Source Release" artifact at [1] is really
not the project source code. It's just some text files that neatly describe
which OSGI bundles and configurations (including run modes) you'd like
present in a new .war file which is then built using *actual* sling
artifacts from completely different projects.  This is called Sling
Provisioning, but shouldn't be confused with actual provisioning tools like
vagrant or something. I had expected to see actual source code when I
clicked that link and that felt wrong. Now I understand. 

All you have to do is download the "source code," set your run mode in
boot.txt, modify the list of artifacts if you wish (in
groupid/artifactid/version format) and run maven clean install. And if you
come from an older Sling background like I do, where you can change run
modes willy-nilly with JVM arguments, I guess you just have to suck it up
and provision a new Sling instance. If you use a remote datastore (such as
oak_mongo) then you can do so without losing your JCR data as well. 

[1] http://sling.apache.org/downloads.cgi



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494p4069554.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Join new member to Sling Oak cluster?

2017-01-12 Thread lancedolan
Robert Munteanu-2 wrote
> - Are the Sling/Oak instances and MongoDB clocks in sync? 

I've just realized the significance of this question. Our Sling and Mongo
instances will be in different data centers entirely, Mongo provided as a
service and Sling in our own AWS instances somewhere... I suppose in this
distributed environment we don't have any strong guarantees about the clocks
being in Sync. Is this a known requirement of clustering? 



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Join-new-member-to-Sling-Oak-cluster-tp4069454p4069553.html
Sent from the Sling - Users mailing list archive at Nabble.com.


RE: How to change run mode in Sling8

2017-01-12 Thread lancedolan
This is fantastic information!

I'd love a nice clear how-to documentation for getting this done, but hey
it's open source stuff, hah. I'll go fumble through the
slingstart-maven-plugin and probably have a question or two along the way.

Thanks guys.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494p4069552.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Not-sticky sessions with Sling?

2017-01-12 Thread lancedolan
Chetan,

I'd like to confirm to what degree that is true for our proposed
architecture. It seems that only the OSGI configurations and bundles would
be "eventually consistent." It seems the only "state" that is stored in
Sling instances are OSGI configurations and OSGI bundles. Everything else is
in the JCR, which Mongo can provide as strongly consistent ( I believe ).
Consider this example and correct me where I'm wrong. I'd hate to shoot
myself in the foot with bad assumptions.

Imagine 3 Sling instances all talking to 1 Mongo instance. In this case, it
seems to me that all REPO state is captured in a single Mongo instance,
which is consistent by default and eventually consistency only happens if
you hit secondary members of a Mongo Replica Set. In an architecture with
only one Mongo instance, the moment one instance writes to the JCR, another
instance will read the same data and agree consistently. It seems to me that
the JCR state is strongly consistent. 

However, OSGI configurations seem to propagate to each other through the JCR
only eventually... Additionally, when we deploy a new OSGI bundle to the JCR
(in an install directory or whatever), then those seem to only eventually
propagate to all Sling instances. I'm not totally sure that these are
"eventually," but it seems like the only place that state will only be
"eventual" in this architecture.

So, as long as we're cool with OSGI configurations and bundle installations
being eventual, everything else, stored in the JCR, should be strongly
consistent right?

And then, I believe we can even scale the Mongo instances into a replica set
for better availability and we'll still be strongly consistent so long as
all Sling instances only read from the primary member of the replica set:
[1]. 

Thanks for your time and thoughts dude!

[1] https://www.mongodb.com/faq#consistency



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069551.html
Sent from the Sling - Users mailing list archive at Nabble.com.


RE: JS Use API usability or limitations

2017-01-12 Thread lancedolan
Aha. Thanks, I was sure it was sure weird Rhino thing. 

It's hard to call it valid JavaScript either, though, as it's invalid in
every single popular browser. That mozilla doc says "Non-standard. The
Iterator function is a SpiderMonkey-specific feature, and will be removed at
some point. " As a career JS developer, I simply wasn't going to know to use
this non-standard and widely unsupported function. On the other hand, using
other modern means, [1] and [2], of iterating the Iterable isn't supported
by Rhino .

I guess my point is just that the same syntax patterns a skilled JavaScript
developer would expect to use aren't always valid, which creates esoteric
knowledge for this environment. Whereas, I felt that all of my existing JS
knowledge was usable when I went to other server-side JS solutions, like
Node.js for example.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069550.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: How to change run mode in Sling8

2017-01-11 Thread lancedolan
Ok that makes sense. It sounds like developing a new codebase *based on* the
launchpad might be my next step. I guess the launchpad is really an example,
and not intended to be deployed to production as provided from the war
download link here: https://sling.apache.org/downloads.cgi.

I guess downloading and copying the source for the software I want to use
and just using that as the basis for my own custom version of that software
just feels like a bad development practice. Like, how do I upgrade to future
versions of Sling? By respecting the Sling war as a deployable artifact, I
could just swap in future version in our provisioning scripts. I feel like
there are other examples of how that's awkward as well, but it's late and
I'm getting foggy hah.

If the war file provided as a release isn't intended to be more than an
example, copying and modifying the source is the way Sling is intended to be
used by the developers, then fair enough.

This sounds like valuable information for beginning developers that find
https://sling.apache.org. It's easy to get lost.





--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494p4069533.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Not-sticky sessions with Sling?

2017-01-11 Thread lancedolan
The only example code I can find to authenticate to Sling will use the JEE
servlet container's "j_security_check" which then stores the authenticated
session in App Server memory. A load-balancer without sticky-sessions
enabled will cause an unstable experience for users, in which they are
suddenly unauthenticated.

-Does Sling already offer a mechanism for authenticating without storing
that JCR session in Servlet Container Session? 
-Do any of you avoid sticky sessions without writing custom code?

I'm thinking that this problem *must* be solved already. Either there's an
authenticationhandler in Sling that I haven't found yet, or there's an
open-source example that somebody could share with me :) 

If I must write this myself, is this the best place to start? 
https://sling.apache.org/documentation/the-sling-engine/authentication/authentication-authenticationhandler.html
https://sling.apache.org/apidocs/sling8/org/apache/sling/auth/core/spi/AuthenticationHandler.html

... as usual, thanks guys. I realize I'm really dominating the mail list
lately. I've got a lot to solve :)




--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: How to change run mode in Sling8

2017-01-11 Thread lancedolan
I can look into overriding init params through some servlet container
features. Is that the way that Sling devs expect me to turn on Mongo
functionality?



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494p4069529.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: How to change run mode in Sling8

2017-01-11 Thread lancedolan
Hmm, my genuine apologies, I'm not sure what custom application bits are. If
you're saying that I can deploy code that I write to Sling, that's
absolutely true, but my understanding is that I need to change the  runmode
BEFORE the Sling instance starts up for the very first time, and I can only
deploy my code to Sling OSGI AFTER the sling instance starts up for the very
first time.

I don't understand how to tell Sling to use oak_mongo instead of oako_tar.
Might only solution right now is to either unzip the war and change the
properties file before deploying for the first time, or to branch off the
Sling source code and rebuild with that property changed. Is this what the
Sling developers expect of me? It feels hacky. Isn't there a more
conventional way for me to control my runmodes?



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494p4069528.html
Sent from the Sling - Users mailing list archive at Nabble.com.


RE: JS Use API usability or limitations

2017-01-11 Thread lancedolan
No architectural reason - purely speed of development reasons. Our team has
switched from Java to Node.js on our other projects and are seeing real
gains in dev time. We believe we could see the same faster development with
lightweight JS files as opposed to traditional type-safe Java.

I think this is a popular opinion amongst developers, that JS is faster to
write in than Java? The question currently on the table is whether the
difficulty in debugging esoteric Rhino interactions will negate that speed,
in which case we might as well stick to Java and enjoy stability of type
safety. 



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069526.html
Sent from the Sling - Users mailing list archive at Nabble.com.


RE: JS Use API usability or limitations

2017-01-11 Thread lancedolan
Thank you for your time everybody! For posterity:

First to clarify, my very specific question is how to iterate an iterable in
the model-building logic (what us old timers might call a "backing bean"). I
do already know that I can use HTL to iterate the children, and I do
recognize that in this contrived example it's a better separation of
view/model concerns to do so. However I'm going to need to do lots of
iterating on resources in my "backing beans" as I build model data for
increasingly complex objects. Imagine a component that searches various
parts of the JCR and filters on specific properties to generate a
heterogenous list of content links... To suggest HTL just skirts around my
development need in model-building logic.

Vlad's syntax solved my problem. I'd love to understand why. It seems the
Iterable contains a Map or List objects with a key and resource... Is that
due to Rhino? The Sling docs say getChildren returns Iterable. I
didn't expect this.

I'm already feeling the pain of debugging JS Use API, which Stefan has
warned about, and so did the sling docs on.

I'm concluding that the JS Use API probably isn't ready and requires too
much esoteric/idiomatic knowledge to give the sort of development speed one
would expect with JS. I'm going to keep it as an option for very simple
components.






--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069521.html
Sent from the Sling - Users mailing list archive at Nabble.com.


How to change run mode in Sling8

2017-01-10 Thread lancedolan
I cannot change run mode using the process I have in the past, with Sling8.

The only thing that has worked for me was to crack open the
org.apache.sling.launchpad-8-webapp.war file, crack open the oak jar file
within it, edit sling_install.properties
(sling.run.mode.install.options=oak|oak_mongo), and then zip it all back up
again. This feels _wrong_ haha.

Things I tried, which failed:

-The Apache Sling Settings Service in OSGI console. It even says "The
settings service manages some basic settings of Sling like run modes."
However, there is no run mode config there.

-JVM arguments. I've tried -Dsling.run.mode.options=oak,oak_mongo and
-Dsling.run.modes=oak,oak_mongo. No luck.

-Searched for other configurations in the configMgr console.

How do I just tell a Sling instance to stop running oak_tar and start
running oak_mongo?



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Join new member to Sling Oak cluster?

2017-01-10 Thread lancedolan
- What kind of discovery mechanism do you use? 

I don't know - whichever is the default discovery mechanism when running
org.apache.sling.launchpad-8-webapp.war on Tomcat 8 and I've modified the
content of the war file so that it will start with run modes oak|oak_mongo,
so that by default it's looking for mongo on localhost.

- Are the Sling/Oak instances and MongoDB clocks in sync? 
I didn't realize this is important, but they must be as it's all in my local
machine. I'm not even using vagrant or virtual machines - just a buncha
stuff on local MacOS.

- Do you have anything suspicious in the error logs when the instances 
shut themselves down? 
See my reply above. Nothing very indicative, just the instance declaring
that the clusterview has changed and itself is no longer in it...

- What happens if after the instances are shut down and a new leader is 
elected you restart one of the old instances? 
Then they boot out the other other guy. They just take turns booting each
other out. To be specific, I had a sling instance on :8080 and another on
:8081, and they were connected to mongo localhost. Everything worked great
as I developed on them for a good 6 hours. Then I added and instance on
:8082 and when it connected to mongo localhost, tomcat 8080 and 8081 both
shut down, and the log file is just their mutual agreement that the new
clusterview doesn't include them. I immediately started 8080 and 8081 back
up again, and the same thing happened but in reverse, with 8082 shutting
itself down.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Join-new-member-to-Sling-Oak-cluster-tp4069454p4069493.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Join new member to Sling Oak cluster?

2017-01-10 Thread lancedolan
Not sure if I've experienced an intermittent but severe defect, or if I did
something wrong when attempting this yesterday.

I followed the exact same steps today, and the new instance *did*
successfully join. Either I'm wrong, and I actually did something
differently yesterday, or this is an intermittent defect and a big bummer.
I'll keep trying to reproduce. 

Here is the log output from one of the instances that was already in the
cluster when the new one joined:

**
09.01.2017 16:20:36.062 *INFO*
[DocumentDiscoveryLiteService-BackgroundWorker-[1]]
org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
doCheckView: view has changed from: a ClusterView[valid=true, viewSeqNum=2,
clusterViewId=ae406105-3c77-4498-b8fc-1557b012d46d, activeIds=1,2,
recoveringIds=null, inactiveIds=null] to: a ClusterView[valid=true,
viewSeqNum=3, clusterViewId=ae406105-3c77-4498-b8fc-1557b012d46d,
activeIds=1, recoveringIds=null, inactiveIds=2] - sending event...
09.01.2017 16:20:36.063 *INFO*
[DocumentDiscoveryLiteService-BackgroundWorker-[1]]
org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
checkView: view changed from: a
ClusterView[{"seq":2,"final":true,"id":"ae406105-3c77-4498-b8fc-1557b012d46d","me":1,"active":[1,2],"deactivating":[],"inactive":[]}],
to: a
ClusterView[{"seq":3,"final":false,"id":"ae406105-3c77-4498-b8fc-1557b012d46d","me":1,"active":[1],"deactivating":[2],"inactive":[]}],
hasInstancesWithBacklog: true
09.01.2017 16:20:37.168 *INFO* [Thread-31]
org.apache.sling.discovery.impl.DiscoveryServiceImpl enqueueForAll: sending
PROPERTIES_CHANGED to all listeners (oldView=TopologyViewImpl
[current=false, super.hashCode=1259039663, instances=[an
InstanceDescription[slindId=3d4f31d9-b3ba-4e32-aa10-36ef150a37f0,
isLeader=true, isOwn=true,
clusterViewId=20a0797b-e957-4b8e-845b-9b9e0b6a246d,
properties={org.apache.sling.instance.endpoints=,
org.apache.sling.event.jobs.consumer.topics=/,com/composum/sling/core/pckgmgr/PackageJobExecutor,com/composum/sling/core/script/GroovyJobExecutor,org/apache/sling/event/impl/jobs/tasks/HistoryCleanUpTask,sling/webconsole/test,
org.apache.sling.instance.name=Instance
3d4f31d9-b3ba-4e32-aa10-36ef150a37f0,
org.apache.sling.instance.description=Instance with id
3d4f31d9-b3ba-4e32-aa10-36ef150a37f0 and run modes [oak_mongo, oak]}], an
InstanceDescription[slindId=cc9e3513-8f6c-460d-b27e-dd3844aa629d,
isLeader=false, isOwn=false,
clusterViewId=20a0797b-e957-4b8e-845b-9b9e0b6a246d,
properties={org.apache.sling.instance.endpoints=,
org.apache.sling.event.jobs.consumer.topics=/,com/composum/sling/core/pckgmgr/PackageJobExecutor,com/composum/sling/core/script/GroovyJobExecutor,org/apache/sling/event/impl/jobs/tasks/HistoryCleanUpTask,sling/webconsole/test,
org.apache.sling.instance.name=Instance
cc9e3513-8f6c-460d-b27e-dd3844aa629d,
org.apache.sling.instance.description=Instance with id
cc9e3513-8f6c-460d-b27e-dd3844aa629d and run modes [oak_mongo, oak]}]]],
newView=TopologyViewImpl [current=true, super.hashCode=238080023,
instances=[an
InstanceDescription[slindId=3d4f31d9-b3ba-4e32-aa10-36ef150a37f0,
isLeader=true, isOwn=true,
clusterViewId=20a0797b-e957-4b8e-845b-9b9e0b6a246d,
properties={org.apache.sling.instance.endpoints=,
org.apache.sling.event.jobs.consumer.topics=/,com/composum/sling/core/pckgmgr/PackageJobExecutor,com/composum/sling/core/script/GroovyJobExecutor,org/apache/sling/event/impl/jobs/tasks/HistoryCleanUpTask,sling/webconsole/test,
org.apache.sling.instance.name=Instance
3d4f31d9-b3ba-4e32-aa10-36ef150a37f0,
org.apache.sling.instance.description=Instance with id
3d4f31d9-b3ba-4e32-aa10-36ef150a37f0 and run modes [oak_mongo, oak]}], an
InstanceDescription[slindId=cc9e3513-8f6c-460d-b27e-dd3844aa629d,
isLeader=false, isOwn=false,
clusterViewId=20a0797b-e957-4b8e-845b-9b9e0b6a246d,
properties={org.apache.sling.instance.endpoints=,
org.apache.sling.event.jobs.consumer.topics=/,org/apache/sling/event/impl/jobs/tasks/HistoryCleanUpTask,sling/webconsole/test,
org.apache.sling.instance.name=Instance
cc9e3513-8f6c-460d-b27e-dd3844aa629d,
org.apache.sling.instance.description=Instance with id
cc9e3513-8f6c-460d-b27e-dd3844aa629d and run modes [oak_mongo, oak]}]]]).
09.01.2017 16:20:37.171 *INFO*
[DocumentDiscoveryLiteService-BackgroundWorker-[1]]
org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
checkView: view changed from: a
ClusterView[{"seq":3,"final":false,"id":"ae406105-3c77-4498-b8fc-1557b012d46d","me":1,"active":[1],"deactivating":[2],"inactive":[]}],
to: a
ClusterView[{"seq":3,"final":true,"id":"ae406105-3c77-4498-b8fc-1557b012d46d","me":1,"active":[1],"deactivating":[],"inactive":[2]}],
hasInstancesWithBacklog: false 
***
 From there onward, the log file is just the normal shut-down logs as OSGI
unregisters bundles and the servlet container shuts down.



--
View this message in context: 

JS Use API usability or limitations

2017-01-10 Thread lancedolan
I've got years of experience writing backing beans for Sling (aem)
components, but can't seem to get a simple JS backing working using the new
Javascript Use API.

All I want to do is print out a resource's children resources.

My JS backing bean:

use([], function () {
 
 var returnObj = {
content: ""
};

  var parent = resource.parent;
  var children = parent.getChildren();

  for (res in Iterator(children)) {
   returnObj.content += res.name;
  }
   
return returnObj;
});

The contents of returnObj.content will be the word "undefined" repeated X
times, where X is the number of children nodes of parent. This tells me it
successfully iterates the Iterable once for each item in it, but it's
failing to give me a reference to a child. If I try res.getName() instead, I
get:

org.mozilla.javascript.EcmaError: TypeError: Cannot find default value for
object

In fact, every single variation I've tried for iterating that collection has
lead to that exact Exception.

It seems to me Rhino is getting in the way. Am I right? What is the
community consensus on use of the JS Use API? Is it production-ready and
stable? Is my problem a user-error? What limitations exist here? I was
planning on doing the same things in JS that I've always done in Java, which
is usually a lot of read/write operations on the JCR.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490.html
Sent from the Sling - Users mailing list archive at Nabble.com.


RE: Sling 8 Resource Versioning? Jira access?

2017-01-10 Thread lancedolan
Ahh, yes you're right. I was getting a 403 apparently because of an old bad
Chrome Plugin that was injecting Basic Auth headers into my request... my
fault.





--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Sling-8-Resource-Versioning-Jira-access-tp4069484p4069486.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Sling 8 Resource Versioning? Jira access?

2017-01-10 Thread lancedolan
The announcement for sling 8 announces a feature we're excited to use:
Versioning through the Resource API:

https://sling.apache.org/news/sling-launchpad-8-released.html#versioning-support-in-the-resource-api

However, the only info it provides is a JIRA link I can't access:
https://issues.apache.org/jira/browse/SLING-848

My questions:
1) How can I get access to Jira to see this?
2) Can we get put this information somewhere outside of JIRA, such as
sling.apache.org or https://cwiki.apache.org/confluence/display/SLING ? (My
apologies if it actually is out there somewhere, I've searched with no luck)



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Sling-8-Resource-Versioning-Jira-access-tp4069484.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Join new member to Sling Oak cluster?

2017-01-09 Thread lancedolan
Hey guys, sorry for multiple recent question. I'm biting down hard on Sling
right now and hitting tons of learning curve and growing pains.

My problem: If I create a fresh instance of MongoDB, and connect multiple
fresh instances of Sling to it (each running in a separate tomcat instance),
they all plug-and-play happily. They just discover each other and my
clusterview is very stable at /system/console/topology.

However, if I used the cluster for a while (deploy some OSGI bundles, create
some JCR content) and *then* connect a new sling instance, what happens is
that all of the current instances shut down (they literally send a shut down
signal to tomcat's shut down port) and then the single new instance votes
itself as the new leader, and only member, of a new 1-instance cluster.

Is this a known issue? Do I need to "prime" my new member with the current
state of the cluster before connecting it to the cluster or something
(perhaps by uploading all the bundles and content that has been uploaded to
the cluster?)



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Join-new-member-to-Sling-Oak-cluster-tp4069454.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Re: Multiple Version of Commons Lang in OSGI...

2017-01-09 Thread lancedolan
Gah - solved myself almost immediately after posting.

For posterity: version 3.5 of commons lang has a different
Bundle-SymbolicName ( org.apache.commons.lang3) in the OSGI metadata of
MINFEST.MF. Simply by bumping to lang 3.5 you'll solve this.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Multiple-Version-of-Commons-Lang-in-OSGI-tp4069450p4069452.html
Sent from the Sling - Users mailing list archive at Nabble.com.


Multiple Version of Commons Lang in OSGI...

2017-01-09 Thread lancedolan
I have packages (such as composum tools) that depend on apache commons lang
3.

I have other packages (such as most of the sling itself) that depend on
commons lang version 2.

There are no Java Package namespacing collisions between these packages -
they can both exist in the same JVM safely. Version 3 uses
"org.apache.commons.lang3.*" package. I should be able to install both of
these packages.

However, possibly because they have the same artifact ID or something,
installing version 3 overwrites version 2, meaning I can't have both, and
thus can't run both the core sling packages and the composum tools. This is
a deal breaker right now for my Sling P.O.C. project.

To be clear, the actual commons lang jar version 2 jar file, which is stored
at /sling/felix/bundle71/version0.0, is deleted and and the version 3 jar
file is stored at /sling/felix/bundle71/version0.1.

The only solution I can imagine is to modify the commons-lang bundle with a
custom artifact ID so that Sling won't consider them the same artifact. That
would be a hack and cause issues later on.

I'm positive somebody else has solved this issue? Google search yields
nothing.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Multiple-Version-of-Commons-Lang-in-OSGI-tp4069450.html
Sent from the Sling - Users mailing list archive at Nabble.com.