Alfresco discussion and collaboration. Stick around a few hours after asking a question.
Official support for Enterprise subscribers: support.alfresco.com.
Join in the conversation by getting an IRC client and connecting to #alfresco at Freenode. Our you can use the IRC web chat.
More information about the channel is in the wiki.
More help is available in this list of resources.
2019-01-09 05:02:09 GMT *** onu_ is now known as onu
2019-01-09 08:44:36 GMT *** angelborroy_ is now known as angelborroy
2019-01-09 09:48:01 GMT <AFaust> angelborroy: Regarding our discussions last year about there potentially not being a Community GA for 6.1 - I just saw a JIRA ticket being assigned the Fix Version for Community Edition 201901 GA...
2019-01-09 09:55:31 GMT <angelborroy> As yreg said, I’m missing (a lot) Jeff, Richard and all the people that made this product open
2019-01-09 09:56:35 GMT <angelborroy> AFaust Additionally, since Francesco switched position, Community is alone
2019-01-09 09:57:03 GMT <angelborroy> Probably we (as OOTB) can talk about this in Scotland
2019-01-09 09:57:25 GMT <AFaust> Well, I thought Ole was transitioning back into that role.
2019-01-09 09:57:35 GMT <angelborroy> When OOTB was born, Community was in risk, but IMO nowadays Community is in a higher risk
2019-01-09 09:57:44 GMT <angelborroy> Ole is now Product Evangelist
2019-01-09 09:57:58 GMT <AFaust> So slightly different, still evangelist, just not dev...
2019-01-09 09:58:00 GMT <angelborroy> But he is not active in any Communicy channel
2019-01-09 09:58:44 GMT <angelborroy> So we have no idea of what Alfresco is working on
2019-01-09 09:58:55 GMT <AFaust> Well... I am all for talking about stuff in the OOTBee... but at the end of the day, something specific would actually have to be done, and we don't have a great track record in that regard, apart from BeeCon...
2019-01-09 09:59:21 GMT <alfresco-discord> <yreg> agreed
2019-01-09 09:59:27 GMT <angelborroy> agreed
2019-01-09 10:00:01 GMT <angelborroy> I don’t know about other groups, but in the last 6-8 months interest in Alfresco has decreased a lot in Spanish
2019-01-09 10:00:31 GMT <angelborroy> Newbies just simply don’t know how to install and use the product
2019-01-09 10:00:56 GMT <angelborroy> Developers think that Alfresco is a Cloud Service
2019-01-09 10:01:38 GMT <angelborroy> And I wonder if all this chaos is intentionally orchested by Alfresco or if this is simply a product of a huge amount of work for Alfresco employees
2019-01-09 10:02:11 GMT <angelborroy> Probably is the second, they have about 20+ open positions
2019-01-09 10:03:55 GMT <AFaust> Well... if I look at some of the questions I have seen of new people trying to install Alfresco, those people did not do their homework in actually reading docs or knowing IT basics in the first place. I had someone ask "I want to install Alfresco on my NAS, I can't find any step-by-step guides for this specific guides for this particular scenario and how dare Alfresco documentation require me to know anything about Linux / Tomcat
2019-01-09 10:03:55 GMT <AFaust> to follow their manual installation documentation"
2019-01-09 10:04:07 GMT <alfresco-discord> <yreg> angelborroy in engineering ? I thought most of these positions were sales/technical presales/Crisis management/support
2019-01-09 10:06:45 GMT <AFaust> angelborroy: And with regards to "intentionally orchestrated" I still stand by the "incompetence" rather than "malice" argument...
2019-01-09 10:07:07 GMT <angelborroy> +1
2019-01-09 10:07:30 GMT <angelborroy> I prefer to think that it’s not “incompetence” but lack of time
2019-01-09 10:07:57 GMT <AFaust> I mean, they lost quite a lot of prreviously critical people (critical in transparency / engagement), in a lot of areas. And it is hard to find decent / good new people to replace them....
2019-01-09 10:09:03 GMT <angelborroy> Anyway we can make our little effort during Hack-a-thon
2019-01-09 10:09:15 GMT <angelborroy> Just to make Community more accesible for the people
2019-01-09 10:09:21 GMT <AFaust> And they relied too long on their people having the personal motivation / drive to engage, instead of making it part of their institutional DNA. So of course it is also hard to find replacements internally since existing people have never been ingrained too much with the necessary mentality
2019-01-09 10:17:48 GMT <hi-ko> here in Germany we also see that Alfresco is losing importance / visibility. Since ~ 2 yrs new biz is migration from Alfresco
2019-01-09 10:20:24 GMT <hi-ko> My personal perception is that Alfresco forgot to care about real use cases and gets lost in technical details
2019-01-09 10:21:05 GMT <angelborroy> This is specially true for Activiti
2019-01-09 10:21:21 GMT <angelborroy> The product is practically dissapeared in Spain
2019-01-09 10:21:41 GMT <hi-ko> For all subjects discussed in the last 2 years.
2019-01-09 10:22:37 GMT <AFaust> Well, biz may now be responding to this, but Alfresco has been ignoring real use cases and got lost in tech for at least 4-5 years.
2019-01-09 10:23:51 GMT <angelborroy> But at least it was a (real) open source product, so integrators could adapt the product to this real use cases
2019-01-09 10:24:11 GMT <hi-ko> but still is still the case!
2019-01-09 10:26:21 GMT <hi-ko> OK - there never was a real working community in terms of open source but show me any commercial OpenSource solution having a working Community
2019-01-09 10:30:17 GMT <hi-ko> If we want to create a working community we need a shared goal.
2019-01-09 10:32:16 GMT <hi-ko> One could be to provide an easy and mature entry level for installation and build up a community around supporting that stack.
2019-01-09 10:33:03 GMT <hi-ko> the community should have an idea who will pay the bill of everyone's time
2019-01-09 10:34:33 GMT <hi-ko> Another aproach would be to focus on implementing real use cases.
2019-01-09 10:36:39 GMT <alfresco-discord> <bhagyas> a simple solution is to boycott the hackathon and fix bugs instead
2019-01-09 10:37:00 GMT <alfresco-discord> <bhagyas> but people like doing cool stuff, instead of focusing on what matters 😃
2019-01-09 10:37:41 GMT <hi-ko> I suggest we stop glumbling on Alfresco and spent the time and energy in doing things better, so bhagyas +1 for fixing bugs
2019-01-09 10:38:09 GMT <alfresco-discord> <bhagyas> when you announce certain bugs are fixed at the devcon, the pressure is high on them to actually merge it
2019-01-09 10:38:33 GMT <alfresco-discord> <Loftux> Bug fixing hasn't been spent time on since they rarely have been accepted. Not sure if it has improved since move to github
2019-01-09 10:39:02 GMT <hi-ko> if we go that road we need an open repo (fork).
2019-01-09 10:40:46 GMT <hi-ko> our best practice is clone every late or final release and to work on that until the next major release is published
2019-01-09 10:41:38 GMT <hi-ko> we would be happy to work on a common repo instead of on our own fork.
2019-01-09 10:43:49 GMT <alfresco-discord> <Loftux> https://blog.documentfoundation.org/blog/2018/12/17/coming-up-on-december-21-bug-hunting-session-for-libreoffice-6-2-rc-1/ LibreOffice hold regular bug hunting sessions
2019-01-09 10:43:51 GMT <alfbot> Title:Coming up on December 21: Bug Hunting Session for LibreOffice 6.2 RC 1 - The Document Foundation Blog (at blog.documentfoundation.org)
2019-01-09 10:44:02 GMT <alfresco-discord> <yreg> @Loftux it has, I speak from experience
2019-01-09 10:44:47 GMT <alfresco-discord> <yreg> but I guess it was so late that everybody had already lost faith
2019-01-09 10:45:19 GMT <hi-ko> loftux: I didn't get your point
2019-01-09 10:45:41 GMT <alfresco-discord> <yreg> for me, I guess I made a couple of pull requests, and it took less than two weeks to get them merged, and less then one week to get them reviewed/looked at
2019-01-09 10:46:25 GMT <alfresco-discord> <Loftux> @hi-ko Just an example of how a Community can do a session on bug fixing instead of adding features/modules
2019-01-09 10:46:52 GMT <hi-ko> yreg: libreoffice is a user founded community - you can't compare this with the commercial alfresco model
2019-01-09 10:46:59 GMT <alfresco-discord> <Loftux> Not sure if it is a good example and how well it works for them
2019-01-09 10:47:27 GMT <hi-ko> Loftux: It's up on us to create that kind of community if we are brave enough
2019-01-09 10:48:31 GMT <alfresco-discord> <yreg> hi-ko not sure what you are talking about, was talkin about alfresco repos not libreoffice
2019-01-09 10:50:32 GMT <hi-ko> yreg: sorry - this answer was meant for loftux and bhagyas
2019-01-09 10:50:42 GMT <alfresco-discord> <yreg> ah ok
2019-01-09 10:52:20 GMT <hi-ko> from my stay in the US I learned their way of thinking: stop blaming for things you expect to be changed, optimized. Do it. Love it or leave it but don't suffer it.
2019-01-09 10:53:14 GMT <alfresco-discord> <yreg> +1
2019-01-09 10:56:09 GMT <hi-ko> so again: what about a community fork based on 6.1 we share our forces in fixing and enhance things until version 7 comes around the corner?
2019-01-09 10:57:32 GMT <alfresco-discord> <bhagyas> One interesting fork is citek ecos
2019-01-09 10:57:40 GMT <alfresco-discord> <bhagyas> they have commits every day making things better
2019-01-09 11:02:28 GMT <alfresco-discord> <yreg> @hi-ko if alfresco is now more than ever open to contributions, and the process does actually work on github, why fork ?
2019-01-09 11:03:35 GMT <hi-ko> yreg: Maybe I missed something but since when is alfresco open to accept pull requests, patches?
2019-01-09 11:03:39 GMT <alfresco-discord> <yreg> How many PRs you had rejected to any of the alfresco-platform repos you had rejected for the last 365 days without proper plausible explanation ?
2019-01-09 11:03:57 GMT <alfresco-discord> <yreg> how many other PRs took more than a month to be reviewed ?
2019-01-09 11:04:49 GMT <alfresco-discord> <yreg> @hi-ko since the fully broke down CE into multiple git repos and fully moved them to git
2019-01-09 11:05:35 GMT <angelborroy> I was trying to correct a simple failure in an Spanish resource…
2019-01-09 11:05:46 GMT <angelborroy> … and I didn’t find the repo to commit
2019-01-09 11:05:53 GMT <angelborroy> Finally, it was open as an issue
2019-01-09 11:09:44 GMT <hi-ko> @yreg we have to try this out. Of course there is no reason to fork if this process is working.
2019-01-09 11:17:58 GMT <AFaust> yreg: One thing that bugs me about the whole contribution via PR approach is that the speed of acceptance mostly depends on how well the existing test framework actually performs.
2019-01-09 11:18:23 GMT <AFaust> On a recent PR of mine to the alfresco-remote-api project, I couldn't even get their base tests to run successfully locally, so had to submit the changes blind.
2019-01-09 11:19:07 GMT <alfresco-discord> <yreg> hi-ko if you don't try it you will never know 😃
2019-01-09 11:19:10 GMT <AFaust> Of course something broke (my code reorg actually uncovered another bug hidden due to lack of coverage), but that could only be found / verified by messing with the Travis CI build via temporary commits
2019-01-09 11:20:20 GMT <alfresco-discord> <yreg> AFaust agreed, I would also add that patches/fixes addressing different components can be a bit tricky ....
2019-01-09 11:20:37 GMT <alfresco-discord> <yreg> but still manageable IMHO
2019-01-09 11:20:59 GMT <AFaust> What I am doubtful about with the GitHub + distributed repo model is the non-trivial changes, e.g. where you have PRs against 3 repos for one feature...
2019-01-09 11:22:23 GMT <hi-ko> yreg: to comments to the contribution process: since a PR has to be done from a fork anyway why not working on a shared fork not to be stucked in the alfresco process which may take months.
2019-01-09 11:24:38 GMT <yreg> Did you actually read me, I only attempted issuing PRs twice
2019-01-09 11:24:51 GMT <yreg> Both of them got reviewed in less than a month
2019-01-09 11:25:12 GMT <yreg> actually less than a week
2019-01-09 11:25:22 GMT <yreg> And both of them got merged in less than 2 weeks
2019-01-09 11:25:35 GMT <hi-ko> I've read that, but I also have my experience in changes which Alfresco didn't want to follow but which our customers wanted to be fixed
2019-01-09 11:26:11 GMT <yreg> That would be a different issue and a different discussion theme
2019-01-09 11:26:14 GMT <hi-ko> and lots of jirea issues open since years - even wiht patch
2019-01-09 11:26:44 GMT <yreg> Can't blame them for closing 2+ year old jiras
2019-01-09 11:27:35 GMT <hi-ko> So my suggestion would be similar but in reverse: we fix things in a fork an offer these fixes as PR but rely on the fork.
2019-01-09 11:27:35 GMT <yreg> And I am pretty sure that issues which come with patches/PRs would be triaged/addressed faster
2019-01-09 11:28:07 GMT <yreg> And TBH I did file an issue a while back just to test out how Alfresco does with community raised tickets
2019-01-09 11:28:31 GMT <yreg> And I intentionally kept it out of the circle of light with Alfresco Support ...
2019-01-09 11:28:42 GMT <yreg> And it was just closed today as fixed
2019-01-09 11:29:04 GMT <yreg> It was fixed in upstream for a few weeks already though
2019-01-09 11:29:41 GMT <yreg> And for reference I haven't even contributed a patch for it
2019-01-09 11:30:49 GMT <yreg> For reference : the issue was created on Sept 4th https://issues.alfresco.com/jira/browse/ALF-22031 for more info
2019-01-09 11:30:52 GMT <hi-ko> so as AFaust mentioned: what we need anyway is a build and test envrionment the community could rely on.
2019-01-09 11:31:04 GMT <yreg> Sept 4th 2018 to be precise
2019-01-09 11:31:17 GMT <alfresco-discord> <douglascrp> @hi-ko I like the shared repo idea
2019-01-09 11:31:28 GMT <yreg> I find that acceptable for a community raised ticket to be honest
2019-01-09 11:32:23 GMT <yreg> We had something like that which mars bard and digcat crafted on the OOTBee server using Jenkins Artifactory .....
2019-01-09 11:32:44 GMT <yreg> But I guess they lost interest in it since no body was using it
2019-01-09 11:33:17 GMT <AFaust> yreg: You seem to be one lucky son of a gun... Check my ALF-22021 to 22029 which are just as old as your 22031. Not even a basic reaction on any of them...
2019-01-09 11:33:26 GMT <alfresco-discord> <douglascrp> that would be a nice project for the hackathon, and having all of us working on this together, trying to organize it and show alfresco
2019-01-09 11:33:27 GMT <yreg> If you want to revive that back, be my guess, I can provide credentials for you to access infra and even contribute to the process with you
2019-01-09 11:33:42 GMT <alfresco-discord> <douglascrp> just like @bhagyas said, forget about new things
2019-01-09 11:34:13 GMT <yreg> *be my guest
2019-01-09 11:36:00 GMT <angelborroy> I sent 3 months ago this issue to support...
2019-01-09 11:36:01 GMT <angelborroy> https://pastebin.com/uJpBrnQy
2019-01-09 11:36:02 GMT <alfbot> Title:We are developing custom search interfaces in Alfresco Share and we found follow - Pastebin.com (at pastebin.com)
2019-01-09 11:36:26 GMT <angelborroy> Just a simple “wget” to reproduce the issue
2019-01-09 11:36:53 GMT <angelborroy> They are still investigating if “cm:versionLabel” is an Alfresco ootb property or if it is a custom property
2019-01-09 11:37:14 GMT <AFaust> With regards to automated, server-side build, I don't think we should have to actually run something on our infra. Travis CI seems fine to me. What I would like to see, is not being reliant on build "only" working in Travis CI, so if I check something out to local, it should work fine (with only basic requirements, i.e. having Docker engine)
2019-01-09 11:37:51 GMT <AFaust> angelborroy: What? They are investigating if a "cm:" property is Alfresco ootb or not?
2019-01-09 11:38:01 GMT <yreg> AFaust, or maybe Alfresco engineers just get afraid when they come across an issue crafted in iron and steel by the almighty AFaust .....
2019-01-09 11:38:35 GMT <AFaust> That reminds me of a response my customer got from Support yesterday, where the Support guy was wondering, why not cleaning up a Thread-local could be a bad thing, because "each request is handled in a new thread anyway, right?"
2019-01-09 11:38:38 GMT <angelborroy> Yes, the asked me if “cm:versionLabel” was from our custom content model
2019-01-09 11:39:04 GMT <angelborroy> wow
2019-01-09 11:39:16 GMT <angelborroy> You win :D
2019-01-09 11:39:41 GMT <AFaust> That was the issue I mentioned on Twitter last week and already sent to Mario via email (along with the Servlet Filter to fix it)
2019-01-09 11:40:22 GMT <angelborroy> I don’t know why first-level support guys does not pass issues they don’t understand to engineers
2019-01-09 11:40:56 GMT <AFaust> Those guys should not be working in first-level anyway - they are more like zero or minus one level...
2019-01-09 11:40:57 GMT <angelborroy> btw, the guy that asked me about versionLabel is working in Alfresco Support for (at least) 5 years
2019-01-09 11:41:58 GMT <angelborroy> This is why I’m not so confident on PRs on publig Github repos
2019-01-09 11:42:17 GMT <AFaust> Well... the PRs on public GitHub repos are handled by the actual engineers...
2019-01-09 11:42:21 GMT <angelborroy> If we start to raise this kind of request...
2019-01-09 11:42:23 GMT <AFaust> I had Derek involved on mine...
2019-01-09 11:42:29 GMT <angelborroy> … yes, this is what I was thinking
2019-01-09 11:42:43 GMT <angelborroy> It we start to create more, they will assign a team to handle them
2019-01-09 11:42:57 GMT <angelborroy> And the whole system will fail again
2019-01-09 11:43:07 GMT <AFaust> I would say that would depend on the quality of PRs we create...
2019-01-09 11:43:22 GMT <angelborroy> The quality and the cuantity
2019-01-09 11:43:24 GMT <AFaust> If there are too many bad ones that take them too much time to process, then definitely that is a risk
2019-01-09 11:52:02 GMT <hi-ko> My minimal expectation from the community would be to have a working build environment creating nightly builds and to have a repo to check in fixes and enhancements.
2019-01-09 11:52:52 GMT <hi-ko> This could be reviewed and quality checked before creating PRs to Alfresco
2019-01-09 11:56:33 GMT <AFaust> Well... I would assume that we would have a PR process for our "fork" as well, where we quality check changes before they are part of our develop/master branch and included in nightly builds... Or would we just hack away on the live state?
2019-01-09 11:57:15 GMT <hi-ko> sure :-)
2019-01-09 11:57:43 GMT <hi-ko> but this is a process we could control
2019-01-09 12:02:15 GMT <hi-ko> there should be a (rotating) team which takes care about this process
2019-01-09 12:11:52 GMT <AFaust> With rotating you mean in terms of the time window when a sub-set of the involved community members would be responsible to review PRs / issues. Not rotating in terms of the forcing the change of the involved community members..
2019-01-09 12:13:44 GMT <AFaust> As much as I would like a "all people are responsible and should act as soon as possible if they see a notification", that has so far failed to work on ootbee-support-tools, so probably assigning / rotating explicit times of responsibility may be the only viable way for people to commit to actually doing the work.
2019-01-09 12:16:51 GMT <yreg> That's all premature talk IMHO
2019-01-09 12:17:26 GMT <yreg> When there is more PRs than what Alfresco could handle in a reasonable amount of time, we can think of ways to have community do the initial review
2019-01-09 12:18:09 GMT <yreg> Which could as well involve labelling PRs and have the comminity give its 2cents in comments for instance
2019-01-09 12:18:49 GMT <yreg> I am really not in favor of this "fork" thingy... I find it too much of a burden and should be avoided unless really crucial !
2019-01-09 12:19:26 GMT <AFaust> So you are saying we should stick to the Alfresco repos only and their (not always usable) build / test process for the time being, and focus on becoming involved somehow in their GitHub process? Just so I get it right at which point you are drawing the line of "premature talk"...
2019-01-09 12:19:41 GMT <Tichodroma> what about the working build enviroment? I'd hate to open a PR for code I can not test
2019-01-09 12:19:46 GMT <AFaust> Ok - just answered that question while I was typiing..
2019-01-09 12:20:03 GMT <angelborroy> IMHO Alfresco is moving to a different business model which does not include Community
2019-01-09 12:20:16 GMT <angelborroy> So probably it’s worthless to start such initiative
2019-01-09 12:21:04 GMT <angelborroy> But I prefer to understand the point of view of the company in Scotland
2019-01-09 12:21:23 GMT <alfresco-discord> <bhagyas> We should stop thinking about business models altogether and consider it as just like any open source software - let Alfresco, Inc. handle the business models
2019-01-09 12:22:18 GMT <alfresco-discord> <bhagyas> If they want to close it, let them - but it's our duty to maintain a better version in public
2019-01-09 12:22:29 GMT <angelborroy> If the model does not include an Open Source Policy…
2019-01-09 12:22:38 GMT <hi-ko> pooled responsibility is a concept which never worked ;-) Yes - I mean a rotating team responsible checking/reviewing commits
2019-01-09 12:22:45 GMT <angelborroy> … it will be (almost) impossible to maintain a public version
2019-01-09 12:23:03 GMT <yreg> AFaust, If tests are not working, or only work if you are behind company firewalls/with access to some internal bits and pieces, then our effort should target making those tests workable on official repos
2019-01-09 12:23:13 GMT <yreg> Either by contribution or lobbying
2019-01-09 12:23:15 GMT <alfresco-discord> <bhagyas> So, if we can all agree to stop building new things without fixing the old, we might be able to go a longer journey with Alfresco together
2019-01-09 12:23:20 GMT <alfresco-discord> <bhagyas> 😃
2019-01-09 12:24:05 GMT <alfresco-discord> <bhagyas> Leave building cooler stuff to marketing
2019-01-09 12:24:09 GMT <AFaust> yreg: Changing the Alfresco build process / POMs? Huh... I expect that to be one of the most difficult challenges in potential PRs...
2019-01-09 12:24:43 GMT <yreg> Have you tried ?
2019-01-09 12:24:47 GMT <Tichodroma> has anybody of you been able to build the current released versions locally? Up until 5.2.x this was possible, do you have experience wiht 6+? Because without this, it will be very hard to contribute anything, let alone maintain a fork
2019-01-09 12:24:50 GMT <yreg> Never judge a book by the cover
2019-01-09 12:25:45 GMT <yreg> At some point I tried, but was blocked by a missing dependency which turned out to be retracted from CE and moved away to EE only feature
2019-01-09 12:25:52 GMT <Tichodroma> :(
2019-01-09 12:25:59 GMT <AFaust> Also, I don't believe the root POM is even available in a public GitHub repository. It may only be published on artifacts.alfresco.com / Maven Central...
2019-01-09 12:26:03 GMT <yreg> Haven't tried after it was removed from the POM
2019-01-09 12:26:11 GMT <Tichodroma> ?!
2019-01-09 12:26:28 GMT <yreg> I mean the missing non public dependency
2019-01-09 12:55:25 GMT <AFaust> As to the idea of a "bug hunt" session during hack-a-thon, how would we make sure this can be done in a productive manner? Considering the test issue and effort going into creating a decent PR. I'd hate to end up only managing to deal with 2 or 3 issues at most because it took too much time running tests / waiting on Travis CI to run the tests as part of the PR build...
2019-01-09 12:57:49 GMT <AFaust> And I believe Alfresco has only a limited number of CPUs for their Travis CI account. Since each PR may run multiple test suites in parallel, having multiple people file PRs on that day could overload the available resources and increase wait time...
2019-01-09 13:09:57 GMT <hi-ko> totally different question: Does anybody know if it is possible to ignore the db stored enterprise config? a custers old ee system isn't starting with wired config complaints which don't fit with the alfresco-global properties.
2019-01-09 13:13:00 GMT <AFaust> Nope... you'd have to do a Spring override to disable / remove the Enterprise bean responsible for reading that DB config - and I don't know for sure if that is even possible cleanly without patching some Enterprise code...
2019-01-09 13:13:51 GMT <AFaust> Oh - I read custers and assumed it meant "clusters" not "customers"
2019-01-09 13:14:31 GMT <AFaust> Well... depending on which component / subsystem is affected, can't you configure that subsystem to be disabled, then use JMX reset, and then reenable?
2019-01-09 13:16:05 GMT <AFaust> I am actually wondering which stored config could even result in startup being disrupted... Only thing I can think of is search subsystem, where I recently had an issue with Lucene being incorrectly activated and causing a startup issue due to failing index validation...
2019-01-09 13:16:06 GMT <hi-ko> it complaints starting the search subsystem and shuts down
2019-01-09 13:16:57 GMT <hi-ko> in alfresco-global I already set index.subsystem.name=noindex
2019-01-09 13:16:57 GMT <hi-ko> but no luck
2019-01-09 13:17:12 GMT <AFaust> Problem is that subsystem name config can also be persisted in the DB via JMX
2019-01-09 13:17:52 GMT <hi-ko> So this needs to be fixed in the attribute store tables?
2019-01-09 13:17:57 GMT <AFaust> I had solved my issue by going into DB and deleting the alf_prop_unique_ctx entries relating to the JMX config which (implicitly) activated Lucene
2019-01-09 13:19:06 GMT <AFaust> As it turned out, if you have at least one persisted Lucene config property, the Lucene subsystem will be implicitly started even though not activated nor used...
2019-01-09 13:19:39 GMT <AFaust> That is a side-effect of the JMX persistence layer. I encountered that same side effect when testing the ootbee-support-tools persisted configuration feature
2019-01-09 13:20:34 GMT <AFaust> e.g. https://github.com/OrderOfTheBee/ootbee-support-tools/issues/132
2019-01-09 13:20:36 GMT <alfbot> Title:Startup error in 5.0.d configured w/o Lucene with new subsystem persister · Issue #132 · OrderOfTheBee/ootbee-support-tools · GitHub (at github.com)
2019-01-09 13:20:48 GMT <AFaust> Still have to find a way to prevent that implicit startup without patching Alfresco...
2019-01-09 14:36:50 GMT <hi-ko> AFaust: how are the alf_prop_values related? alf_prop_unique_ctx references alf_prop_value in column prop1_id and may have up to 3 values?
2019-01-09 14:39:08 GMT <AFaust> value1_prop through value3_prop are actually the "keys" for the entry (the AttributeService allows up to 3 key values) and the prop_value reference the value for the config
2019-01-09 14:39:20 GMT <AFaust> sorry, the prop1_id
2019-01-09 14:40:03 GMT <AFaust> each alf_prop_value can be a reference to either of thealf_prop_XY_value tables based on the persisted_type_id
2019-01-09 14:41:03 GMT <AFaust> so you need at least 8 joins to completely load an entry (4 to alf_value and 4 more for the transitive link to one of the alf_prop_xx_value)
2019-01-09 14:41:05 GMT <hi-ko> yes - depending on the persisted type
2019-01-09 14:42:13 GMT <AFaust> I have not yet seen any persisted configuration examples where the alf_prop_root + alf_prop_link tables become involved - these are mostly used for auditing data where the prop value is a map
2019-01-09 14:42:29 GMT <AFaust> But technically they could also be used via the AttributeService
2019-01-09 14:42:54 GMT <AFaust> I assume in that case the link would again be via the alf_prop_value table and a special persisted type
2019-01-09 15:20:50 GMT <hi-ko> AFaust: sorry again: if I find e.g. 'Search$managed$noindex' in alf_prop_string_value I should find the related context by value1_prop_id or value2_prop_id or value2_prop_id?
2019-01-09 15:21:21 GMT <hi-ko> I don't understand the structure yet
2019-01-09 15:31:00 GMT <AFaust> So Enterprise should have ".PropertyBackedBeans" via value1_prop_id and the name of the subsystem / property backed bean ("Search$managed$noindex") in value2_prop_id
2019-01-09 15:33:11 GMT <AFaust> Looking at my support tools implementation (which supports "read" capability for legacy JMX settings) the value in prop1_id should be a map, so actually alf_prop_root/alf_prop_link will have to be involved in some way.
2019-01-09 15:33:44 GMT <AFaust> Legacy JMX stored all the settings as one big chunk - my supports-tools implementation stores each property in a subsystem individually...
2019-01-09 15:40:39 GMT <hi-ko> as a work around I commented out the cron Triggers for Solr in the repo-jar having the wrong config
2019-01-09 15:42:14 GMT <hi-ko> I will continue on the db later. thanks!
2019-01-09 17:40:22 GMT <hi-ko> loftu
The other logs are at http://esplins.org/hash_alfresco