meinds-developers Mailing List for Meinds
Brought to you by:
emcs,
rickardoberg
Menu
▾
▴
meinds-developers — Info/discussion/development of Meinds
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(33) |
Oct
(7) |
Nov
(31) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: a2k <a2...@bl...> - 2002-06-26 16:09:50
|
Dmitri Colebatch wrote: > I think this project is pretty dead.... this is the first mail I've seen on > the list for a long time. Sorry I cant offer any help... > > cheers > dim Does anybody know an alternative solution to Meinds that is Java-based? Gruesse, Andreas |
|
From: a2k <a2...@bl...> - 2002-06-25 07:26:05
|
Hi I'm a Meinds-Newby. The setup complains about missing database tables. Where do I find the database definition files to create the database schema? Thanx. Andreas |
|
From: Maurice P. <Ma...@Vi...> - 2002-01-10 13:52:12
|
Hey, On Thursday, January 10, 2002, at 02:11 AM, Rickard wrote: > > Very good question. We've discussed redoing the entire codebase from the > ground. Not sure about other's feelings on getting started on that. I'm still very wrapped up in my new job right now. Hopefully, I will have more time to contribute to a big rework later in the spring... > Since I am now working fulltime on TheServerSide.com, if noone minds I > wouldn't mind using "org.meinds" as package prefix in there, so as to be > able to eventually OpenSource TSS into Meinds. The problem is I have no > timeline at all, so it could take a very long time or a relatively short > time to do that. > > What say ye? Very cool. Another, more radical codebase could jump start the development process again. Looking forward to seeing it. -Maurice |
|
From: Rickard <ri...@mi...> - 2002-01-10 11:23:42
|
Scott Eade wrote: > I can't say that I have read all of the relevant material in the archive, > but it seems to me that meinds was intended to allow people to > continue to use and extend the 1.x release of Jive and that a rewrite > would be better served as a completely new project. The alternative > will be two different implementations in the same repository (though > presumably in different branches). Jive would either be removed or kept in an entirely separate module for historic reasons. >>Since I am now working fulltime on TheServerSide.com, if noone minds I >>wouldn't mind using "org.meinds" as package prefix in there, so as to be >>able to eventually OpenSource TSS into Meinds. The problem is I have no >>timeline at all, so it could take a very long time or a relatively short >>time to do that. >> > > A decent IDE should allow you easily migrate to a new package > name without too much trouble shouldn't it? Yes. > Wouldn't you be better off using a new name anyway as it sounds > like you want to develop your solution within TSS and only release > it later on - i.e. it would not be open to discussion or review until > its release. Correct. > I am making assumptions here that may well be incorrect so > please don't take offence. None taken :-) It's a tricky situation. I'm not sure how to do this, which is why I asked. /Rickard -- Rickard Öberg |
|
From: Scott E. <se...@ba...> - 2002-01-10 10:58:32
|
From: "Rickard" <ri...@mi...> > Very good question. We've discussed redoing the entire codebase from the > ground. Not sure about other's feelings on getting started on that. I can't say that I have read all of the relevant material in the archive, but it seems to me that meinds was intended to allow people to continue to use and extend the 1.x release of Jive and that a rewrite would be better served as a completely new project. The alternative will be two different implementations in the same repository (though presumably in different branches). > Since I am now working fulltime on TheServerSide.com, if noone minds I > wouldn't mind using "org.meinds" as package prefix in there, so as to be > able to eventually OpenSource TSS into Meinds. The problem is I have no > timeline at all, so it could take a very long time or a relatively short > time to do that. A decent IDE should allow you easily migrate to a new package name without too much trouble shouldn't it? Wouldn't you be better off using a new name anyway as it sounds like you want to develop your solution within TSS and only release it later on - i.e. it would not be open to discussion or review until its release. I am making assumptions here that may well be incorrect so please don't take offence. > What say ye? I have no say. Just my $0.02. > /Rickard > > -- > Rickard Öberg > Cheers, Scott |
|
From: Rickard <ri...@mi...> - 2002-01-10 08:11:58
|
Scott Eade wrote: > This looks like a very quiet list! > > Just downloaded meinds yesterday and I now have > it up and running quite nicely. > > It isn't clear if anyone is interested in the following, > but I will mention them anyway... > > 1. Short email addresses > The database schema limits the username and email > columns to just 30 characters! Worse still the login > pages for vodka and sapphire are even less than this > (I didn't check bay). > > 2. The search results page for vodka uses three > images that should probably be replaced: > search_j.gif > search_i.gif > search_ve.gif > Which spells a word that should probably be > replaced with "meinds". > I never checked the other skins. > > Is anyone interested in these types of issues or should > I just ignore them and continue with my own > customisation. Very good question. We've discussed redoing the entire codebase from the ground. Not sure about other's feelings on getting started on that. Since I am now working fulltime on TheServerSide.com, if noone minds I wouldn't mind using "org.meinds" as package prefix in there, so as to be able to eventually OpenSource TSS into Meinds. The problem is I have no timeline at all, so it could take a very long time or a relatively short time to do that. What say ye? /Rickard -- Rickard Öberg |
|
From: Scott E. <se...@ba...> - 2002-01-10 03:12:00
|
This looks like a very quiet list!
Just downloaded meinds yesterday and I now have
it up and running quite nicely.
It isn't clear if anyone is interested in the following,
but I will mention them anyway...
1. Short email addresses
The database schema limits the username and email
columns to just 30 characters! Worse still the login
pages for vodka and sapphire are even less than this
(I didn't check bay).
2. The search results page for vodka uses three
images that should probably be replaced:
search_j.gif
search_i.gif
search_ve.gif
Which spells a word that should probably be
replaced with "meinds".
I never checked the other skins.
Is anyone interested in these types of issues or should
I just ignore them and continue with my own
customisation.
Cheers,
Scott
|
|
From: Rickard <ri...@xp...> - 2001-11-30 13:15:59
|
Rickard Öberg wrote: > First of all, the most obvious problem: it is not possible for an > AOP-object to implement interfaces with methods that clash. I.e. you > can't have interfaces A and B that both have "String getName()" methods > in them. If they have different method signatures it's ok. This may not > be a big problem in reality, but it's something to watch for. Actually, this can be easily solved by explicitly narrowing the object. Example, an object obj has two aspects A and B which both have a method getName(). Invoking obj.getName() will always delegate to A.getName() (even if the object was casted to B) since the proxy can only implement one of the two methods. However, if one explicitly casts it like this: B bObj = ObjectFactory.getObject(obj, B.class); // Narrow it bObj.getName(); // Invoke B aspect with getName() This will allow an object to have aspects which have the same method signatures. /Rickard -- Rickard Öberg |
|
From: Rickard <ri...@xp...> - 2001-11-30 12:36:18
|
Dmitri Colebatch wrote:
> duh! maybe like the one in ObjectFactory (o: ok... no more from
> me...
;-)
> I'm just wondering if the problem is that we're trying to do OO
> coding style and have the common Individual interface, when really we
> should just be using differnet interfaces as we require... then if we had
> a method in ObjectFactory that "casted" one aspect to another... so you
> could do something like:
>
> User user = UserBuilder.createObject("urn:user:dim");
> // use user
> user.getName();
>
> ACL acl = ObjectFactory.cast(user, ACL.class);
> // use ACL
This would work just fine, yes. You can either use the aspects of an
object that it already has (by casting/invoking it), or you can attach
any aspect to it as necessary. I.e. either the above (which is an
example of dynamically attaching aspects and then using them), or you
could do:
User user = IndividualBuilder.getIndividual("urn:user:dim");
user.getName();
ACL acl = (ACL)user;
acl.check(..);
/Rickard
--
Rickard Öberg
|
|
From: Rickard <ri...@xp...> - 2001-11-30 12:33:07
|
Dmitri Colebatch wrote: > I've just realised a problem with this... the common interface... you > would have to do without the common interface for this to work, which > means that its not too dissimilar to how it is now really... you just > get a new aspect... Correct. And the common interface in the example is purely for readability (i.e. easily see what aspects an Individual have). Remove it if you want to. You'd have to change IndividualBuilder to return Object, but other than that you're ok. Or, change the Individual interface to not extend any interfaces, but attach those aspects anyway. Works too. > maybe we could have a method getAspect(Object resource, Class > aspect) where the class is the interface represneting the aspect (and > hence interceptors/behaviour) that you want...? =ObjectBuilder. /Rickard -- Rickard Öberg |
|
From: Rickard <ri...@xp...> - 2001-11-30 12:31:11
|
Dmitri Colebatch wrote: > When I first started thinking about the aspect oriented thing I was > actually wondering if I could just have a "resource" that is basically > just an object, and then cast it to anything (which it may not have been > assigned at compile time), and have the dynamic proxy implement > isAssignableTo or something like that... so if I was invoking the > getName() on the User interface it would go to a different interceptor > than if I invoked it on the ACL interface. That is precisely how it works. > However, because we still need > to have a common interface (Individual) it doesn't really work... No, there's no "need" ;-) I just happened to make such an interface, to make it easy to see what aspects an Individual could have, by default. If you want, try removing ACL from Individual, and change IndividualBuilder to use the interfaces Individual+ACL instead. Same effect. > now... thinking about this, whilst Java requires that we have the common > interface, in Interceptor.invoke you test for getDeclaring class... could > we not have a chain of interceptors for each aspect rather than each > interface, so rather than IndividualBuilder creating the chain, > Interceptor did it? This is how it already works ;-) ACLBuilder sets the ACLImpl interceptors, the MemberBuilder sets the MemberImpl interceptors, and so on. IndividualBuilder is only responsible for either the interceptors that should go for only the object, or for the object and all aspects. /Rickard -- Rickard Öberg |
|
From: Dmitri C. <di...@bi...> - 2001-11-30 12:04:38
|
On Fri, 30 Nov 2001, Dmitri Colebatch wrote:
> maybe we could have a method getAspect(Object resource, Class
> aspect) where the class is the interface represneting the aspect (and
> hence interceptors/behaviour) that you want...? I'm kinda tired atm... so
> probably not thinking straight... well, thats my excuse and I'm sticking
> to it (o: maybe I'll realise how silly this all sounds tomorrow!
duh! maybe like the one in ObjectFactory (o: ok... no more from
me... I'm just wondering if the problem is that we're trying to do OO
coding style and have the common Individual interface, when really we
should just be using differnet interfaces as we require... then if we had
a method in ObjectFactory that "casted" one aspect to another... so you
could do something like:
User user = UserBuilder.createObject("urn:user:dim");
// use user
user.getName();
ACL acl = ObjectFactory.cast(user, ACL.class);
// use ACL
??? I'm sure going on my last two emails that this is also a stupid idea,
but will send it anyway, hopefully I'll learn from it!
cheers
dim
|
|
From: Dmitri C. <di...@bi...> - 2001-11-30 11:51:40
|
On Fri, 30 Nov 2001, Dmitri Colebatch wrote: > On Fri, 30 Nov 2001, Rickard [ISO-8859-1] =D6berg wrote: >=20 > > First of all, the most obvious problem: it is not possible for an=20 > > AOP-object to implement interfaces with methods that clash. I.e. you=20 > > can't have interfaces A and B that both have "String getName()" methods= =20 > > in them. If they have different method signatures it's ok. This may not= =20 > > be a big problem in reality, but it's something to watch for. >=20 > When I first started thinking about the aspect oriented thing I was > actually wondering if I could just have a "resource" that is basically > just an object, and then cast it to anything (which it may not have been > assigned at compile time), and have the dynamic proxy implement > isAssignableTo or something like that... so if I was invoking the > getName() on the User interface it would go to a different interceptor > than if I invoked it on the ACL interface. However, because we still nee= d > to have a common interface (Individual) it doesn't really work... >=20 > now... thinking about this, whilst Java requires that we have the common > interface, in Interceptor.invoke you test for getDeclaring class... could > we not have a chain of interceptors for each aspect rather than each > interface, so rather than IndividualBuilder creating the chain, > Interceptor did it? >=20 > So when Interceptor gets the call, it knows through config what > interceptors to actually use, and you can have a different interceptor > chain for each different aspect...? I've just realised a problem with this... the common interface... you would have to do without the common interface for this to work, which means that its not too dissimilar to how it is now really... you just get a new aspect...=20 maybe we could have a method getAspect(Object resource, Class aspect) where the class is the interface represneting the aspect (and hence interceptors/behaviour) that you want...? I'm kinda tired atm... so probably not thinking straight... well, thats my excuse and I'm sticking to it (o: maybe I'll realise how silly this all sounds tomorrow! cheers dim |
|
From: Dmitri C. <di...@bi...> - 2001-11-30 11:33:58
|
On Fri, 30 Nov 2001, Rickard [ISO-8859-1] =D6berg wrote: > First of all, the most obvious problem: it is not possible for an=20 > AOP-object to implement interfaces with methods that clash. I.e. you=20 > can't have interfaces A and B that both have "String getName()" methods= =20 > in them. If they have different method signatures it's ok. This may not= =20 > be a big problem in reality, but it's something to watch for. When I first started thinking about the aspect oriented thing I was actually wondering if I could just have a "resource" that is basically just an object, and then cast it to anything (which it may not have been assigned at compile time), and have the dynamic proxy implement isAssignableTo or something like that... so if I was invoking the getName() on the User interface it would go to a different interceptor than if I invoked it on the ACL interface. However, because we still need to have a common interface (Individual) it doesn't really work... now... thinking about this, whilst Java requires that we have the common interface, in Interceptor.invoke you test for getDeclaring class... could we not have a chain of interceptors for each aspect rather than each interface, so rather than IndividualBuilder creating the chain, Interceptor did it? So when Interceptor gets the call, it knows through config what interceptors to actually use, and you can have a different interceptor chain for each different aspect...? cheers dim |
|
From: Rickard <ri...@xp...> - 2001-11-30 09:25:56
|
Hey Having tinkered a bit more with the aspect stuff, I have found a couple of problems with the approach. First of all, the most obvious problem: it is not possible for an AOP-object to implement interfaces with methods that clash. I.e. you can't have interfaces A and B that both have "String getName()" methods in them. If they have different method signatures it's ok. This may not be a big problem in reality, but it's something to watch for. Second, the performance impact. The current code uses reflection and dynamic proxies, so there's an 0.03ms/call overhead. This may become a problem with huge amounts of objects. That said, I think I have found a way to get around the performance problem. Instead of using dynamic proxies one can use the TechTrader Bytecode Toolkit (http://sourceforge.net/projects/tt-bytecode/) to generate these proxies. Then it is possible to entirely avoid reflection, which should improve performance to the point where it's almost no overhead at all. Any other thoughts from people on the list about this? You're a very quiet crowd... /Rickard -- Rickard Öberg |
|
From: <Afl...@bm...> - 2001-11-29 14:26:42
|
Hello Everyone,
I have taken the old Jive 1.2.4 source code and created a new
project called Yazd. Pretty much it has some of bug fixes and also
Moderation feature added to it.
I just put together the website for it and you can get a copy of
it at http://yazd.yasna.com.
Please note, if you need to e-mail me, you have to send your
e-mails to aaf...@ya....
I would call this a beta release, there are still a few things
that need to happen.
Regards
Aflatoon |
|
From: Rickard <ri...@xp...> - 2001-11-29 12:58:15
|
Hey Following Dim's queries I tested how easy it would be to implement state management for the ACL. It was very very easy :-) First of all I did an ACLState interceptor. I added this to the ACLBuilder factory, so that all ACLImpl's had it "on top" of them. In invoke, before delegating the call the ACLState interceptor reads an XML file with ACL info corresponding to the resource it is attached to (e.g. "urn:user:john" will cause the file "urn/user/john/acl.xml" to be loaded). The ACLImpl was then fed these entries. The interceptor then delegated to the ACLImpl which could then perform its tasks. When the method returned the ACLState interceptor can check whether the method was a modifying one (i.e. "add") and then store the state back into the acl.xml file. All of this without having to change ACLImpl *at all*. Pretty neat. AOP rocks :-) Since I didn't have to change ACLImpl at all, I can now replace the ACLState interceptor with one that uses a database or heuristics or whatever instead, which is great. /Rickard -- Rickard Öberg |
|
From: Rickard <ri...@xp...> - 2001-11-29 08:54:50
|
Dmitri Colebatch wrote: > what is next on the list then? I'd be very keen in doing something here, > and feel like I understand what you're doing in the code... I suppose a > good start would be doco - do you have any thoughts on what structure the > documentation should take (in terms of a toc)... I figure if I started > there I would (a) ensure that I'm not completely missing something - or at > least have it corrected by you, and (b) get the necessary evil of doco > started at an early point... thoughts? BTW, if you start docoing this, then be sure not to mention Meinds, or as it being a part of Meinds. It'll be developed here first, since it's a good use-case of the AOP framework, but will be split off into another project later on due to its general usefulness. /Rickard -- Rickard Öberg |
|
From: Rickard <ri...@xp...> - 2001-11-29 08:45:03
|
Dmitri Colebatch wrote:
> got another query...
>
> in CallLog, you have
>
> public Object invoke(Object proxy, Method method, Object[] args)
> throws Throwable
> {
> // Log call
> if (!method.getDeclaringClass().equals(Object.class))
> ^^^^^^^^^^^^
>
> shouldn't it be
>
> public Object invoke(Object proxy, Method method, Object[] args)
> throws Throwable
> {
> // Log call
> if (!method.getDeclaringClass().equals(getObject().getClass()))
No, because all I wanted to do is avoid writing out all Object calls
(toString(), equals, hashCode).
> ? it seemed that the log methods weren't really coming out that
> usefully so I had a look... this change makes them look quite odd in
> places, my thoughts are that this is due to the implicit toString() calls
> going through the proxy, and hence through the logger... I'm assuming that
> this sort of logging probably wouldn't be done via an interceptor, the
> logging you'd be interested at the interceptor would be business logging
> yes?
Correct, hence the above filter :-)
/Rickard
--
Rickard Öberg
|
|
From: Rickard <ri...@xp...> - 2001-11-29 08:43:42
|
Dmitri Colebatch wrote: >>I have now finished the first working version of an Aspect Oriented >>Programming (AOP) framework. It is very simple, yet extremely powerful. >>I should be very useful as the base for the object model of Meinds. >> > > hehe... yes I agree... you are very useful for the object model for Meinds > (o: if only someone had thought to not make you a singleton! LOL, I guess I deserved that one ;-) > I _think_ I now see why state hasn't really been an issue... each aspect > can simply control their own state - yeah? Yes, and the actual state management can be done by an interceptor, just like in EJB. In fact, an aspect can *be* an EJB hence using EntityBeans to perform the state management. That doesn't mean that the other aspects of a given object has to use EJB though. > as the implementation of ACL > does... so as far as persistence is concerned, that is where that would > occur as well... in UserImpl you have getName() simply returning the > resource id - in reality UserBuilder will load an object from persistent > store, and that is where the name would come from, yes? Correct. > one other little thing here, the term Builder, as I understand GoF use it, > is a stateful throwaway object that you use to incrementially build > something... aren't the Builders more like Factories? or am I missing > something? Not really, since they may indeed be stateful. I used DocumentBuilder/DocumentBuilderFactory from JAXP as a comparison to what I wanted to achieve. The ObjectBuilders may indeed be stateful (that's why you register instances of them with the OBF), so I think it's an ok use of the term. I'm not religious about it though :-) > what is next on the list then? AFAICT the core framework that is there now is enough to get started. The horizontal compositioning (=adding features) is there, and the vertical compositioning (=adding behaviour) is there. All we need to do know is start using it, and see if the framework is somehow inherently flawed. If there's something I didn't think of, that needs to be fixed. Also, there *is* a small performance hit for using this, since dynamic proxies are involved. I have minimized this by letting interceptors call other interceptors directly (instead of going through method.invoke), but there's always a hit of 0.03ms/call. It might be irrelevant in the big picture, but may become important when thousands of objects are being called during a process. For the really performance-minded it *is* possible to extract objects from the compositioning and call them directly, but this should be done as little as possible since it makes the code harder to write/read. > I'd be very keen in doing something here, > and feel like I understand what you're doing in the code... I suppose a > good start would be doco - do you have any thoughts on what structure the > documentation should take (in terms of a toc)... I figure if I started > there I would (a) ensure that I'm not completely missing something - or at > least have it corrected by you, and (b) get the necessary evil of doco > started at an early point... thoughts? Good idea. Steal the doco outline from WebWork (i.e. DocBook), since it's got the basic outline done, and also with a nice CSS stylesheet to go with it. The doco generation works well there too, which can be tricky to set up. All set, soldier? Then move out :-) /Rickard -- Rickard Öberg |
|
From: Dmitri C. <di...@bi...> - 2001-11-29 06:49:07
|
got another query...
in CallLog, you have
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable
{
// Log call
if (!method.getDeclaringClass().equals(Object.class))
^^^^^^^^^^^^
shouldn't it be
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable
{
// Log call
if (!method.getDeclaringClass().equals(getObject().getClass()))
^^^^^^^^^^^^^^^^^^^^^^
? it seemed that the log methods weren't really coming out that
usefully so I had a look... this change makes them look quite odd in
places, my thoughts are that this is due to the implicit toString() calls
going through the proxy, and hence through the logger... I'm assuming that
this sort of logging probably wouldn't be done via an interceptor, the
logging you'd be interested at the interceptor would be business logging
yes?
anyway, still reading, still smiling (o:
cheesr
dim
On Thu, 29 Nov 2001, Dmitri Colebatch wrote:
> On Wed, 28 Nov 2001, Rickard [ISO-8859-1] =D6berg wrote:
>=20
> > I have now finished the first working version of an Aspect Oriented=20
> > Programming (AOP) framework. It is very simple, yet extremely powerful.=
=20
> > I should be very useful as the base for the object model of Meinds.
>=20
> hehe... yes I agree... you are very useful for the object model for Meind=
s
> (o: if only someone had thought to not make you a singleton!
>=20
> > Individuals have the ACL, Member, and User aspects attached to them. Th=
e=20
> > basic object itself that these are attached to is a simple string (the=
=20
> > id). Hence, the object itself does not provide much functionality,=20
> > except toString(), hashCode(), and equals() implementations (from=20
> > java.lang.String).
>=20
> I've had a good look through, and am pretty comfortable (I think) with th=
e
> flow of events and stuff (IntelliJ + Ctrl-B works wonders :), and surpris=
e
> surprise have a couple more questions related to state. =20
>=20
> I _think_ I now see why state hasn't really been an issue... each aspect
> can simply control their own state - yeah? as the implementation of ACL
> does... so as far as persistence is concerned, that is where that would
> occur as well... in UserImpl you have getName() simply returning the
> resource id - in reality UserBuilder will load an object from persistent
> store, and that is where the name would come from, yes?
>=20
> one other little thing here, the term Builder, as I understand GoF use it=
,
> is a stateful throwaway object that you use to incrementially build
> something... aren't the Builders more like Factories? or am I missing
> something?
>=20
> what is next on the list then? I'd be very keen in doing something here,
> and feel like I understand what you're doing in the code... I suppose a
> good start would be doco - do you have any thoughts on what structure the
> documentation should take (in terms of a toc)... I figure if I started
> there I would (a) ensure that I'm not completely missing something - or a=
t
> least have it corrected by you, and (b) get the necessary evil of doco
> started at an early point... thoughts?
>=20
> cheers
> dim
>=20
>=20
|
|
From: Dmitri C. <di...@bi...> - 2001-11-29 03:54:16
|
On Wed, 28 Nov 2001, Rickard [ISO-8859-1] =D6berg wrote: > I have now finished the first working version of an Aspect Oriented=20 > Programming (AOP) framework. It is very simple, yet extremely powerful.= =20 > I should be very useful as the base for the object model of Meinds. hehe... yes I agree... you are very useful for the object model for Meinds (o: if only someone had thought to not make you a singleton! > Individuals have the ACL, Member, and User aspects attached to them. The= =20 > basic object itself that these are attached to is a simple string (the=20 > id). Hence, the object itself does not provide much functionality,=20 > except toString(), hashCode(), and equals() implementations (from=20 > java.lang.String). I've had a good look through, and am pretty comfortable (I think) with the flow of events and stuff (IntelliJ + Ctrl-B works wonders :), and surprise surprise have a couple more questions related to state. =20 I _think_ I now see why state hasn't really been an issue... each aspect can simply control their own state - yeah? as the implementation of ACL does... so as far as persistence is concerned, that is where that would occur as well... in UserImpl you have getName() simply returning the resource id - in reality UserBuilder will load an object from persistent store, and that is where the name would come from, yes? one other little thing here, the term Builder, as I understand GoF use it, is a stateful throwaway object that you use to incrementially build something... aren't the Builders more like Factories? or am I missing something? what is next on the list then? I'd be very keen in doing something here, and feel like I understand what you're doing in the code... I suppose a good start would be doco - do you have any thoughts on what structure the documentation should take (in terms of a toc)... I figure if I started there I would (a) ensure that I'm not completely missing something - or at least have it corrected by you, and (b) get the necessary evil of doco started at an early point... thoughts? cheers dim |
|
From: Rickard <ri...@xp...> - 2001-11-28 14:29:36
|
Rickard Öberg wrote: > I should be very useful as the base for the object model of Meinds. I->It :-) /R -- Rickard Öberg |
|
From: Rickard <ri...@xp...> - 2001-11-28 14:27:49
|
Hey I have now finished the first working version of an Aspect Oriented Programming (AOP) framework. It is very simple, yet extremely powerful. I should be very useful as the base for the object model of Meinds. The main features: * You can add behaviour to any object. This will allow the object to be casted to the interface of the new behaviour, and the methods in the additional interface are invokable. The methods are routed to aspects instead of the original object. * You can add interceptors to any object, including behaviour aspects. This will allow you to do custom things on each call to the object. The behaviour itself may be a composite object, but I haven't begun thinking about what weird possibilities that will bring :-) The example I have created contains two main object types: Individuals and UserGroups. Individuals have the ACL, Member, and User aspects attached to them. The basic object itself that these are attached to is a simple string (the id). Hence, the object itself does not provide much functionality, except toString(), hashCode(), and equals() implementations (from java.lang.String). UserGroups have the ACL, Member, and Group aspects attached to them. The basic object itself is again a string. The ACL, Member, and Group aspects have the CallLog and ACLCheck interceptors on top of them, so any call to them will log the call to System.out, and do an ACLCheck against the ACL of the same object. The ACLCheck implementation is fairly advanced, and allows for inherited ACL's both on the user and resource side. For example, if John is a member of the Admin UserGroup, and Admin may access the Sara Individual, then John may access Sara because of the transitive ACL check logic. The code are in four parts(/packages): * The main objects and object builders (for Individuals and UserGroups). * The aspects and their factories. * The interceptors and their factories. * The framework classes. There's also a fairly interesting test class that tests various uses of the example, mainly doing ACL-checks in complex ways. That should be all that's needed to allow you to look in the code and understand what's going on. I have uploaded a zip with both source and compiled code to SourceForge (check out the "aspects" release). run from /build/result with "java aspects.test.Test". A bunch of ACL tests will be executed. Most of the test messages are from the interceptors, and some are from behaviours. What you'll want to take a look at is the test source code, how the different behaviour aspects are coded, and well, how it fits together. Shouldn't be that hard to trace (especially if you're an IntelliJ user ;-). Play around. /Rickard -- Rickard Öberg |
|
From: Rickard <ri...@xp...> - 2001-11-27 20:44:43
|
Erik Sundvall wrote: > It will solve a particular, very important part of the Meinds > architecture. As we have discussed before I (and many others on the > list) believe we can find other already made components for most parts > of Meinds. A main task of the Meinds project will be to find good > components, glue them together (with as little extra code as possible) > and then package the whole thing in an attractive, user-friendly way. I agree, although it also vital that it can be expanded with new code as easily as possible. I doubt that using Meinds in its "raw" form will be what most people want. Maybe a couple of "profiles" of Meinds will be more suitable. The key lies in customization though (IMHO). What does people on this list want, or think about this? > As I told you before (off list) you are very welcome to start developing > this within Meinds. The idea of then splitting it out to a separate > project is also a good idea. It can be dangerous to try to host too much > within a single project and the described concept is very general and > far from Meinds-specific. I believe most people on the list agree, and > as long as you keep the code Open Source (as you usually do). Yup, so it'll begin as a part of Meinds then, and then be split off. > To get up to speed I believe we can start using Jena for RDF > persistence. (It can be changed to something else later.) Jena provided > several different RDF storage options (XML-files, Memory based, Berkley > DB, SQL/JDBC (soon), Lucene (experimental). This does not exclude the > possibility to use JDO on different levels later. That does indeed sound like a good gameplan. > Where to perform and store access control to objects has been one of my > main concerns when thinking of Meinds architecture, now we can use RDF > for storage/persistence also of ACL data and "the interceptor-oriented > part" of Rickards idea for the actual access control checking. Yes. As you have seen by now Erik, I already have ACL's and the accompanying ACLChecker interceptor working. It can be applied to any resource, so it's very very generic yet powerful. > Well, it seems like we might have some interesting pieces for the Meinds > puzzle soon... time to assemble a first pre-alpha? I'll do some more testing of the current codebase, but it should be sufficiently stable to try out now I think. I'll send it to the list later. /Rickard -- Rickard Öberg |
