If you just new them up:
Customer cust = new Customer();
then the framework doesn't know about it and any services will be null.
You can then use:
domainObjectContainer.injectServicesInto(cust);
~~~
Alternatively, use:
Customer cust = container.newTransientInstance(Customer.class);
to do both steps in one.
HTH
Dan
On 26 November 2015 at 09:09, Stephen Cameron <steve.cameron...@gmail.com>
wrote:
> Hi,
>
> I think I've read somewhere that domain services aren't always injected
> into entities by default and you sometimes have to trigger this yourself?
>
> Is this a correct?
>
> Thank
>
>
> On Thu, Nov 26, 2015 at 10:00 AM, Stephen Cameron <
> steve.cameron...@gmail.com> wrote:
>
> > I cannot try alternatives till later this evening, will let you know
> > of results. If I cannot get tenancies working for tomorrow its not the
> end
> > of the world. I was getting "record not found" errors last night due to
> > making region allowsNull="false", so a bit of a panic, given its
> > mostly been working very smoothly now for a while.
> >
> > On Thu, Nov 26, 2015 at 9:40 AM, Dan Haywood <
> d...@haywood-associates.co.uk
> > > wrote:
> >
> >> On 25 November 2015 at 22:26, Stephen Cameron <
> steve.cameron...@gmail.com
> >> >
> >> wrote:
> >>
> >> > Hi Dan,
> >> >
> >> > I did not explain it that well sorry.
> >> >
> >> > I want to get rid of nulls completely, the fact that I do handle them
> is
> >> > just a work-around for the fact that they are still being created, but
> >> only
> >> > for People. That is, if a new Participant is registered it looks to
> see
> >> if
> >> > there is an existing Person with the same details then adds a new one
> if
> >> > not present (a single Person can be a Participant and/or a Volunteer).
> >> The
> >> > Participant is getting its region set in setUpdatedBy() but the Person
> >> is
> >> > not, I need to debug this.
> >> >
> >> >
> >> In 1.10.0, a better approach is probably to add a subscriber to the
> >> lifecycle events:
> >>
> >> @DomainService(nature=NatureOfService.DOMAIN)
> >> public class RegionSubscriber extends AbstractSubscriber {
> >>
> >> @Subscribe
> >> public void on(ObjectPersistingEvent ev) {
> >> Object domainObject = ev.getSource();
> >> }
> >>
> >> @Subscribe
> >> public void on(ObjectUpdatingEvent ev) {
> >> Object domainObject = ev.getSource();
> >> }
> >> }
> >>
> >>
> >>
> >>
> >> > As general interest is handling such things via such a service better,
> >> that
> >> > is to avoid injecting services into entities if possible?
> >> >
> >> >
> >> There's nothing wrong with injecting services into entities; it allows
> >> them
> >> to perform their responsibilities without leaking details of how they do
> >> it
> >> (their implementation) to the caller. I don't hold by this "pass in the
> >> services" and "double dispatch"... I see that as a code smell.
> >>
> >> On the other hand, we now have a very rich set of domain events; in AOP
> >> terms these are jointpoints (or is it pointcuts? see [1]), anyway they
> are
> >> a different way to cause "stuff to happen".
> >>
> >> Should one have the entity call a services, or rely on subscribers to
> >> domain events? With the latter, the entity is very clean and the
> >> responsibility kept completely separate. On the other hand, with events
> >> the order in which the subscribers fire is non-deterministic.
> >>
> >>
> >>
> >>
> >>
> >>
> >> > Last minute tweeks aren't the best idea, but the tests that I do have
> >> are
> >> > proving their value. These particular issues are probably a result of
> no
> >> > integration tests yet.
> >> >
> >> >
> >> It's not clear to me if my suggestion to use the TenancyEvaluator SPI
> >> helped ? Or, indeed, whether you have a reasonable workaround in your
> >> current handling of the nulls?
> >>
> >>
> >>
> >>
> >> > Thanks
> >> >
> >> >
> >>
> >> [1]
> >>
> >>
> http://stackoverflow.com/questions/15447397/spring-aop-whats-the-difference-between-joinpoint-and-pointcut
> >>
> >>
> >> > On Thu, Nov 26, 2015 at 8:09 AM, Dan Haywood <
> >> d...@haywood-associates.co.uk
> >> > >
> >> > wrote:
> >> >
> >> > > Hi Steve,
> >> > >
> >> > > Not sure I follow quite all the ins-and-outs of this, but what could
> >> well
> >> > > be of use is the optional ApplicationTenancyPathEvaluator domain
> >> > > service[1]. If an implementation is registered (on the classpath),
> >> then
> >> > > the security module will delegate to this [2] in order to determine
> >> who
> >> > > gets to see/edit what.
> >> > >
> >> > > From what I did follow, it sounds like you need to treat objects
> with
> >> a
> >> > > null region in a particular way? If so, then hopefully you can put
> >> this
> >> > > "special case" logic in an implementation of said service.
> >> > >
> >> > > HTH
> >> > > Dan
> >> > >
> >> > >
> >> > >
> >> > > [1]
> >> > >
> >> > >
> >> >
> >>
> https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/dom/tenancy/ApplicationTenancyPathEvaluator.java
> >> > > [2]
> >> > >
> >> > >
> >> >
> >>
> https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/facets/TenantedAuthorizationFacetFactory.java#L72
> >> > >
> >> > >
> >> > > On 25 November 2015 at 20:25, Stephen Cameron <
> >> > steve.cameron...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I have a problem with Application Tenancies not working the way I
> >> > want, I
> >> > > > want to drive it off a field 'region', such that a person is
> >> assigned a
> >> > > > tenancy of GLOBAL, NORTH, SOUTH, NORTH-WEST and these are also the
> >> > > regions
> >> > > > that they are working in too, so when they create a record their
> >> region
> >> > > > gets assigned to the new record and that controls who else can see
> >> the
> >> > > > record.
> >> > > >
> >> > > > This mostly works, but there is one small glitch. The main
> problem I
> >> > have
> >> > > > is setting it up so that region is non-null and any records
> created
> >> by
> >> > a
> >> > > > GLOBAL tenancy user are seen by all users, while those created by
> a
> >> > > NORTH,
> >> > > > SOUTH or NORTH-WEST user are seen only by users with the same
> >> tenancy.
> >> > By
> >> > > > changing the region of a record it can change tenancy.
> >> > > >
> >> > > > Presently this is broken, or at least it I think it was working
> >> > correctly
> >> > > > when I allowed a record with a region of null to be the GLOBAL
> >> ones. I
> >> > > need
> >> > > > to have this working for a demo tomorrow, so advice is welcomed on
> >> how
> >> > > best
> >> > > > to set this up properly.
> >> > > >
> >> > > > My base class that controls all this here:
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/Stephen-Cameron-Data-Services/isis-chats/blob/master/dom/src/main/java/au/com/scds/chats/dom/AbstractChatsDomainEntity.java
> >> > > >
> >> > > > The other small glitch is that a person record created in the
> >> process
> >> > of
> >> > > > creating a participant doesn't get assigned a region
> automatically.
> >> I
> >> > > have
> >> > > > a work-around for that in place at present, anything that has a
> null
> >> > > region
> >> > > > gets presented as having a global tenancy.
> >> > > >
> >> > > >
> >> > > > Thanks
> >> > > >
> >> > > > Steve Cameron
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
