isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject Re: Some questions
Date Wed, 20 Nov 2013 22:04:55 GMT
On 20 November 2013 18:19, Kevin Meyer - KMZ <> wrote:

> Hi all,
> In no particular order:
> a) how well does it work on EE6+ servers

very well, thank you!

> and how much of EE
> infrastructure can it leverage? (see next questions)
Since Isis is a framework that provides a container for domain objects, the
user's code is substantially hidden from JEE.  So the question really is to
what extent could one expose these services.

The answer to that is that, if you can write a domain service that
encapsulates some capability you want to leverage, then Isis apps can use
all of JEE 6.  For example, a domain service could provide access to a
rules engine, or simply to HttpServletRequest.  Domain services are the
"gateway" to the rest of the world.

A similar question might be... to what extent can the various components of
Isis (the Wicket viewer, the RESTful viewer etc) be customized themselves?
  To which the answer varies.  The Wicket viewer can to some extent, see my
various component factories that integrate gmap, calendar, highcharts etc;
the RO viewer cannot be extended at all, but then it's purpose is simply to
provide a well-defined REST API into the Isis runtime for arbitrary uses
(eg an Javascript SPA app, for migration, etc etc).

> b) how do annotations that are use relate to JSR-330,

they don't... they are in a different package.

A similar question might be... how does Isis' injection of domain services
compare to JSR-330? Right now there's not much overlap... JSR-330 defines
@Inject, whereas Isis supports either setXxx() or injectXxx() as methods.
 Oscar just raised a ticket (at my request) to also support @Inject, so
that will come in the next release.

@Named (which qualifies two services of coincidentally the same type) is
not supported... Isis would probably trip up on this.  However, all Isis
services can optionally define an id() method which "names" them, so this
would be easy enough to add as well, I guess.  Same goes for @Qualifier...
not supported yet.

@Scope also isn't supported, but here it's harder to see the justification.
 Isis automatically provides request-scoping for each interaction, while
domain services are globally scoped singletons.  For that reason the
@Singleton annotation is implied.

> or even CDI for
> that matter given that you share names of annoations
again, coincidence... different package.

Related, it would be trivial, if one wanted, to use @javax.inject.Named
instead of org.apache.isis.applib.annotation.Named... just write an Isis
FacetFactory.  Not sure that's a good idea, but would take about 30 minutes
to implement.

> c) could validation be extended to use bean validation spec?
yep, easily enough.... write some FacetFactory's.  There is in fact some
example code on this [1] as well as a ticket, IIRC.

> d) could user use JPA instead of JDO?
> [The Isis DN objectstore currently has a JDO implementation. One
> would have to write a JPA equivalent?]
Not currently.  DN does support JPA syntax, so I imagine the changes would
be pretty simple.

Supporting a different JPA implementaition would be much more work...
should distinguish between the API (JDO vs JPA) and the impl (DN vs
Hibernate vs OpenJPA vs ...).  So as I say, supporting a different API on
DN is easy.  Supporting a different implementation is rather more work.
 Note: we cannot ever support Hibernate because of its license (LGPL); that
basically leaves OpenJPA.

> e) any there other persistence providers that work with isis beyond
> datanucleus?

I believe that Maurizio has got Isis running on Google App Engine, which is
a different JDO impl (though derived from DN, I think).  I'm pretty sure
that I do use some DN-specific APIs, so I'm a bit surprised this works, but
there you go.

> [Again, for a "seamless" fit, you can write your own objectstore
> implementation. Otherwise, you can bypass Isis' objectstore and use
> your own store API - but this would require disabling bytecode
> enhancements, etc... More specific guidance can be provided on
> demand.]
As you say, Isis itself does define its own ObjectStore API, and the JDO/DN
ObjectStore is only one implementation (albeit at this stage the most
mature).   There is an unreleased NoSQL ObjectStore however.  Writing an
OpenJPA ObjectStore would take a couple of months work, I reckon (the DN
one took about 3, and another 6 months of use to stabilize).

> f) What about client-side validation?
What's the client in this context... presumably the browser/Javascript?

It would be possible, if using the Wicket viewer, to write some custom
Javascript, and have it call back into the Restful Objects viewer to
perform validation.  Otherwise, we are leveraging the capabilities of the
Wicket framework.  That does quite a lot in this space.  Isis' Wicket
viewer has a pluggable architecture for its components, so writing cleverer
widgets is certainly do-able.

> General feedback: The guys asking all seemed to working on or for
> Redhat (JBoss) and related. They seemed surprised that Isis adopted
> JDO over JPA, with comments along the lines of "but JDO is dead
> already".

I doubt that Andy Jefferson would agree. But yes, it is the betamax to
JPA's vhs.  Note: it's also more capable, eg supporting NoSQL stores as
well as RDBMS [2]

> Otherwise, the general consensus was positive, since Isis
> handles all that one could want, if one wanted everything to be
> provided by a single framework.
Nice to hear!

Thanks for doing this talk, Kevin.



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