Mw extension ;)

Le 2 févr. 2018 21:03, "Mark Struberg" <strub...@yahoo.de> a écrit :

> With 'Extension' do you mean CDI Extension?
>
> I was thinking about this the other day and thought it might be cool to
> have an exclude list in OWB directly.
> So with the openwebbeans.properties you might be able to have a list of
> fqcn of the Extensions to ignore.
>
> Not sure whether this is in the direction you were thinking.
>
> LieGrue,
> strub
>
> > Am 02.02.2018 um 15:12 schrieb Aaron Anderson <aaronander...@acm.org>:
> >
> > Hi Mark,
> >
> > My experience with creating a contribution was overall positive. I did
> encounter a few of issues that I had to work around:
> >
> > 1) meecrowave.properties and CLI binding - I have several options
> classes that I registered as Cli.Options service loader extensions and I
> was able to obtain the commandline provided values without a problem.
> However additionally I wanted to bind meecrowave.properties values to the
> same options instance so I could access both the CLI values and configured
> values. From what I can tell the CLI values and properties are mutually
> exclusive, i.e. one can't override a properties file set value with a CLI
> value like in most apps. In any event when I tried to include my extension
> options in meecrowave.properties they were never available either before or
> after meecrowave started. I ended up creating a separate properties file
> and manually loading it using builder.setProperties(myProperties) and
> then builder.getExtension(CliExtOptions.class);
> >
> > 2) Add support of interfaces for extensions - I have several plugable
> interfaces I am using and it would have been nice to be able to register
> extensions instead of the extension automatically being instantiated. For
> example builder.addExtension(MyInterface.class,MyImplObject) and
> builder.getExtension(MyInterface.class) != null? .... Right now a
> reference to the concrete implementation class always needs to be retained
> to lookup an extension.
> >
> > 3) CDI support for objects instantiated in the extention - This was by
> far my biggest headache and I spent a couple of hours trying to get this to
> work. Basically I wanted to create a single instance of my OAuthClient that
> was configured via properties and have that be injectable into the running
> application. I wanted a configuration exactly like OWBAutoSetup,java that
> registers Meecrowave and it's builder as being injectable. I tried multiple
> attempts of adding a Tomcat listener to call the
> WebBeansContext.getInstance() in the right classloader with the same
> beanManager.addInternalBean logic but my listener was always called too
> late. This is where my request to allow extensions to add
> servletcontextlisteners originated from.
> >
> >
> > I ended up creating a CDI extension that works around the issue by
> leveraging the Meecrowave extension feature to lookup the configured
> instance:
> >
> > public class WebAuthenticatorCDIExtension implements Extension {
> >       WebAuthenticator webAuthenticator;
> >
> >
> >       //I am not sure how OAuth2WebAuthenticator was discovered by
> openwebbeans but it needs to be vetoed to avoid an ambiguous dependency
> exception with the unmanaged bean below.
> >       void processAnnotatedType(@Observes 
> > ProcessAnnotatedType<OAuth2WebAuthenticator>
> pat) {
> >               pat.veto();
> >       }
> >
> >       void addBeans(@Observes final AfterBeanDiscovery afb, final
> BeanManager bm) {
> >               afb.addBean().beanClass(WebAuthenticator.class).scope(
> ApplicationScoped.class).types(WebAuthenticator.class,
> Object.class).qualifiers(DefaultLiteral.INSTANCE).createWith(cc -> {
> >                       return webAuthenticator;
> >               });
> >
> >       }
> >
> >       void initBeans(@Observes final AfterDeploymentValidation adv,
> final BeanManager bm) {
> >               //copied from JPA Extension
> >               try {
> >                       final ServletContext sc =
> ServletContext.class.cast(bm.getReference(bm.resolve(bm.
> getBeans(ServletContext.class)), ServletContext.class,
> bm.createCreationalContext(null)));
> >                       Meecrowave.Builder config =
> Meecrowave.Builder.class.cast(sc.getAttribute("meecrowave.
> configuration"));
> >                       ResourceFinder finder = new
> ResourceFinder("META-INF/services/");
> >                       Class<?> webAuthenticatorImpl =
> finder.findImplementation(WebAuthenticator.class);
> >                       if (webAuthenticatorImpl != null) {
> >                               webAuthenticator = (WebAuthenticator)
> config.getExtension(webAuthenticatorImpl);
> >                       }
> >               } catch (Exception e) {
> >                       adv.addDeploymentProblem(e);
> >               }
> >       }
> >
> > }
> >
> > Is there a better  way to expose extension instances to the application
> for injection? Is there a way to add other instances to the ServletContext?
> >
> > Regards,
> >
> > Aaron
> >
> >
> > On Friday, February 2, 2018 2:18 AM, Mark Struberg <strub...@yahoo.de>
> wrote:
> >
> >
> > Hi Aaron!
> >
> > This sounds like extremely useful work!
> > I hope you enjoyed digging into OWB and Meecrowave and of course we do
> highly welcome your contributions back to the project :)
> >
> > Is the code available anywhere already?
> > Looking forward to work with you!
> >
> > @Romain incubator whould be an overkill for now I think.
> > I agree that such an update mechanism might become more generic in the
> end.
> > But I'd still start with it over here and then if it works fine we can
> extract it out into a component and make it more reusable.
> >
> > >> 6) Finally I built a simple CLI release manager that queries the
> local maven repository for version
> > >> information and then injects version manifest files into a copy of
> the selected artifacts, jar signs them,
> > >> and then uploads them to a central server. Currently my release
> manager uploads the update files
> > >> to an AWS S3 bucket that my server application reads from but I can
> adjust it to publish to an SFTP server.
> > >
> > > Guess we will stick to maven/nexus/artifactory for this kind of things
> to avoid a custom
> > > implementation and costly one (s3 is quickly too expensive)
> >
> > Yes, using something like Nexus or Archiva might be perfectly fine.
> > But I'd be not so quick judging before knowing Aarons exact use case.
> >
> >
> > > Just to make sure we are on the same page I am proposing that this
> desktop extension would
> > > be packaged like the other component extensions, distributed in a
> separate jar
> >
> > +1
> >
> > > While Maven artifacts are a good fit for build management artifact
> resolution it is very complex and
> > > requires a large number of dependencies making it less than ideal for
> software asset provisioning
> >
> > Yes, Maven is surely more complex than needed for just file serving.
> > Otto it's a standard infrastructure item which doesn't require any
> maintenance.
> > Btw re Maven: we might enhance our meecrowave-maven-plugin to package up
> and deploy such a 'release'.
> > Regardless whether this is handled as attached-artifacts in a Maven repo
> or done via scp, sftp, etc.
> > Again: would need to dig deeper to understand the exact need and
> solution.
> >
> >
> >
> > txs and LieGrue,
> > strub
> >
> >
> > > Am 01.02.2018 um 07:19 schrieb Aaron Anderson <aaronander...@acm.org>:
> > >
> > > Hi Meecrowave developers and users,
> > >
> > > I am nearly finished working on a Meecrowave extension for enhancing
> Meecrowave to be a desktop platform. Here is some background on my work:
> > >
> > > For some time I have been working on a desktop application that
> manages very sensitive data. The data it manages must be encrypted at rest
> and requires password authentication to start it. The application cannot be
> Cloud based. The application will be used by several dozen users so it
> needs to have an update mechanism where I can push out updates.  I can't
> make the application purely JavaScript/Browser base since I need to use
> some Java libraries to access and manipulate the data.
> > >
> > > I am familiar with Applets and Java WebStart  but those are now dead
> technologies. I actually built out an application using e(fx)clipse which
> is based on JavaFX and the eclipse RCP platform but my update libraries are
> behind an oauth protected web site and it took a tremendous amount of work
> to get the update site feature to work. It was also laborious for me to
> build the UI in JavaFX since that requires specialized knowledge that I
> don't use day to day.
> > >
> > > This brings me to Meecrowave. In the past I have used several
> commercial Windows applications that actually ran Tomcat as a service to
> render their presentation view for their application. I am also working on
> a server side application as well so using the same UI framework (Polymer)
> on both the client and server is appealing to me.
> > >
> > > I started to build my client application using WildFly-Swarm but the
> file size (130mb) was a little extreme considering I wanted support
> frequent updates. Meecrowave addressed all of my concerns with cutting edge
> API support, quick startup times, and small dependency sizes (25mb for my
> runner and 11mb for my application).
> > >
> > > Now getting to my potential contribution, I have added several
> features to Meecrowave to make it more desktop friendly:
> > >
> > > 1) System Tray - If one runs the Meecrowave jar as a java application
> it runs in the background and there is visible cue it is accessible. I used
> the Java AWT system tray to add an icon with a shutdown option to cleanly
> shutdown the server.
> > >
> > > 2 Browser launch - Again I used the AWT desktop API provided with Java
> to launch a browser instance to open the applications home page once the
> application is started.
> > >
> > > 3) Interactive Authentication with Derby - As I mentioned my
> application requires local authentication in order to decrypt the data. I
> built several Java swing forms for password creation, change, and
> authentication. These credentials are used to create or start an embedded
> Apache Derby database using AES 256 encryption.
> > >
> > > 4) OAuth Client Support - My application updates and remote resources
> are protected by an OIDC OAuth IDP so I built in a local OAuth JAX-RS
> client that manages refresh tokens in the Apache derby database. There are
> several examples of using CXF as an OAuth server but there is hardly any
> documentation on using CXF with a pure JAX-RS 2.0 client to interact with
> OAuth systems.
> > >
> > > 5) Update support - I built an update process that can independently
> update the runner jar and application war. It performs several actions like
> checking the local versions, fetching a version manifest file from a remote
> protected HTTPS server, downloading updated jar files, and rendering
> several Java swing forms to display the update status in real time.
> > >
> > > 6) Finally I built a simple CLI release manager that queries the local
> maven repository for version information and then injects version manifest
> files into a copy of the selected artifacts, jar signs them, and then
> uploads them to a central server. Currently my release manager uploads the
> update files to an AWS S3 bucket that my server application reads from but
> I can adjust it to publish to an SFTP server.
> > >
> > >
> > > I have tested these enhancements on both Linux and Windows. The system
> tray doesn't work on my Linux system very well but everything else does. I
> also had contributing this code in mind when I developed it so I tried to
> make everything plugable and configurable.
> > >
> > > Please let me know if there is any interest in having these features
> contributed to the Meecrowave project as an extension. If so I can start to
> work on a github pull request.
> > >
> > > Regards,
> > >
> > > Aaron
> >
> >
>
>

Reply via email to