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

2019-01-08 12:02:58 GMT <AFaust> Can anyone explain to me how some beans in APS can be injected / autowired when their classes don't have any annotations marking them as @Component or @Service, and without any Spring XML thus should not be instantiated? There are also no direct calls to their constructors anywhere, as far as I can see...

2019-01-08 12:03:20 GMT <AFaust> The question relates to the beans in the activiti-app-alfresco-cloud JAR...

2019-01-08 12:06:06 GMT <alfresco-discord> <yreg> that's probably some spring configuration bean mojo

2019-01-08 12:06:14 GMT <alfresco-discord> <yreg> a shortcut of somesort

2019-01-08 12:06:30 GMT <alfresco-discord> <yreg> where you do not need to actually call the constructor

2019-01-08 12:06:47 GMT <AFaust> yeah, but I should find that call in a @Configuration bean somewhere. I have all the JARs included in my IDE, and it can find no references in bytecode anywhere

2019-01-08 12:06:55 GMT <AFaust> Not even references to the class name

2019-01-08 12:07:10 GMT <AFaust> (the impl class name, not the interface, obviously)

2019-01-08 12:08:00 GMT <AFaust> And if Spring has that mojo, why then explicitly mark other beans as @Component or @Service - should work with the same mojo without those annotations, but doesn't...

2019-01-08 12:08:38 GMT <AFaust> Ah... curse you Alfresco and your habit of having some classes outside of the JARs...

2019-01-08 12:09:15 GMT <AFaust> There is a Configuration bean in the WEB-INF/classes/ path that actively calls those constructors

2019-01-08 12:09:51 GMT <AFaust> And those classes are not included in the IDE unless you explicitely add the -classes JAR for that webapp too...

2019-01-08 12:12:21 GMT <AFaust> As always: Thou understandeth if thee debuggeth...

2019-01-08 12:43:35 GMT <alfresco-discord> <douglascrp> has anyone found a solution for this? https://community.alfresco.com/thread/236280-onactionformdialog-closes-even-if-invalid

2019-01-08 12:43:37 GMT <alfbot> Title:onActionFormDialog closes even if invalid | Alfresco Community (at community.alfresco.com)

2019-01-08 12:43:46 GMT <alfresco-discord> <douglascrp> the action form is closed even if the mandatory field is not filled

2019-01-08 12:52:37 GMT <AFaust> That sounds familiar... but I believe we (at current customer) have simply patched the original files to check field validation status before hiding dialog / submit action that hides the dialog

2019-01-08 12:52:58 GMT <alfresco-discord> <douglascrp> it seems I will have to do that too

2019-01-08 12:53:16 GMT <alfresco-discord> <douglascrp> this for is composed of association fields, where the user selecs some users

2019-01-08 12:54:13 GMT <AFaust> It's one of these "thousand issues I could have reported if reporting via JIRA wasn't a colossal waste of time due to rejection / time to convince Alfresco to accept it"

2019-01-08 12:54:45 GMT <alfresco-discord> <douglascrp> 😁

2019-01-08 12:58:35 GMT <alfresco-discord> <dgradecak> @AFaust: I guess it is some spring auto configuration

2019-01-08 12:59:32 GMT <alfresco-discord> <dgradecak> with spring boot I also do a lot of autoconfig and than it is indeed a matter of having the jar on the classpath

2019-01-08 12:59:37 GMT <AFaust> dgradecak: You missed the realisation - it is a @Configuration bean which was not included in one of the JARs (class file directly in the WAR) and thus not found by my IDE when searching the call hierarchy

2019-01-08 13:00:30 GMT <alfresco-discord> <dgradecak> aha I see, that is than a bit problematic

2019-01-08 13:03:56 GMT <AFaust> And to fix this crappy bug I am dealing with at the moment, I have not only to patch the actually affected class, but also that damn @Configuration class. Thanks Spring Boot and your idiotic "Annotation-all-the-things" mantra. (to be read in the same tone as "Thanks Obama")

2019-01-08 13:06:28 GMT <AFaust> @Bean methods in @Configuration classes should be forbidden. At least with regular @Component you can still use a post processor to override their auto-scanned config...

2019-01-08 13:07:13 GMT <AFaust> Though even that requires you to write/touch two classes - the actual patch and a post processor. God, how I miss Spring XML...

2019-01-08 13:40:45 GMT <alfresco-discord> <douglascrp> ok, about my problem on the form, I was able to "fix" it by simply replacing the onActionFormDialog with onActionFormDialogWithSubmitDisable

2019-01-08 14:45:52 GMT <alfresco-discord> <yreg> @Francesco Corti I have a quick APS question for you, is it the responsibility of APS to run sync jobs on one single node of the cluster, or is it the responsibility of the dev/admin to configure only one node to actually perform the sync ?

2019-01-08 15:25:39 GMT <AFaust> It should always be the job of the admin/dev. The job framework can't be smart enough to figure this out on a job-by-job basis automatically and I am not aware of any special code that Alfresco put in to coordinate jobs across a cluster.

2019-01-08 15:26:02 GMT <AFaust> (I realise I am not Francesco Corti, but still wanted to throw my 2 cents in)

2019-01-08 15:26:55 GMT <alfresco-discord> <bhagyas> @AFaust you can probably extend the class :p

2019-01-08 15:27:05 GMT <alfresco-discord> <bhagyas> *on configuration bean

2019-01-08 15:27:43 GMT <alfresco-discord> <Francesco Corti> Thank you AFaust for the support... @yreg, let me know if I can do more.

2019-01-08 15:28:25 GMT <alfresco-discord> <bhagyas> unless, it's marked as final xD

2019-01-08 15:30:22 GMT <AFaust> Extending APS beans is a nuisance - it almost involves semi-dirty Spring hacks (@Primary or post-processor that changes the bean definition) if you want to do it without source patching.

2019-01-08 15:31:04 GMT <AFaust> And yes, of course there are a lot of private members / methods that you may end up duplicating / calling via reflection...

2019-01-08 15:32:54 GMT <alfresco-discord> <bhagyas> Alfresco should have migrated to annotations a long ago, half baked annotations can only make things worse

2019-01-08 15:33:13 GMT <AFaust> @Francesco Corti: I guess even with my answer you can still give a "more official" response...

2019-01-08 15:33:32 GMT <alfresco-discord> <bhagyas> someone should write an article, 10 things you can do with annotations without meddling with a ton of xml in Alfresco :p

2019-01-08 15:34:02 GMT <AFaust> And someone should write the anti-article, 10 things you can do with annotations that will annoy the crap out of anyone wanting to use / extend your product.

2019-01-08 15:34:41 GMT <alfresco-discord> <bhagyas> With SDK 3, you can forget extensions altogether :p

2019-01-08 15:34:53 GMT <alfresco-discord> <bhagyas> So I don't see why they should stick with xml anymore xD

2019-01-08 15:36:11 GMT <Tichodroma> what kind of extensions? this is quite a broad term

2019-01-08 15:36:16 GMT <AFaust> Annotations aren't a silver bullet, and using annotations for hard-coding component wiring when interface-based components may need to be swapped at runtime, potentially by multiple extensions (so some magic single "provider" approach also wouldn't work)

2019-01-08 15:36:48 GMT <alfresco-discord> <bhagyas> Tichodrama, the kind that makes Alfresco usable to many customers

2019-01-08 15:36:50 GMT <alfresco-discord> <bhagyas> 😄

2019-01-08 15:37:00 GMT <Tichodroma> ha

2019-01-08 15:37:28 GMT <Tichodroma> do you talk about JAR modules that until 5.x where put into $ALFRESCO/modules/{platform,share} ?

2019-01-08 15:37:36 GMT <Tichodroma> or AMPs? or ...

2019-01-08 15:39:34 GMT * AFaust realises he is missing the second half of the statement in his last message....

2019-01-08 15:40:02 GMT <AFaust> [...] should be considered offensive / a crime against common sense...

2019-01-08 15:57:05 GMT <alfresco-discord> <dgradecak> @AFaust: I might be mistaken, but I am sure alfresco is doing as much as they can to discourage extending their products

2019-01-08 15:58:00 GMT <alfresco-discord> <dgradecak> so probably writing "micro services" that do some integrations with their product is what they want in the futre, just my understanding of what will happen in the future

2019-01-08 15:58:18 GMT <AFaust> Not "as much as they can", but actively limiting it is part of the long term strategy (as publicly communicated, so no surprise to anyone)

2019-01-08 15:59:02 GMT <AFaust> Though it remains to be seen if they can provide a microservice-based architecture that can actually support the diverse range of use cases and requirements of users / customers.

2019-01-08 15:59:32 GMT <alfresco-discord> <dgradecak> well that is up to us to do it I guess

2019-01-08 15:59:43 GMT <alfresco-discord> <dgradecak> they already did it with APS ...

2019-01-08 15:59:52 GMT <AFaust> I still have my strong doubts with regards to key concepts like transactionality / atomicity / consistency. it appears that nowadays those are typically willingly ignored in cloud-native approaches...

2019-01-08 16:00:28 GMT <alfresco-discord> <dgradecak> indeed, unfortunately. but I am also reconsidering how I write alfresco based applications lately

2019-01-08 16:00:42 GMT <AFaust> APS was an accident. It is an internal proof of concept product that at some point some business people decided could be unleashed on users / customers.

2019-01-08 16:00:49 GMT <alfresco-discord> <dgradecak> but transactionality wise, there is not much to do

2019-01-08 16:01:50 GMT <AFaust> APS is such a hack in some parts, lacking clear design / architecture, that I can't even take seriously the idea that there was a deliberate strategy to limit extensibility.

2019-01-08 16:02:49 GMT * AFaust likes to stick to Hanlon's_razor

2019-01-08 16:03:28 GMT <alfresco-discord> <dgradecak> so ACID in the scope of ACS is indeed going to be droped out at some point, mainly the custom business logic should not be written in alfresco anymore

2019-01-08 16:03:37 GMT <alfresco-discord> <dgradecak> what I sued to do a lot

2019-01-08 16:05:18 GMT <AFaust> I does not matter were logic is written. If I have a non-trivial, multi-step operation to be performed, interacting with more than a single document/folder, which requires that either everything succeeds or nothing is changed, without any other process being able to interfere, that needs to be supported somehow...

2019-01-08 16:06:54 GMT <AFaust> And my client should not need to be aware of how many steps / micro-services are involved in a specific operation, or have to check for each intermediate state to report on the progress...

2019-01-08 16:08:28 GMT <AFaust> I mean, sure, they can (and probably will) drop ACID completely.... It will be interesting to see what sort of home-baked hacks / helpers people will end up writing in this case (provided they are not dropping the "inconsistent by design" product) to deal with that...

2019-01-08 16:38:05 GMT <AFaust> Hmm... I rarely (almost never) use web services. But my current customer has a custom transformer using web services. Is there really not a more memory efficient means of handling binary data than using in-memory byte arrays?

2019-01-08 16:38:49 GMT <AFaust> Looking at ~150 MiB memory use for request and response, all stored on Java heap. And so far I can't find any mention of using ByteBuffer instead on the interwebs...

2019-01-08 16:39:53 GMT <angelborroy> Serialization happens in XML

2019-01-08 16:40:13 GMT <angelborroy> if you don’t use Doc Attachment, all content is represented as a byte array in memory

2019-01-08 16:40:30 GMT <angelborroy> do yes, this is a common scenario

2019-01-08 16:41:24 GMT <angelborroy> I don’t know if Alfresco used MTOM or SWA

2019-01-08 16:41:34 GMT <angelborroy> both are available from last Century

2019-01-08 16:43:59 GMT <AFaust> Well... should not matter what Alfresco uses since we are not talking about an Alfresco web service here. Just some web service that custom code at the customer happens to call to transform a content on a different server by a proprietary product

2019-01-08 16:44:43 GMT <AFaust> They are using a regular JAX-WS generated interface and I guess standard Java APIs to perform the call. Nothing fancy..

2019-01-08 16:45:59 GMT <AFaust> And I actually don't care about the size of the transport XML. I just can't believe it can't be constructed / sent in a "streaming" way with data held in an off-heap byte buffer.

2019-01-08 16:48:46 GMT <AFaust> Due to those ~150 MiB (or larger) byte arrays in memory, we have some infrequent out-off-memory errors in the log and heap dumps on disk. Likely as the result of a related allocation failure where a copy / additional data no longer fits in a specific section of the heap (though the heap in total has sufficiently free space)

2019-01-08 16:55:12 GMT <angelborroy> share this link with them:

2019-01-08 16:55:13 GMT <angelborroy> https://www.mkyong.com/webservices/jax-ws/jax-ws-attachment-with-mtom/

2019-01-08 16:55:14 GMT <alfbot> Title:JAX-WS attachment with MTOM – Mkyong.com (at www.mkyong.com)

2019-01-08 16:55:38 GMT <angelborroy> They have just to stream the content

2019-01-08 16:57:22 GMT <AFaust> One problem though: They don't control the web service / server implementation. It is a proprietary product.

2019-01-08 16:57:29 GMT <angelborroy> wow

2019-01-08 16:59:29 GMT <angelborroy> So probably you can provide some manipulation at transport level, but it could be hard to make all the transformations

2019-01-08 16:59:36 GMT <AFaust> And again, I don't care about how it is handled on the transport layer. Regardless of whether the content is embedded in the XML or put into a separate mimemessage section of the HTTP body, a decent client should be able to build the HTTP body for the SOAP request in a streaming manner (and even read responses in a streaming manner)...

2019-01-08 16:59:38 GMT <angelborroy> I made something similar some years ago http://cxf.apache.org/docs/interceptors.html

2019-01-08 16:59:39 GMT <alfbot> Title:Apache CXF -- Interceptors (at cxf.apache.org)

2019-01-08 17:02:34 GMT <AFaust> Or at least during message processing store the binary data in an off-heap buffer while the rest of the message is processed, so that - at any point - it is not necessary to hold the entirety of the message in-memory.

2019-01-08 17:03:44 GMT * AFaust knew that web services / SOAP were a tremendous cluster frak, but did not realise it came down to such simple aspects like "using runtime memory somewhat-efficiently"

2019-01-08 17:07:02 GMT <angelborroy> In Spain the Government published a law to share expedients between local entities

2019-01-08 17:07:17 GMT <angelborroy> They designed the whole system with SOAP without attachments

2019-01-08 17:07:20 GMT <angelborroy> That was 2010

2019-01-08 17:08:04 GMT <angelborroy> Now they “invented” a reference system to include binary files “related to” a XML

2019-01-08 17:08:29 GMT <angelborroy> I tried to explain them (10 years ago) that using standards (like MTOM) could be a nice idea

2019-01-08 17:08:53 GMT <angelborroy> But you know, it’s always better to fix “things” with local “inventions”

2019-01-08 17:09:25 GMT <angelborroy> (obviously 1 expedient can include 1 TB or so in storage)

2019-01-08 17:15:31 GMT <angelborroy> Sorry, I tried to warn them in 2012

2019-01-08 17:15:32 GMT <angelborroy> https://angelborroy.wordpress.com/2012/08/31/eni-transmision-de-ficheros-en-el-esquema-del-documento-electronico/

2019-01-08 17:15:33 GMT <alfbot> Title:ENI – Transmisión de ficheros en el esquema del Documento Electrónico | Programming and So (at angelborroy.wordpress.com)

2019-01-08 17:19:25 GMT <AFaust> Hmm... so since I can't use any of the mentioned techniques since they require changes to both ends, and there is no client with streaming, off-heap XML construction support, I'll have to focus on incident rate reduction...

2019-01-08 17:19:43 GMT <angelborroy> I guess so

2019-01-08 17:20:37 GMT <AFaust> Since our server(s) have 8G heap, having those two 150MiB (or larger) byte arrays should not normally cause an issue. Even at the time of the errors I am looking at now, we only had at most 2 GiB of 8 GiB heap used...

2019-01-08 17:21:17 GMT <angelborroy> It’s a pain for the memory, but also for the CPU

2019-01-08 17:21:42 GMT <AFaust> So it likely must be an issue with allocating a large-ish contiguous region of heap rather than the amount required, that triggers the error..

2019-01-08 17:21:42 GMT <angelborroy> XML object is built in memory (including a node of 149 MB size)

2019-01-08 17:23:05 GMT <AFaust> Yeah, but a "modern" implementation would not have to build it in heap memory, and could Java NIO features to do that (of course if enabled via config - default behaviour should not require off-heap memory)

2019-01-08 18:06:16 GMT <alfresco-discord> <Shibak Tensai> In alfresco what is node.js primarily used for?

2019-01-08 18:15:32 GMT <alfresco-discord> <edw24> Is there a way to use the Javascript console and search.query and return > 1000 nodes?

2019-01-08 18:50:41 GMT <alfresco-discord> <douglascrp> @edw24 https://www.youtube.com/watch?v=pnaW_4ZNUAY

2019-01-08 19:12:17 GMT <alfresco-discord> <edw24> Thanks @douglascrp

End of Daily Log

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