river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Heads-up - Trying out Maven and git for the container.
Date Sun, 02 Jun 2013 04:58:20 GMT
Hi Greg,

I noticed while reading your docs, you've got a java policy parser planned, there's a parser
in org.apache.river.api.security (package private) that fully supports java policy file syntax,
including undocumented features, as well as PermissionGrant, which makes policy implementation
simpler, easier to implement and is also non blocking, so policy deadlock can be avoided.

The PolicyParser interface is public, to allow alternate parsers, such as xml, or encrypted
policy files.

In future I also plan to implement a parser for OSGi syntax permission.perm in jar files as
previously discussed on the list.

Perhaps we might have some common use cases?

Regards,

Peter.

----- Original message -----
> Hi all:
>
> As you know, I've been working for some time on a container for Jini
> services.  This work started out as a Surrogate container, but has
> migrated to be a generic container that has similar goals to the old
> Harvester project on jini.org.  To wit:
>
> - Provide a simplified deployment environment (simpler than the
> com.sun.jini.Start mechanism)
> - Host multiple services in one VM.  e.g.  reggie plus business
> services.
> - Handle the task of serving codebase jars without asking much of the
> developer
> - Handle the classpath without asking much of the developer.
> - Provide a platform on which to develop better deployment standards
> - Provide an implementation of the Surrogate spec.
> - Allow for service containers on one machine, by auto-allocating
> codebase ports
>
> The work has been contained up to now in the jtsk/skunk/surrogate
> branch.  It has reached a point of relative feature-completeness where
> I'm now comfortable inviting review and participation from other River
> developers.
>
> In light of recent discussions about git I thought I'd try it out, so
> I've moved the bulk of the project into a git repository at
> git://github.com/trasukg/river-container.  Eventually of course, the
> nascent Apache git server will hold the canonical copy.
>
> At the same time I'm migrating to Maven.  Here's where I need the
> services of someone a little more experienced with Maven than I am.
> Could someone tell me if I'm on the right or wrong track?
>
> I've setup a multi-module project like so:
>
> river-container        - parent project
> --river-container-core    - Java and associated source for the core
> container
>
> The core jar files need to get assembled with configuration files and
> dependent jars into a deployment layout similar to JBoss or Tomcat.
> Services get assembled and packaged into a jar file somewhat like a web
> application.  For integration testing, I need to assemble a test
> container including reggie and the core container components, and so on.
>
> So I'm thinking that I'll add the following modules to the multi-module
> project:
>
> -- reggie-module.ssar    - Starter Service Archive module for reggie
> -- river-container-test    - container configured with Reggie for testing
> -- river-container-default    - container configured for basic use.
>
> Does that make sense?  Should the Maven group id be "org.apache.river"
> or "org.apache.river.container"?
>
> Feel free to have a look and let me know.
>
> Greg.
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message