The bottom line is that there are no use cases for which OSGi is a bad
decision as far as we're all concerned :)

The assembly model also part of your choice. It matters really more what
you like best, what gives you the best mileage for your usage.

- Ray

On Wed, Sep 19, 2018 at 10:39 AM Philipp Höfler <
philipp.hoef...@pernexas.com> wrote:

> Hallo Ray,
>
> thank you very much.
> I already found the Aries JMX dependency, but I was exactly missing the
> MBeanService.
> That's why it didn't worked for me.
>
> Thanks, now I can connect with VisualVM __
> I can now proceed with testing ...
>
> It's off topic, but I have to ask one last question:
> Would you recommend using "classic" OSGi with a container for an
> application like mine?
> It is connecting two systems with different APIs. It will always run on a
> server.
> Honestly, when starting the application I was not aware that enRoute was
> built to make standalone apps. Now, as I am getting a better understand
> (probably still not too good understanding) I am questioning this decision.
>
> Philipp
>
>
> Am 19.09.18, 16:21 schrieb "Raymond Auge" <raymond.a...@liferay.com>:
>
>     I added gogo for good measure to help diagnosing issues.
>
>     Aries JMX has this weird requirement that someone has to provide the
>     MBeanService service, which I did for you.
>
>     - Ray
>
>     On Wed, Sep 19, 2018 at 10:19 AM Raymond Auge <
> raymond.a...@liferay.com>
>     wrote:
>
>     > I just sent a PR to your osgi-test repo adding JMX.
>     >
>     > Also, enRoute was most certainly not limited to desktop apps.
>     >
>     > In fact there are several consumers using it specifically for
>     > "microservices" story.
>     >
>     > - Ray
>     >
>     > On Wed, Sep 19, 2018 at 10:12 AM Jean-Baptiste Onofré <
> j...@nanthrax.net>
>     > wrote:
>     >
>     >> Hi,
>     >>
>     >> I think you can achieve this with enRoute (even if I would not do
> that
>     >> way personnally).
>     >>
>     >> As it seems you want to do kind of integration, I would evaluate
> using
>     >> Apache Camel routes running Karaf.
>     >> Camel is an integration framework that allow you to easily integrate
>     >> system all together.
>     >>
>     >> Let me know if you need some details (you can ping me directly on my
>     >> e-mail to avoid to "flood" the Felix mailing list).
>     >>
>     >> Regards
>     >> JB
>     >>
>     >> On 19/09/2018 16:06, Philipp Höfler wrote:
>     >> > Thanks, it is getting clearer to me.
>     >> > Would you recommend using enRoute for a server application
> translating
>     >> rest requests to CMIS?
>     >> > Now with these information, it feels like enRoute was built for
> desktop
>     >> standalone apps not for server applications?
>     >> >
>     >> > Best,
>     >> > Philipp
>     >> >
>     >> >
>     >> > Am 19.09.18, 15:44 schrieb "Jean-Baptiste Onofré" <
> j...@nanthrax.net>:
>     >> >
>     >> >      Hi Philip,
>     >> >
>     >> >      For Karaf, you probably have to install the dependency
> bundles
>     >> first.
>     >> >
>     >> >      Using enRoute, it creates an "uber" jar embedding all jar
> files
>     >> required
>     >> >      for execution. You don't need a container: it's a regular
>     >> standalone jar
>     >> >      application that you run with java -jar.
>     >> >
>     >> >      Karaf uses a modular approach where your bundles are very
> light,
>     >> and you
>     >> >      install dependency bundles in Karaf (that other bundles can
> use).
>     >> That's
>     >> >      why we have Karaf Features to install all in a row.
>     >> >
>     >> >      So, if you are interested by Karaf, I can help you to create
> a
>     >> Karaf
>     >> >      feature for your application or at least provide the
> commands you
>     >> should
>     >> >      do to install the dependency bundles.
>     >> >
>     >> >      Regards
>     >> >      JB
>     >> >
>     >> >      On 19/09/2018 15:38, Philipp Höfler wrote:
>     >> >      > Hallo Ray, hallo JB,
>     >> >      >
>     >> >      > thanks for your reply :-).
>     >> >      >
>     >> >      > Maybe I have not clearly described the problem. I think you
>     >> might have misunderstood it.
>     >> >      > When compiling the application, the runable app.jar will be
>     >> generated. This is working fine. All dependencies are in place and
> I can
>     >> start it.
>     >> >      >
>     >> >      > Unfortunately, I am facing performance issues. Probably,
> these
>     >> are related to the CMIS connection, but I would like to find the
> bottle
>     >> necks by monitoring the app.
>     >> >      > My first approach was, to connect VisualVM to the packaged
> app.
>     >> But - at least for me - it was not possible.
>     >> >      >
>     >> >      > Then, I followed JB's suggestion to use Karaf. But I've
> problems
>     >> to deploy the app to Karaf as I see missing dependencies.
>     >> >      >
>     >> >      > I think I do not get the big picture here.
>     >> >      > Based on JB's latest reply, I assume that with enRoute I
> do not
>     >> have to use any container like Karaf?
>     >> >      > enRoute is for building standalone apps?
>     >> >      > When using the "classic" OSGi it would be necessary to use
> an
>     >> container, right?
>     >> >      >
>     >> >      > Is the runnable jar the way of deploying enRoute apps?
>     >> >      > My understand was, that this is used for testing and it
> should
>     >> be deployed to an application server / container like Karaf.
>     >> >      >
>     >> >      > Best,
>     >> >      > Philipp
>     >> >      >
>     >> >      > Am 19.09.18, 15:31 schrieb "Jean-Baptiste Onofré" <
>     >> j...@nanthrax.net>:
>     >> >      >
>     >> >      >      Hi,
>     >> >      >
>     >> >      >      Using enRoute, I guess you want to have an executable
> jar.
>     >> In that case,
>     >> >      >      you don't need Karaf.
>     >> >      >
>     >> >      >      As an alternative, you can package your application as
>     >> "pure" OSGi
>     >> >      >      bundles (and eventually release), and deploy on Karaf
> or
>     >> package with Karaf.
>     >> >      >
>     >> >      >      Packaging with Karaf will give you an execute archive.
>     >> >      >
>     >> >      >      Regarding log, you are right, Karaf provides a log
> service
>     >> abstracting
>     >> >      >      lot of different frameworks. The only thing you have
> to do
>     >> is to import
>     >> >      >      the package of the logging framework you are using
>     >> (logback, slf4j,
>     >> >      >      whatever).
>     >> >      >
>     >> >      >      Regards
>     >> >      >      JB
>     >> >      >
>     >> >      >      On 19/09/2018 15:15, Philipp Höfler wrote:
>     >> >      >      > Hallo JB,
>     >> >      >      >
>     >> >      >      > thanks for your kind reply.
>     >> >      >      >
>     >> >      >      > I am getting confused :-)
>     >> >      >      > I am quite new to the OSGi world, so my questions
> are
>     >> probably very basic.
>     >> >      >      >
>     >> >      >      > I am not sure, if I can use Karaf just like that,
> as I am
>     >> using OSGi enRoute R7.
>     >> >      >      > As far as I understood, it's not finally released
> yet? So
>     >> I guess, that Karaf does it not support yet?
>     >> >      >      >
>     >> >      >      > Anyhow, I tried to deploy my app on Karaf. And
> there are
>     >> a lot of missing dependencies.
>     >> >      >      > How is the best way of deploying a OSGi app? I've
> three
>     >> bundles and each have different dependencies.
>     >> >      >      > The packaged app jar, that is generated from the
> enRoute
>     >> example project, packs all these dependencies in a jar folder of
> the app.jar
>     >> >      >      > What I do not understand is, why dependencies like
>     >> "org.osgi.framework" or "org.osgi.service.log" is missing. I
> though, that
>     >> would be provided by Karaf?
>     >> >      >      >
>     >> >      >      > I recently added logging via the new OSGi Logging
>     >> standard and logback. I read on the Karaf website, that Karaf can
> already
>     >> unify the logging configuration.
>     >> >      >      > As I understood, logback is also trying to unify the
>     >> configuration over all popular logging frameworks. Does it just
> work or do
>     >> I have to adapt anything?
>     >> >      >      >
>     >> >      >      > Thanks for your help,
>     >> >      >      > Philipp
>     >> >      >      >
>     >> >      >      > Am 19.09.18, 14:17 schrieb "Jean-Baptiste Onofré" <
>     >> j...@nanthrax.net>:
>     >> >      >      >
>     >> >      >      >      Hi Philip,
>     >> >      >      >
>     >> >      >      >      You can use Karaf as a container. It supports
>     >> different programming
>     >> >      >      >      model including OSGi of course.
>     >> >      >      >
>     >> >      >      >      Karaf supports Aries JMX and MBean whiteboard
>     >> pattern to simplify the
>     >> >      >      >      way of exposing your MBeans (it's just
> registering a
>     >> MBean service).
>     >> >      >      >
>     >> >      >      >      Once done, you can use Karaf Decanter to
> collect the
>     >> metrics and have
>     >> >      >      >      monitoring/BAM/alerting.
>     >> >      >      >
>     >> >      >      >      Don't hesitate to ping me if you need more
> details.
>     >> >      >      >
>     >> >      >      >      Regards
>     >> >      >      >      JB
>     >> >      >      >
>     >> >      >      >      On 19/09/2018 12:34, Philipp Höfler wrote:
>     >> >      >      >      > Hi,
>     >> >      >      >      >
>     >> >      >      >      > I've setup a small OSGi application.
>     >> >      >      >      > The application gets some REST requests and
>     >> forwards these requests to a content repository using CMIS.
>     >> >      >      >      > So, basically the app consists of three
> bundles.
>     >> The first bundle provides and RESTful webservice (HTTP Whiteboard),
> the
>     >> second the CMIS connection to the repository and the third is the
> internal
>     >> API between the other two bundles.
>     >> >      >      >      >
>     >> >      >      >      > Now, I am encountering performances problems.
>     >> Storing documents to the repository, is quite slower than it should
> be.
>     >> >      >      >      > I thought it would be a good idea, to
> monitor the
>     >> application to identify the bottle necks.
>     >> >      >      >      > That's why I would like to connect VisualVM
> (or
>     >> JConsole) via JMX.
>     >> >      >      >      >
>     >> >      >      >      > Right now the application is not finished
> yet, so
>     >> the deployment does not exists.
>     >> >      >      >      > I am currently using the bundled app from the
>     >> enRoute R7 example project for testing.
>     >> >      >      >      >
>     >> >      >      >      > Is it a realistic to use the bundled app for
> tests
>     >> or is an application server like Karaf faster?
>     >> >      >      >      > Is it possible to connect to the JMX of the
>     >> bundled app? Would you recommend using Karaf (application server)?
>     >> >      >      >      >
>     >> >      >      >      > When you do recommend Karaf, how can I
> deploy my
>     >> app to the application server?
>     >> >      >      >      > Do I have to install every single bundle?
>     >> >      >      >      >
>     >> >      >      >      > As always, thanks for your help.
>     >> >      >      >      > Philipp
>     >> >      >      >      >
>     >> >      >      >      >
>     >> >      >      >      >
>     >>
> ---------------------------------------------------------------------
>     >> >      >      >      > To unsubscribe, e-mail:
>     >> users-unsubscr...@felix.apache.org
>     >> >      >      >      > For additional commands, e-mail:
>     >> users-h...@felix.apache.org
>     >> >      >      >      >
>     >> >      >      >
>     >> >      >      >
>     >>
> ---------------------------------------------------------------------
>     >> >      >      >      To unsubscribe, e-mail:
>     >> users-unsubscr...@felix.apache.org
>     >> >      >      >      For additional commands, e-mail:
>     >> users-h...@felix.apache.org
>     >> >      >      >
>     >> >      >      >
>     >> >      >      >
>     >> >      >      >
>     >> >      >      >
>     >>
> ---------------------------------------------------------------------
>     >> >      >      > To unsubscribe, e-mail:
>     >> users-unsubscr...@felix.apache.org
>     >> >      >      > For additional commands, e-mail:
>     >> users-h...@felix.apache.org
>     >> >      >      >
>     >> >      >
>     >> >      >
>     >>
> ---------------------------------------------------------------------
>     >> >      >      To unsubscribe, e-mail:
> users-unsubscr...@felix.apache.org
>     >> >      >      For additional commands, e-mail:
>     >> users-h...@felix.apache.org
>     >> >      >
>     >> >      >
>     >> >      >
>     >> >      >
>     >> >      >
>     >>
> ---------------------------------------------------------------------
>     >> >      > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>     >> >      > For additional commands, e-mail:
> users-h...@felix.apache.org
>     >> >      >
>     >> >
>     >> >
>     >>
> ---------------------------------------------------------------------
>     >> >      To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>     >> >      For additional commands, e-mail: users-h...@felix.apache.org
>     >> >
>     >> >
>     >> >
>     >> >
>     >> >
> ---------------------------------------------------------------------
>     >> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>     >> > For additional commands, e-mail: users-h...@felix.apache.org
>     >> >
>     >>
>     >>
> ---------------------------------------------------------------------
>     >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>     >> For additional commands, e-mail: users-h...@felix.apache.org
>     >>
>     >>
>     >
>     > --
>     > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>     >  (@rotty3000)
>     > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>     >  (@Liferay)
>     > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>     > (@OSGiAlliance)
>     >
>
>
>     --
>     *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>      (@rotty3000)
>     Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>      (@Liferay)
>     Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
>
>

-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Reply via email to