Open maybeec opened 7 years ago
It seems that the performance issue is just present in an osgi environment.
@maybeec wrote:
It seems that the performance issue is just present in an osgi environment.
That would explain why I hadn't noticed it! I wanted to use DI for the validation code, partly to achieve separation of base parsing from validation of the parsed result. It also makes it possible for users to create custom validators, e.g. to enforce in-house naming policies, etc.
Do you recommend a lighter-weight alternative to guice?
Dagger 2 might be worth a try. It removes the reflection overhead by utilizing code generation at compile time. It is even guice compatible as far as I know. So hopefully no migration overhead at all.
Thanks, @maybeec, I'll take a look.
It's also quite slow for me starting up. About four seconds before it gets to the point where the code in my main class starts executing. This is starting the application from the Eclipse IDE on my Mac.
@KevinMitchell Is your app also osgi-based, as @maybeec reported?
No, just a vanilla Java SE app.
On 1 Oct 2017, at 16:16, Andy Lowry notifications@github.com wrote:
@KevinMitchell https://github.com/kevinmitchell Is your app also osgi-based, as @maybeec https://github.com/maybeec reported?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RepreZen/KaiZen-OpenApi-Parser/issues/66#issuecomment-333383613, or mute the thread https://github.com/notifications/unsubscribe-auth/AE_sQRtpIDXwjcAILeplE7E-_OguRKwLks5sn6zhgaJpZM4PL0lB.
btw. do you need guice across osgi bundles?
just saw https://github.com/google/guice/wiki/ClassLoading and it is possible to disable the guice custom class loading by the guice_custom_class_loading
parameter. Maybe this can make a difference.
I was trying to use Dagger 2, however, you are using some annotations, which does not have any semantic replacement in dagger.
See the fork of your parser, which has been reworked to remove a log of dependencies, especially the one's with problematic licenses: https://github.com/networknt/openapi-parser It especially replaces guice and java mail API.
Any chance to make the parser libraries more lightweight? I also detected, that there are multiple redundant dependencies since the extraction of jsonoverlay. Maybe you want to clean up your dependencies once more.
@maybeec , we're hard at work on other things at the moment, but I expect we will circle back and give you a proper response on these questions next week.
btw we are using the openapi-parser in CobiGen devonfw/tools-cobigen, which is open source now. Unfortunately, we cannot release it as an update site to the public currently as of the license issues with the open api parser. Nontheless, a maven plugin it is already published to maven central.
We observed a very slow initialization of the parser as of google guice. On initialization of the OpenAPI 3 parser, we are facing a huge delay. As debugging is a little hard without source bundles, I can just guess from what I could see. I finally found google guice to be initialized, which causes seconds of delay. Can you confirm this? Is there any option to skip the usage of google guice or at least make it more performant? Google guice is a heavy weight framework, which most often comes with unnecessary overhead.