Daily Log for #alfresco IRC Channel

Alfresco discussion and collaboration. Stick around a few hours after asking a question.

Official support for Enterprise subscribers: support.alfresco.com.

Joining the Channel:

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.

Getting Help

More help is available in this list of resources.

Daily Log for #alfresco

2018-12-11 00:02:47 GMT <alfresco-discord> <douglascrp> would you help on this? at least providing some guidance?

2018-12-11 00:03:07 GMT <alfresco-discord> <douglascrp> I believe trying to create a patch would be easier than creating a new property type

2018-12-11 00:03:22 GMT <alfresco-discord> <douglascrp> the issue itself already has lots of good information

2018-12-11 02:14:28 GMT <alfresco-discord> <douglascrp> @AFaust, some classes with date related processing I could find so far: https://github.com/Alfresco/alfresco-data-model/blob/c7aaa53cce8245889ef79daffac46b53f827ee0e/src/main/java/org/alfresco/service/cmr/repository/datatype/DefaultTypeConverter.java

2018-12-11 02:14:29 GMT <alfresco-discord> https://github.com/Alfresco/alfresco-data-model/blob/c7aaa53cce8245889ef79daffac46b53f827ee0e/src/main/java/org/alfresco/service/cmr/dictionary/DataTypeDefinition.java https://github.com/alfresco-mirror/alfresco-mirror/blob/master/root/projects/core/source/java/org/alfresco/util/ISO8601DateFormat.java

2018-12-11 02:14:30 GMT <alfbot> Title:alfresco-data-model/DefaultTypeConverter.java at c7aaa53cce8245889ef79daffac46b53f827ee0e · Alfresco/alfresco-data-model · GitHub (at github.com)

2018-12-11 02:14:31 GMT <alfbot> Title:alfresco-data-model/DataTypeDefinition.java at c7aaa53cce8245889ef79daffac46b53f827ee0e · Alfresco/alfresco-data-model · GitHub (at github.com)

2018-12-11 06:42:24 GMT <AFaust> douglascrp: But creating a new property type would be a "cleaner" solution for compatibility reasons. If you change the d:date behaviour, you'll have to adapt SOLR / clients too and essentially create a split in cross-version support, i.e. ASS 1.x only supports / runs correctly with ACS 6.x and up, and no longer with ACS 5.2/ / 6.0 as well...

2018-12-11 06:43:22 GMT <AFaust> And ACS 6.x (where the d:date behaviour changed) would only support ASS 1.x and up (where ASS was already adapted)

2018-12-11 06:44:31 GMT <AFaust> A new property type would only introduce one of these dependencies, i.e. have ACS require a specific version of ASS / clients (that can handle the new type), but have ASS / Clients still be backeards compatible to other ACS versions...

2018-12-11 07:20:45 GMT <alfresco-discord> <mnybon> Hello everyone. I have been developing a code-generation maven plugin for Alfresco Module files 2 Java, and the first version is more or less complete. My only snag is testing. I would very much like to create a unit test that starts an Alfresco instance and runs a number of junit tests in that context. But the only examples I have are testing entire amp deployments, which is not really whats in scope.

2018-12-11 07:20:46 GMT <alfresco-discord> Can someone help me witha guide to some integrations-testing? I don't think i need access to more than the NodeService functionality at the moment.

2018-12-11 09:29:12 GMT <alfresco-discord> <drazen04> Hi, everyone. I really need help. I'm working with Alfresco 5 and solr 4 and there is no way to make work solr. The log is always "ERROR [solr.tracker.AbstractTracker]".

2018-12-11 09:30:06 GMT <angelborroy> can you paste your full “catalina.out” in pastebin or so?

2018-12-11 09:32:52 GMT <alfresco-discord> <drazen04> https://pastebin.com/gksu7he7

2018-12-11 09:32:53 GMT <alfbot> Title:2018-12-11 10:17:44,294 ERROR [solr.tracker.AbstractTracker] [org.alfresco.solr - Pastebin.com (at pastebin.com)

2018-12-11 09:33:11 GMT <angelborroy> Not only this part...

2018-12-11 09:33:17 GMT <angelborroy> … the whole catalina.out

2018-12-11 09:33:31 GMT <angelborroy> This error is provoked because Alfresco is not working properly

2018-12-11 09:33:40 GMT <angelborroy> You have to find a “caused by” in your log

2018-12-11 09:36:49 GMT <alfresco-discord> <drazen04> I cannot find it

2018-12-11 09:38:09 GMT <alfresco-discord> <drazen04> https://pastebin.com/0HUZNciK

2018-12-11 09:38:10 GMT <alfbot> Title:dic 11, 2018 10:16:41 AM org.apache.catalina.startup.VersionLoggerListener log - Pastebin.com (at pastebin.com)

2018-12-11 09:39:36 GMT <angelborroy> it looks like you have different problems writing log files

2018-12-11 09:39:59 GMT <angelborroy> and some webscript that is now properly deployed

2018-12-11 09:40:10 GMT <angelborroy> alfresco is working as expected?

2018-12-11 09:40:19 GMT <angelborroy> http://localhost:8080/alfresco is up and ready?

2018-12-11 09:40:31 GMT <alfresco-discord> <drazen04> yes

2018-12-11 09:40:46 GMT <alfresco-discord> <drazen04> Yes, it works

2018-12-11 09:40:50 GMT <angelborroy> can you share your alfresco-global.properties?

2018-12-11 09:40:58 GMT <angelborroy> just to check if solr is properly configured

2018-12-11 09:41:53 GMT <angelborroy> https://localhost:8443/alfresco is also working?

2018-12-11 09:43:44 GMT <alfresco-discord> <drazen04> https://pastebin.com/408PiHve

2018-12-11 09:43:45 GMT <alfbot> Title:############################### ## Common Alfresco Properties # ############ - Pastebin.com (at pastebin.com)

2018-12-11 09:44:09 GMT <angelborroy> https://localhost:8443/alfresco is also working?

2018-12-11 09:44:17 GMT <angelborroy> did you changed SSL certificates?

2018-12-11 09:45:04 GMT <alfresco-discord> <drazen04> No, it's not working

2018-12-11 09:45:20 GMT <angelborroy> SOLR is trying to connect with https://localhost:8443/alfresco

2018-12-11 09:45:43 GMT <angelborroy> what did you make?

2018-12-11 09:45:49 GMT <angelborroy> some change in SSL configuration for Tomcat?

2018-12-11 09:46:49 GMT <alfresco-discord> <drazen04> No changes

2018-12-11 09:47:06 GMT <angelborroy> so it stopped to work suddenly?

2018-12-11 09:48:00 GMT <angelborroy> can you share your server.xml from tomcat/conf?

2018-12-11 09:49:07 GMT <alfresco-discord> <drazen04> https://pastebin.com/yBE6knxB

2018-12-11 09:49:08 GMT <alfbot> Title:<?xml version="1.0" encoding="UTF-8"?> <!-- Licensed to the Apache Software - Pastebin.com (at pastebin.com)

2018-12-11 09:50:54 GMT <angelborroy> Your connector port for 8443 is commented

2018-12-11 09:51:06 GMT <angelborroy> This is not default configuration for Alfresco

2018-12-11 09:51:23 GMT <angelborroy> You have to use something like this

2018-12-11 09:51:23 GMT <angelborroy> https://github.com/loftuxab/alfresco-ubuntu-install/blob/master/tomcat/server.xml#L97

2018-12-11 09:51:24 GMT <alfbot> Title:alfresco-ubuntu-install/server.xml at master · loftuxab/alfresco-ubuntu-install · GitHub (at github.com)

2018-12-11 09:51:35 GMT <angelborroy> Or just leave the installer making the job for you

2018-12-11 10:00:34 GMT <alfresco-discord> <drazen04> I'll try to re-install it

2018-12-11 10:00:39 GMT <alfresco-discord> <drazen04> Thank you 😉

2018-12-11 11:16:22 GMT <alfresco-discord> <douglascrp> good morning everyone

2018-12-11 11:16:44 GMT <alfresco-discord> <douglascrp> I am back after an almost no sleep night 😄

2018-12-11 11:16:54 GMT <alfresco-discord> <douglascrp> I accidentally deleted all the production data yesterday 😄

2018-12-11 11:20:51 GMT <alfresco-discord> <MorganP> Hi @douglascrp

2018-12-11 11:20:55 GMT <alfresco-discord> <MorganP> Sounds nice 😉

2018-12-11 11:26:11 GMT <alfresco-discord> <douglascrp> not tine at all 😄

2018-12-11 11:26:16 GMT <alfresco-discord> <douglascrp> only the backup saves 😄

2018-12-11 11:29:29 GMT <alfresco-discord> <mnybon> Hello guys. Can someone help me understand something about security contexts. I have a class which uses the ApplicationContextHelper.getApplicationContext() to get a NodeService instance. The instance is found but when I attempt to use it I get this error: net.sf.acegisecurity.AuthenticationCredentialsNotFoundException: A valid SecureContext was not provided in the RequestContext I am running a test

2018-12-11 11:29:29 GMT <alfresco-discord> in a subclass of BaseWebScriptTest. The odd thing is that if i do the exact same thing with the NodeService i get from getServer().getApplicationContext().getBean("ServiceRegistry", ServiceRegistry.class) in the test everything works fine

2018-12-11 11:30:24 GMT <alfresco-discord> <mnybon> I also tried putting the code inside a List<StoreRef> generatedRefsNodeBase = AuthenticationUtil.runAs(new AuthenticationUtil.RunAsWork< List<StoreRef>>() { @Override public List<StoreRef> doWork() throws Exception { //My code here } }, AuthenticationUtil.getFullyAuthenticatedUser()); block, but that

2018-12-11 11:30:24 GMT <alfresco-discord> didn't work so i deduce that i have no idea what I'm doing...

2018-12-11 11:53:37 GMT <alfresco-discord> <douglascrp> @AFaust, about the date problem, we were think about how to recover, by a db query for example, what documents are stored with dates using the wrong timezone, and then try to "fix" them by changing the database directly

2018-12-11 11:53:41 GMT <alfresco-discord> <douglascrp> do you have any idea?

2018-12-11 12:00:36 GMT <alfresco-discord> <MorganP> How would you know in the DB which dates are wrong and which are rights?

2018-12-11 12:00:48 GMT <alfresco-discord> <douglascrp> that is exactly what I am trying to figure out

2018-12-11 12:01:05 GMT <alfresco-discord> <douglascrp> this is not the fix for the problem, but a workaround to avoid users seeing the wrong values

2018-12-11 12:01:24 GMT <alfresco-discord> <douglascrp> I am trying to identify if the timezone information is kept in the database in some way

2018-12-11 12:01:41 GMT <alfresco-discord> <MorganP> yes it is in the date

2018-12-11 12:02:08 GMT <alfresco-discord> <douglascrp> nice

2018-12-11 12:02:17 GMT <alfresco-discord> <MorganP> look at the first query for example

2018-12-11 12:02:17 GMT <alfresco-discord> <MorganP> https://blog.dbi-services.com/alfresco-some-useful-database-queries/

2018-12-11 12:02:19 GMT <alfresco-discord> <douglascrp> I am going to connect into the db right now and try to identify the issue

2018-12-11 12:02:20 GMT <alfbot> Title:Alfresco: some useful database queries - Blog dbi services (at blog.dbi-services.com)

2018-12-11 12:02:30 GMT <alfresco-discord> <douglascrp> tks

2018-12-11 12:02:31 GMT <alfresco-discord> <MorganP> There is the +02:00

2018-12-11 12:02:39 GMT <alfresco-discord> <douglascrp> hmmm, interesting

2018-12-11 12:03:21 GMT <alfresco-discord> <douglascrp> @AFaust, I am in to try to fix this problem by creating the new data type you suggested... would you guide me on this? at least in a high level?

2018-12-11 12:03:33 GMT <alfresco-discord> <douglascrp> we use date properties a lot, and it is important to have them working properly

2018-12-11 12:04:37 GMT <alfresco-discord> <MorganP> Sometimes it's Z, sometimes +01:00, +02:00, ...

2018-12-11 12:06:09 GMT <alfresco-discord> <douglascrp> the other ones are the ones I would have to "touch"

2018-12-11 12:31:39 GMT <alfresco-discord> <MorganP> It depends

2018-12-11 12:32:13 GMT <alfresco-discord> <douglascrp> I am playing with it rignt now

2018-12-11 12:32:26 GMT <alfresco-discord> <douglascrp> making sure it is on the dev server this time 😛

2018-12-11 12:32:28 GMT <alfresco-discord> <MorganP> I have these +01:00 and +02:00 on an internal Alfresco

2018-12-11 12:32:39 GMT <alfresco-discord> <MorganP> We are all on the same timezone in switzerland

2018-12-11 12:32:50 GMT <alfresco-discord> <MorganP> yet we have different representations on the DB

2018-12-11 12:32:59 GMT <alfresco-discord> <MorganP> So not sure how it changes and why

2018-12-11 12:32:59 GMT <alfresco-discord> <douglascrp> the problem is DST in my case

2018-12-11 12:38:21 GMT <AFaust> douglascrp: I am not sure you will be able to find the incorrect dates via a DB query.All dates in DB "should" be stored as Z / UTC formatted ISO dates

2018-12-11 12:38:55 GMT <alfresco-discord> <douglascrp> hmmm, that would be a problem

2018-12-11 12:39:14 GMT <AFaust> I too have seen those +01:00/+02:00 table entries at some point, but am not sure how these come to be...

2018-12-11 12:41:28 GMT <AFaust> Ahh.. I think the various evolutions of the ISO8601DateFormat class are responsible for the non-Z dates in the DB

2018-12-11 12:43:11 GMT <AFaust> When Alfresco stores dates it does a Date -> String conversion, and https://issues.alfresco.com/jira/browse/ALF-21965 has in the most recent iteration of ISO8601DateFormat ensured that only Z-dates will ever be stored

2018-12-11 12:43:34 GMT <AFaust> Interestingly, a code comment refers to https://issues.alfresco.com/jira/browse/ALF-21957

2018-12-11 12:43:55 GMT <alfresco-discord> <douglascrp> checking all links

2018-12-11 12:43:56 GMT <AFaust> The ALF-21965 was from yreg

2018-12-11 12:44:05 GMT <AFaust> https://github.com/Alfresco/alfresco-core/blob/master/src/main/java/org/alfresco/util/ISO8601DateFormat.java#L148

2018-12-11 12:44:06 GMT <alfbot> Title:alfresco-core/ISO8601DateFormat.java at master · Alfresco/alfresco-core · GitHub (at github.com)

2018-12-11 12:44:36 GMT <AFaust> Before that change you could get those +/- offsets in DB due to server timezone

2018-12-11 12:45:08 GMT <AFaust> unless server was running in UTC (which I often set my servers to so I was under the impression Z was the default)

2018-12-11 12:47:32 GMT <AFaust> So the +01:00/+02:00 that MorganP sees are clearly non-DST / DST

2018-12-11 12:47:55 GMT <alfresco-discord> <douglascrp> in those cases, maybe fixing the values would do the trick, right?

2018-12-11 12:49:45 GMT <AFaust> Ahh... I also remember having to write a bugfix in an old PRODYNA module for one of my current customers which was trying to find max/min date values (for faceting) of a specific property in the DB, and due to the +01:00/+02:00 data in their system it could not do a simple MIN/MAX SQL. So I believe we actually wrote a patch to pin all existing dates to UTC and backported the ISO8601DateFormat change from yreg to our version of 5.2

2018-12-11 12:49:46 GMT <AFaust> Enterprise...

2018-12-11 12:52:45 GMT <alfresco-discord> <douglascrp> in my case, I found this 2018-10-29T02:00:00.000Z

2018-12-11 12:53:01 GMT <alfresco-discord> <douglascrp> the only difference is the T02:00:00.000Z part

2018-12-11 12:53:23 GMT <alfresco-discord> <douglascrp> and I also have things like 2014-09-25T03:00:00.000Z

2018-12-11 12:55:41 GMT <AFaust> Ok - so it is already stored "correctly" as UTF, but you are confused by the 02:00 / 03.00 effective hours. Well, that is "normal" d:date behaviour, taking the timezoned client date at 00:00 and converting it to UTC (with proper offset added / removed) for storing it.

2018-12-11 12:56:09 GMT <AFaust> UTF => UTC

2018-12-11 12:56:54 GMT <alfresco-discord> <douglascrp> I am trying to find different cases

2018-12-11 12:57:25 GMT <alfresco-discord> <douglascrp> indeed, for this specific property I am working on, I have not a single value stored incorectly

2018-12-11 12:58:43 GMT <AFaust> Oh - and our patch for those dates in DB also included padding of years 0 <= x < 1000 to a 4 digit year value, otherwise MIN/MAX would not work since those ISO 8601 strings are sorted lexicograpihcally...

2018-12-11 12:58:57 GMT <AFaust> lexicographically

2018-12-11 12:59:11 GMT <alfresco-discord> <douglascrp> got it

2018-12-11 12:59:24 GMT <AFaust> Why did we have dates with years 0 <= x < 1000? Well, because of the Alfresco Outlook Client, of course...

2018-12-11 13:01:50 GMT <AFaust> Damn, I just noticed our corrected ISO8601DateConverter does not guarantee a year to be formatted with 4 digits, so any new dates added to our DB can break MIN/MAX again

2018-12-11 13:01:54 GMT <alfresco-discord> <douglascrp> ok, the database is right, but why is the date saved as 23:00, like this? 28 out 2018 23:00:00 GMT-0300 (BRT)

2018-12-11 13:02:04 GMT <alfresco-discord> <douglascrp> wouldn't it be the right value to set as 00:00 ?

2018-12-11 13:04:17 GMT <alfresco-discord> <douglascrp> not saved, shown in node browser

2018-12-11 13:04:26 GMT <alfresco-discord> <douglascrp> but I guess because of the offset

2018-12-11 13:08:11 GMT <AFaust> Let me do some checks - I think I may have a clue about the origin of the incorrect date saves...

2018-12-11 13:08:30 GMT <alfresco-discord> <douglascrp> but in the DB, they are right

2018-12-11 13:09:11 GMT <alfresco-discord> <douglascrp> having servers running on UTC would be a good thing?

2018-12-11 13:10:02 GMT <AFaust> Well, it would avoid those issues with "different serer timezone after restart" issues and be consistent all year

2018-12-11 13:10:33 GMT <alfresco-discord> <douglascrp> but things depending on time, like cron, would be problematic, right?

2018-12-11 13:10:59 GMT <AFaust> I don't know how much that would help in your case specifically. I never had such a persistent issue of incorrect dates to begin with - even in the customer system with the 01:00/02:00 offsets stored in DB, apart from the MIN/MAX select issue

2018-12-11 13:11:30 GMT <AFaust> CRON would not be problematic at all. It would run as configured, using UTC as the reference zone

2018-12-11 13:12:00 GMT <AFaust> You would "just" have to align your thinking during configuration to think in UTC, instead of your local time...

2018-12-11 13:13:49 GMT <alfresco-discord> <douglascrp> and to make things even better, this year was different https://www.timeanddate.com/news/time/brazil-delays-dst-2018.html

2018-12-11 13:13:50 GMT <alfresco-discord> <douglascrp> 😄

2018-12-11 13:13:50 GMT <alfbot> Title:Brazil Changes DST Start from 2018 (at www.timeanddate.com)

2018-12-11 13:14:12 GMT <alfresco-discord> <douglascrp> it was when the problem started happening, after the server got restarted for maintenance

2018-12-11 13:14:32 GMT <alfresco-discord> <douglascrp> so, if setting the server as UTC is the "fix", I am going to evaluate this option

2018-12-11 13:21:37 GMT <alfresco-discord> <douglascrp> @AFaust, do you think the user's local machine tz settings could be the cause of this?

2018-12-11 13:22:01 GMT <alfresco-discord> <douglascrp> because they select the date using share

2018-12-11 13:22:36 GMT <AFaust> That and how the final ISO value for transmission is constructed on the client-side

2018-12-11 13:23:05 GMT <alfresco-discord> <douglascrp> so, there is no easy fix for this

2018-12-11 13:24:06 GMT <alfresco-discord> <douglascrp> I tried changing the date for one of the documents with the wrong date, but the value is not changed... weird

2018-12-11 13:26:14 GMT <alfresco-discord> <douglascrp> java is configured as -Duser.timezone=America/Sao_Paulo

2018-12-11 13:32:25 GMT <AFaust> Ok... so I am testing with a default d:date property (audio:releasedate) via Share. The date is provided without any time from Share to repository, and repository adds 00:00 in the serer time zone to form the full value. In my instance, the local server was started today with CET, but it still handled CET + CEST dates correctly

2018-12-11 13:32:34 GMT <AFaust> though to be fair, this is a customer specific build I am running right now, so our patches could already fix some stuff - will run a more default Alfresco next

2018-12-11 13:33:16 GMT <alfresco-discord> <douglascrp> cool

2018-12-11 13:33:17 GMT <AFaust> I must have confused the default Share form behaviour with Aikau date behaviour (which is different)

2018-12-11 13:33:29 GMT <alfresco-discord> <douglascrp> tks for all the help investigating this

2018-12-11 13:33:43 GMT <AFaust> Aikau date widget will always produce a full ISO8601 string...

2018-12-11 13:34:19 GMT <AFaust> And in one project I believe I patched the default Aikau widget for date handling to handle timezones correctly...

2018-12-11 13:36:53 GMT <AFaust> Right - I patched the DateTextBox to add a configuration property "editAsUTC" to have UI use UTC to standardize displaying "date" values (which may still contain some arbitrary time portion)

2018-12-11 13:37:23 GMT <alfresco-discord> <douglascrp> but that does not apply for share forms, right?

2018-12-11 13:37:27 GMT <AFaust> And I believe there are still some cases where one customer complains about a date value slipping a day into the past on every edit cycle...

2018-12-11 13:39:01 GMT <AFaust> Share forms date.ftl widget always submits as date-only, but uses ISO8601 raw value to determine the value to display when editing an existing value...

2018-12-11 13:40:13 GMT <AFaust> The last part is where the slip occurs when you look at the date value in a timezone "later" than the server timezone (i.e. date stored in server timezone CET, and you look at it with BRT timezone, you will see "date - 1")

2018-12-11 13:40:56 GMT <alfresco-discord> <douglascrp> by "you look at it with BRT timezone", you mean, the browser?

2018-12-11 13:41:27 GMT <AFaust> Yes, since it will parse the ISO8601 and then strip away the time after TZ has already been adjusted

2018-12-11 13:42:29 GMT <AFaust> Repository should always expose a d:date value as "date-only" in its ReST APIs to deal with this

2018-12-11 13:42:44 GMT <AFaust> But then a lot of client code may have to be adapted to not fail when ISO8601 is "incomplete"

2018-12-11 13:44:19 GMT <alfresco-discord> <Loftux> https://issues.alfresco.com/jira/browse/MNT-16261

2018-12-11 13:44:29 GMT <alfresco-discord> <Loftux> Date bug

2018-12-11 13:46:03 GMT <alfresco-discord> <Loftux> Even created a sample project for them so that they could reproduce the issue where the date moves 1 day back for each save.

2018-12-11 13:48:25 GMT <alfresco-discord> <Loftux> I've moved on to use https://github.com/dbushell/Pikaday when time is not needed to be part of the control

2018-12-11 13:48:26 GMT <alfbot> Title:GitHub - Pikaday/Pikaday: A refreshing JavaScript Datepicker — lightweight, no dependencies, modular CSS (at github.com)

2018-12-11 13:48:32 GMT <AFaust> Yeah - my patch for the Aikau widget also was in 2016-something...

2018-12-11 13:58:53 GMT <alfresco-discord> <mnybon> Hello everyone. I hope I do not seem overly pushy, but I tried asking about NodeService and a missing SecurityContext this morning, and noone seemed to have an answer. I am using the NodeService in a BaseWebScriptTest. One NodeService is retrieved thorugh getServer().getApplicationContext().getBean(uid, class) and the other is retrieved though ApplicationContextHelper.getApplicationContext(). The

2018-12-11 13:58:53 GMT <alfresco-discord> first one works fine but the one I got though ApplicationContextHelper.getApplicationContext() throws this exception on every use: net.sf.acegisecurity.AuthenticationCredentialsNotFoundException: A valid SecureContext was not provided in the RequestContext

2018-12-11 13:59:39 GMT <AFaust> mnybon: Alfresco does not recommend obtaining a service via the application context - they recommend using the ServiceRegistry

2018-12-11 14:00:05 GMT <alfresco-discord> <mnybon> I am getting the ServiceRegistry though the ApplicationContext, so I was hoping that was ok

2018-12-11 14:00:18 GMT <AFaust> Also, this kind of exception can mean you do not have an authenticated user in the current thread / security context

2018-12-11 14:01:01 GMT <AFaust> The thing is there are multiple candidate beans in the application context for the interface of NodeService, and only the bean "NodeService" (with capital N) is the supported variant

2018-12-11 14:01:31 GMT <alfresco-discord> <mnybon> I tried using NodeService, nodeService and _nodeService, and each one gives me the same result

2018-12-11 14:01:36 GMT <AFaust> supported = safe to use for people that are not familiar with internal details of Alfresco architecture

2018-12-11 14:01:59 GMT <alfresco-discord> <mnybon> Thats not exactly true actually, one of them gave me a constructor exception

2018-12-11 14:02:00 GMT <AFaust> You should never use _nodeService, almost never nodeService, and almost always NodeService

2018-12-11 14:02:10 GMT <alfresco-discord> <mnybon> but it is NodeService I was using

2018-12-11 14:02:37 GMT <alfresco-discord> <mnybon> Actually i was getting the ServiceRegistry though the ApplicationContext at first since i thought that was the safest approach

2018-12-11 14:02:42 GMT <AFaust> Yeah, so if you are using NodeService (the proper, public API bean) then the exception means you do not have an authenticated user in the current thread context

2018-12-11 14:02:49 GMT <alfresco-discord> <mnybon> that is where the error began

2018-12-11 14:03:28 GMT <AFaust> Why were you getting the service registry from the application context (I assume via manual code)? Why not have Spring inject that component into your bean?

2018-12-11 14:03:56 GMT <AFaust> You should almost never have to deal with an instance of application context directly...

2018-12-11 14:04:11 GMT <alfresco-discord> <mnybon> Because I don't have a bean exactly. I am working on a code-generation framework to turn the model files into java classes

2018-12-11 14:05:40 GMT <alfresco-discord> <mnybon> Those classes should be able to work interface with Alfresco. The problem i am facing is that what I am doing is not exactly happening inside the realm of the established bean structure

2018-12-11 14:05:47 GMT <AFaust> Still, to have an application context you must have had to instantiate some context using a Spring context XML file in your code generator, and in that Spring context you could simply define a custom bean responsible for your custom handling logic and using Spring DI to get the references to Alfresco components

2018-12-11 14:06:33 GMT <AFaust> And if you are not running in a proper Alfresco system bean structure (because your Spring application context is only a partial context) then you should not try to use any of the Alfresco services in the first place... there is no guarantee any of them will work correctly...

2018-12-11 14:06:37 GMT <alfresco-discord> <bhagyas> @douglascrp will you be there at the devcon?

2018-12-11 14:07:29 GMT <alfresco-discord> <mnybon> @AFaust The idea is that the generated code should be used inside Alfresco components in place of calls like NodeService.getProperty and getTargetAssoc and so on, so my context should be the "standard" Alfresco context

2018-12-11 14:07:53 GMT <alfresco-discord> <mnybon> I am just meeting a bit of resistence with actually getting at the ApplicationContext itself

2018-12-11 14:10:23 GMT <alfresco-discord> <mnybon> You can see the actual test here: https://github.com/magenta-aps/alfresco-model-codegenerator/blob/master/Tests/src/test/java/dk/magenta/alfresco/generated/Tests.java The serviceRegistry.getNodeService().getStores() call works like a charm, the return NodeBase.getStores() does not. NodeBase.getStores() gets the ApplicationContext, then gets the ServiceRegistry, then the NodeService, then calls

2018-12-11 14:10:24 GMT <alfresco-discord> getStores()

2018-12-11 14:10:24 GMT <alfbot> Title:alfresco-model-codegenerator/Tests.java at master · magenta-aps/alfresco-model-codegenerator · GitHub (at github.com)

2018-12-11 14:10:42 GMT <alfresco-discord> <mnybon> one works, one does not, and I simply cannot get my head around why

2018-12-11 14:14:12 GMT <AFaust> What you mean, one works, one doesn't? Of course that happens - one test uses Alfresco API, the other doesn't,so the one that does not use Alfresco API works...

2018-12-11 14:15:26 GMT <AFaust> I also advise to never use setAdminUserAsFullyAuthenticatedUser - the "admin" user may not exist because it can actually be deleted at any point / not be bootstrapped...

2018-12-11 14:15:36 GMT <AFaust> I always prefer to use "System" user for any tests for that reason

2018-12-11 14:16:21 GMT <alfresco-discord> <mnybon> Sorry! I will try to be a little more clear. One returns the StoreRefs, the other one returns the net.sf.acegisecurity.AuthenticationCredentialsNotFoundException: A valid SecureContext was not provided in the RequestContext exception

2018-12-11 14:16:53 GMT <alfresco-discord> <mnybon> For clarity: AuthenticationUtil.setAdminUserAsFullyAuthenticatedUser(); List<StoreRef> baseRefs = serviceRegistry.getNodeService().getStores(); ApplicationContext context = ApplicationContextHelper.getApplicationContext(); ServiceRegistry reg = context.getBean(ServiceRegistry.class); reg.getNodeService().getStores();

2018-12-11 14:16:55 GMT <AFaust> Yeah, so the problem is not in your test class, but your NodeBase class

2018-12-11 14:17:41 GMT <AFaust> Where you are using a different approach to obtaining the application context

2018-12-11 14:17:48 GMT <alfresco-discord> <mnybon> I removed the NodeBase dependency and did the above instead. The error is the same for the second call

2018-12-11 14:18:44 GMT <alfresco-discord> <mnybon> Yes I realize that is the problem, my question is how on earth do I get it to work? I don't understand what the first call does that the second does not

2018-12-11 14:19:09 GMT <AFaust> The ApplicationContextHelper does NOT retrieve the same application context as the getServer().getApplicationContext() call in your test setup call.

2018-12-11 14:20:05 GMT <AFaust> As it stands, you are creating two different application contexts, one via the getServer() and one via ApplicationContextHelper... Those are also setup differently, the getServer() one is more complete

2018-12-11 14:20:25 GMT <AFaust> ... it contains web script related stuff, while the latter contains only some application core stuff

2018-12-11 14:20:37 GMT <alfresco-discord> <douglascrp> @Loftux thanks for the input... I am going to read after lunch

2018-12-11 14:20:58 GMT <alfresco-discord> <douglascrp> @bhagyas no, I am not

2018-12-11 14:21:27 GMT <alfresco-discord> <mnybon> oook. So I am basically dead in the water then? There is no way to get an application context outside of the normal Alfresco bootstrapping?

2018-12-11 14:21:49 GMT <alfresco-discord> <mnybon> Or just a ServiceRegistry i mean

2018-12-11 14:22:02 GMT <alfresco-discord> <drazen04> Hi, i solved the problem with solr. I don't know why eclipse taked the wrong server.xml from Tomcat

2018-12-11 14:22:25 GMT <alfresco-discord> <douglascrp> lunch time... brb

2018-12-11 14:23:36 GMT <AFaust> mnybon: First, you should seriously overhaul your test + code generator architecture to make sure you work with the same application context, and it is a context that also allows the services to work correctly (what about connection to databases etc?)

2018-12-11 14:26:11 GMT <AFaust> You can get an application context outside of the "normal" Alfresco bootstrapping (i.e. running in a Tomcat), but depending on what you need the services to do, those half-assed, for tests-only application contexts may not do for your code genreator tool (I don't know what the full feature plan for the tool is)

2018-12-11 14:26:55 GMT <alfresco-discord> <drazen04> Now, i have a code problem. The scenario is this one: i have to create a zip from file and a folder that exist in the same parent folder without download it. I try to override the createDownload method from DownloadServiceImpl but it doesn't work. Some advices?

2018-12-11 14:27:36 GMT <alfresco-discord> <mnybon> @AFaust I completely agree and that is exactly what I am trying to do. I am trying to figure out a way to use the ApplicationContext already started by Alfresco. But the problem is that finding any sort of actionalble information on this matter is kind of hard. So I was hoping for some help in understanding it, hence my presense here. By the way you are responding it seems that it's common knowledge,

2018-12-11 14:27:36 GMT <alfresco-discord> but I just have no idea what to do.

2018-12-11 14:28:11 GMT <alfresco-discord> <mnybon> The whole idea is that the code I am generating should be used inside an already started Alfresco, in Webscripts for example.

2018-12-11 14:28:47 GMT <alfresco-discord> <yreg> @mnybon AFaust's knowledge is far from being common (just a side note)

2018-12-11 14:28:52 GMT <alfresco-discord> <mnybon> So I would like to use the ApplicationContext already present there, I just don't know how. I though the getApplicationContext was the way to go.

2018-12-11 14:29:08 GMT <alfresco-discord> <mnybon> obiously it wasn't 😃

2018-12-11 14:30:22 GMT <rluders> Is there any way to list the jobs from Alfresco mailer? or get the mailing status?

2018-12-11 14:30:34 GMT <rluders> same for workflows

2018-12-11 14:31:28 GMT <AFaust> mnybon: The "getApplicationContext()" is just a utility for test environments. In a regular, already started Alfresco environment you would normally not need to get the application context as you would inject your dependencies.

2018-12-11 14:32:09 GMT <AFaust> Though an already started Alfresco also has some utilities to get the application context, they are different from the "getApplicationContext" used in tests

2018-12-11 14:32:43 GMT <alfresco-discord> <mnybon> I would really like to know what those are, because that sounds exactly like what i need

2018-12-11 14:33:17 GMT <alfresco-discord> <yreg> AFaust I guess he is trying to setup some kind of remote test runner in a webscript and in such a usecase, he will probably not have the comprehensive list of beans he will need pre-injected

2018-12-11 14:34:01 GMT <AFaust> a) any Spring bean in an Alfresco environment can simply implement the interface ApplicationContextAware to be passed the application context via a lifecycle methods

2018-12-11 14:34:38 GMT <alfresco-discord> <yreg> If that's the use case, I would advise either to inject servicesRegistry (if that's already enough / high level services are what he needs) or use ApplicationContextAware interface

2018-12-11 14:34:56 GMT <alfresco-discord> <mnybon> @AFaust but that would require Alfresco to create the bean in the first place right? That is kind of a problem.

2018-12-11 14:35:03 GMT <AFaust> b) any thread that is executing a user request in an Alfresco environment can use ContextLoader.getCurrentWebApplicationContext() - but that will not work in background processes

2018-12-11 14:35:33 GMT <AFaust> And yreg is repeating what I already mentioned: prefer injecting ServiceRegistry over using the application context whenever possible

2018-12-11 14:36:01 GMT <AFaust> so in case a) you should never use ApplicationContext at all

2018-12-11 14:36:24 GMT <AFaust> and case b) is typically reserved for workarounds, i.e. in JavaScript Console js code

2018-12-11 14:36:31 GMT <alfresco-discord> <mnybon> @yreg not exactly. What i am doing is creating a way to map model.xml types to java classes. So instead of doing NodeService.getProperty(myTypeRef, myPropertyRef) you would call myType.getProperty() instead

2018-12-11 14:37:06 GMT <alfresco-discord> <mnybon> the idea is to get around the busywork of mapping a custom model with whole bunch of constants

2018-12-11 14:38:25 GMT <AFaust> One thing I don't understand is: Why does your code generator have to use the node service at all? The code generator should just generate code, which then would be wired up in the Alfresco application context as any other beans would... So no need to do any weird magic...

2018-12-11 14:38:46 GMT <AFaust> A code generator should never have to do runtime service calls itself...

2018-12-11 14:38:56 GMT <AFaust> It is just a model-to-text transformation application

2018-12-11 14:40:54 GMT <alfresco-discord> <mnybon> Because the whole idea is to map the functionality as well as the types. There, for example, is the content:folder class: package dk.magenta.alfresco.generated.org.alfresco.model.content._1_0; import dk.magenta.alfresco.generated.Name; import dk.magenta.alfresco.generated.org.alfresco.model.system._1_0.Base; import java.util.List; import org.alfresco.service.namespace.QName; @Name( namespace =

2018-12-11 14:40:54 GMT <alfresco-discord> "http://www.alfresco.org/model/content/1.0", localName = "folder" ) public class Folder extends Cmobject { public static final QName containsChildAssociation = QName.createQName("http://www.alfresco.org/model/content/1.0", "contains"); public List<Base> getContainsChild() { return getChildAssociations(Base.class, containsChildAssociation); } } And here is system:Archived package

2018-12-11 14:40:55 GMT <alfresco-discord> dk.magenta.alfresco.generated.org.alfresco.model.system._1_0; import dk.magenta.alfresco.generated.Name; import java.lang.String; import java.util.Date; import org.alfresco.service.cmr.repository.ChildAssociationRef; @Name( namespace = "http://www.alfresco.org/model/system/1.0", localName = "archived" ) public interface Archived { ChildAssociationRef getArchivedOriginalParentAssoc(); String

2018-12-11 14:40:55 GMT <alfresco-discord> getArchivedBy(); Date getArchivedDate(); String getArchivedOriginalOwner(); }

2018-12-11 14:41:13 GMT <alfresco-discord> <mnybon> eeehm. apparently the bot did not let me send class examples

2018-12-11 14:41:26 GMT <alfresco-discord> <mnybon> i tried to show a few types to better show what i am trying to do

2018-12-11 14:42:17 GMT <alfresco-discord> <mnybon> I really would like to just show off the project when I get it to work but that requires that I actually get the ApplicationContext to work 😃

2018-12-11 14:42:30 GMT <AFaust> you should use a paste service for providing any code snippets

2018-12-11 14:43:10 GMT <alfresco-discord> <mnybon> you are right of cause. I can see why the bot would get angry. It just sees some jerk shouting the same word over and over

2018-12-11 14:44:12 GMT <alfresco-discord> <mnybon> here you go. System:archived for example:

2018-12-11 14:44:13 GMT <alfresco-discord> <mnybon> https://paste.ofcode.org/38Xi7kgSNEE7LYnjZ3tquMP

2018-12-11 14:44:14 GMT <alfbot> Title:Paste ofCode (at paste.ofcode.org)

2018-12-11 14:44:31 GMT <alfresco-discord> <mnybon> This is an aspect, so it is an interface, that also has a class file

2018-12-11 14:44:44 GMT <alfresco-discord> <mnybon> https://paste.ofcode.org/LSpK6kend2EC3f6yUqRnPw

2018-12-11 14:44:45 GMT <alfbot> Title:Paste ofCode (at paste.ofcode.org)

2018-12-11 14:45:02 GMT <alfresco-discord> <mnybon> So i am building up the entire model in strongly types java calls

2018-12-11 14:45:43 GMT <alfresco-discord> <mnybon> calling Archived.getArchivedBy(); Will actually result in the call return (String)getNodeService().getProperty(getNodeRef(), archivedBy);

2018-12-11 14:45:46 GMT <AFaust> but to work with those objects you need to get them from somewhere, a service of some sorts..

2018-12-11 14:45:55 GMT <alfresco-discord> <mnybon> yes, the NodeService

2018-12-11 14:46:02 GMT <alfresco-discord> <mnybon> hence my need for the ServiceRegistry

2018-12-11 14:46:04 GMT <AFaust> No, no... the NodeService does not construct your objects

2018-12-11 14:46:28 GMT <alfresco-discord> <mnybon> No i get that, every type contains the NodeRef for the class it represents

2018-12-11 14:46:42 GMT <AFaust> The NodeService only deals with the Alfresco stuff... Something needs to instantiate the Archived class into an object and map that with a nodeRef...

2018-12-11 14:47:00 GMT <AFaust> And that something needs to already inject the correct application context along with the nodeRef into your wrapper instances

2018-12-11 14:47:44 GMT <alfresco-discord> <yreg> something like a factory bean

2018-12-11 14:47:58 GMT <AFaust> Side node: hard-casts to String (or any property value type) are very bad style IMHO... You should seriously consider using DefaultTypeConverter.INSTANCE.convert(<TargetType>.class, <value>)

2018-12-11 14:48:20 GMT <AFaust> Side node => side note (we are talking too much about nodes here already...)

2018-12-11 14:48:52 GMT <alfresco-discord> <mnybon> That sounded like AFaust saying that this is not possible again?

2018-12-11 14:49:14 GMT <AFaust> No... that should have sounded like "you may need to refactor your instantiation code"

2018-12-11 14:49:19 GMT <alfresco-discord> <mnybon> My though was that since I can do this in a WebScript with an injected ServiceRegistry, why can't i do it here?

2018-12-11 14:51:41 GMT <alfresco-discord> <mnybon> But i will make a note of the DefaultTypeConverter.INSTANCE.convert(<TargetType>.class, <value>)

2018-12-11 14:51:49 GMT <alfresco-discord> <mnybon> that does seem like a better idea

2018-12-11 14:54:16 GMT <alfresco-discord> <mnybon> @AFaust So if i understand correctly: ApplicationContextAware would be an idea if my class was a bean instantiated by Alfresco, but it isn't, so my way forwards seems to be ContextLoader.getCurrentWebApplicationContext() which will resctrict my code from being used to create backend processes, but should be OK for things like Webscripts and inside beans called by webscripts. Correct?

2018-12-11 14:56:30 GMT <AFaust> mnybon: What ever creates your objects of the ArchivedClass type should be a (utility / service) bean in Alfresco and have the service registry injected. Then, when you instantiate ArchivedClass, you simply pass the service registry along with the NodeRef of the node to wrap.

2018-12-11 14:58:04 GMT <AFaust> Best example of such a "wrapper" in default Alfresco: the ScriptNode class

2018-12-11 14:58:05 GMT <AFaust> see https://github.com/Alfresco/alfresco-repository/blob/4e4e31b5a618af26bce53db54d4dd362d2268d50/src/main/java/org/alfresco/repo/jscript/ScriptNode.java

2018-12-11 14:58:07 GMT <alfbot> Title:alfresco-repository/ScriptNode.java at 4e4e31b5a618af26bce53db54d4dd362d2268d50 · Alfresco/alfresco-repository · GitHub (at github.com)

2018-12-11 14:58:09 GMT <alfresco-discord> <mnybon> ... of cause... You know that old expression: If you can't see the idiot in the room, you need a mirror? 😄

2018-12-11 14:58:30 GMT <alfresco-discord> <mnybon> I need a mirror. Thanks a lot for your help

2018-12-11 14:59:23 GMT <AFaust> Never heard that expression - must be a Danish one not shared with your Germanic neighbours to the south...

2018-12-11 14:59:32 GMT <alfresco-discord> <mnybon> I should of cause just make my factory into a bean and let it be injected as normal

2018-12-11 15:03:27 GMT <alfresco-discord> <mnybon> @AFaust ContextLoader.getCurrentWebApplicationContext() returns null when I run it inside a BaseWebScriptTest. Is that expected behavior?

2018-12-11 15:03:57 GMT <alfresco-discord> <mnybon> BaseWebScriptTest seems to start up at least part of an Alfresco instance so I thought that would work

2018-12-11 15:05:52 GMT <AFaust> Yes, that is the expected behaviour

2018-12-11 15:06:55 GMT <AFaust> "any thread that is executing a user request" - a BaseWebScriptTest is not executing a user request, and using ContextLoader also requires a fully built servlet environment (i.e. running Alfresco webapp in Tomcat)

2018-12-11 15:07:37 GMT <AFaust> BaseWebScriptTest only builds up the Spring part of an Alfresco instance, without any servlet environment...

2018-12-11 15:09:48 GMT <alfresco-discord> <mnybon> Right. So in order to actually test my code in a unit test I will have to create a factory which can have the ServiceRegistry injected directly

2018-12-11 15:10:31 GMT <alfresco-discord> <mnybon> And i have the ServiceRegistry available already from the code.

2018-12-11 15:11:02 GMT <alfresco-discord> <mnybon> Ok. Thank you very much for all your help. I hope to be able to hand something semi-cool back to the community soon-ish

2018-12-11 16:57:16 GMT <alfresco-discord> <drazen04> Hi, someone know how to calculate a type_content hash in java?

2018-12-11 17:11:04 GMT <angelborroy> https://github.com/sujaypillai/alfchecksum

2018-12-11 17:11:05 GMT <alfbot> Title:GitHub - sujaypillai/alfchecksum (at github.com)

2018-12-11 19:12:15 GMT <alfresco-discord> <douglascrp> @Loftux is https://github.com/Pikaday/Pikaday used in your custom lx share project?

2018-12-11 19:12:17 GMT <alfbot> Title:GitHub - Pikaday/Pikaday: A refreshing JavaScript Datepicker — lightweight, no dependencies, modular CSS (at github.com)

2018-12-11 19:14:28 GMT <alfresco-discord> <Loftux> @douglascrp not in any public project right now

2018-12-11 19:14:39 GMT <alfresco-discord> <douglascrp> yes, right... I was searching here

2018-12-11 19:14:56 GMT <alfresco-discord> <douglascrp> now I am trying to understand the issue you linked, and how the project would help on this

2018-12-11 19:15:08 GMT <alfresco-discord> <douglascrp> I see you mention datetime...

2018-12-11 19:15:10 GMT <alfresco-discord> <douglascrp> I am using date only

2018-12-11 19:22:24 GMT <alfresco-discord> <douglascrp> have you been using the datetime hiding the time as a workaround to avoid the date problems?

2018-12-11 19:22:37 GMT <alfresco-discord> <douglascrp> @Loftux ^

2018-12-11 19:24:06 GMT <alfresco-discord> <Loftux> When only needing date switched to pickaday and it works

2018-12-11 19:24:27 GMT <alfresco-discord> <douglascrp> got it

2018-12-11 19:24:41 GMT <alfresco-discord> <douglascrp> tks

2018-12-11 19:50:35 GMT <alfresco-discord> <douglascrp> using JavaScript Console, if I run: var date = Packages.org.alfresco.service.cmr.repository.datatype.DefaultTypeConverter.INSTANCE.convert(Packages.java.util.Date, '2018-10-29T12:00:00.000Z'); print(date);

2018-12-11 19:50:52 GMT <alfresco-discord> <douglascrp> it works perfectly, and I get Mon Oct 29 09:00:00 BRT 2018

2018-12-11 19:52:02 GMT <alfresco-discord> <douglascrp> but as the value in the database is set as 2018-10-29T02:00:00.000Z, when I use the same code agains this value, I get: var date = Packages.org.alfresco.service.cmr.repository.datatype.DefaultTypeConverter.INSTANCE.convert(Packages.java.util.Date, '2018-10-29T02:00:00.000Z); print(date); Sun Oct 28 23:00:00 BRT 2018

2018-12-11 19:52:34 GMT <alfresco-discord> <douglascrp> so, a quick and dirty workaround would be to save the value as T12:00 when the property is date only

2018-12-11 19:55:21 GMT <alfresco-discord> <douglascrp> but for this to work, the https://github.com/Alfresco/alfresco-core/blob/master/src/main/java/org/alfresco/util/ISO8601DateFormat.java#L98 would have to know what the type is, if datetime or date

2018-12-11 19:55:22 GMT <alfbot> Title:alfresco-core/ISO8601DateFormat.java at master · Alfresco/alfresco-core · GitHub (at github.com)

2018-12-11 19:56:43 GMT <alfresco-discord> <douglascrp> wrong... what I wanted to say is that if I want to change the value presented to the user, without touching the database, then the previous sentence is what I would have to do

2018-12-11 20:17:05 GMT <alfresco-discord> <douglascrp> interesting... if I change the date.ftl to submit the time, and set it hardcoded as 12:00, it works

2018-12-11 20:17:10 GMT <alfresco-discord> <douglascrp> and I can see the right date on share

2018-12-11 20:17:20 GMT <alfresco-discord> <douglascrp> so, I guess I am going to workaround it like this

End of Daily Log

The other logs are at http://esplins.org/hash_alfresco