Some have wondered what happened to Rickard Oberg, who distinguished himself via various open source contributions including XDoclet, WebWork, JBoss' microkernel architecture, etc. Rickard has finally blogged about the Portal/CMS company SenseLogic, where he has been focused for the last 2 and a half years, as well as various technology decisions and lessons learned along the way.

Talking about business, how Senselogic has thrived, Rickard explains that "For us it has been a relatively simple recipe: listen to customers, understand their needs, use networks".

On technology choices, Rickard is "infinitely pleased" that they adopted AOP for their core architecture, but they had to implement their own framework due to lack of any other viable choices at the time. Interestingly, he also says that there are "still are no good contenders out there today".

Senselogic also saw reasonable succcess using PicoContainer as their component container but ran into some of it's limitations. "...its 'everyone sees everything' approach doesn't really work well when you have lots and lots of components."

Rickard also takes a firm stance on the benefits of using LDAP directories for account management, claiming that they simply do it much better than in-house solutions. "I see very few reasons why anyone would want to build an application today that has a custom user management that is not a LDAP directory."

From his experience building a Portal/CMS product, Rickard assets WSRP's and security integration technologies:

It is curious to read forums where people bash things like portlets and WSRP and XACML and such.

Why would we want to run portlets in two servers? My Struts app works just fine on one Tomcat instance.

Amazing. When you have been exposed to real-life DMZ environments a couple of times you start to wonder how the heck we get anything done *without* stuff like WSRP and security integration specifications like XACML and SAML.

On the Portal/CMS market, Rickard notes that you need a product that is both a Portal and a CMS if you a website that with content and app integration; however, most products today are either focused on being a CMS solution, or a portal solution. However, since Senselogic's product SiteVision implements CMS functionality as portlets, it operates in both worlds.

Full version: Thoughts on Senselogic and SiteVision.

Some have wondered what happened to Rickard Oberg [..] Full version: Thoughts on Senselogic and SiteVision.

A worthwhile read. I like his explanation of how product quality is a reflection of business goals; we call it "managing to your customers' pain points," which basically means that if you can successfully make your customers' pain into your own pain, you will naturally find a way to solve your customers' pain points, which helps immensely when you are trying to sell your company's products and/or services.

Congratulations and best wishes, Rickard!

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

And I thought shacked up and had 6 kids...You know what that means, right? No more late night application development..

Glad to know, his fingers are still punching

Is there any link/url/answer for the above question?

I was wondering what happened to Rikard. The last time I heard anything about him was some time ago. I guess he was busy getting real work done. Good to hear about him.

What happened to him, really? A journalist is always a journalist, right Joe?

The guy is working, he is innovating, as usual. He occasionally posts to TheServerside, and to his blog. You might want to bookmark this, http://www.jroller.com/page/rickard
Uh-oh, he does not participate in flame wars: too bad. We miss you Rickard...

Anyone heard of the Abstract Schema approach to AOC? Hello?

Here's a suggestion for a new topic: Bob Lee unveiled. Can anyone let me know where Bob posts his thoughts nowadays?
Bob?!

Here's a suggestion for a new topic: Bob Lee unveiled. Can anyone let me know where Bob posts his thoughts nowadays? Bob?!

http://today.java.net/pub/au/152


Javier

Great post - this is just the kind of thing that TSS should be publishing. One the the best articles that I have read here recently was the migration of TSS to Tapestry. I'd much rather read about the true experience of using tapestry rather than reading about the features the framework has in a "who can p*ss the highest" competition.

A description from someone one who is actually *doing* this stuff is so valuable and I'd love to see TSS doing more along these lines.

Using AOP was a gamble at the time, especially since I had to write it all from scratch as there were no frameworks available that anywhere resembled production quality (and this is, sadly, still true today).

This is an interesting claim. Can you explain "(this is, sadly, still true today)" Rickard ? I don't want to start a flamewar here but I suppose that AspectJ/AspectWerkz guys do not entirely agree with you, or do they ?

This is an interesting claim. Can you explain "(this is, sadly, still true today)" Rickard ? I don't want to start a flamewar here but I suppose that AspectJ/AspectWerkz guys do not entirely agree with you, or do they ?

First of all the term "production quality" is of course highly subjective and relatively arbitrary. What I meant was that I wouldn't be able to do what I want to do with any existing framework. There's a whole bunch of specific issues, but in general it's the two I outlined in the entry: making it comprehensible for human beings, and having tools that allow the developer to see what is going on.

For but one tool example, if I change a pointcut for an aspect I want to know exactly what joinpoints were affected by this change; where was the aspect added and where was it removed. Let's say it was added in 1000 places and removed in 100. Without this there's no way for me to able to evolve the system and have a reasonable idea of what the system looks like. Essentially, I can't add stuff and I definitely can't do refactoring of pointcuts. Simple things like this, which are vital for day-to-day development of large systems, are still missing in the AOP toolset, regardless of framework.

Did you try out AJDT and if so what problems did you encounter with it? AJDT will show you which joinpoints are being advised by your aspects, but I'm interested to know whether or not this is unweildy in large projects.

Rob

Did you try out AJDT and if so what problems did you encounter with it? AJDT will show you which joinpoints are being advised by your aspects, but I'm interested to know whether or not this is unweildy in large projects.Rob

What you describe is the static view ("what does the system look like"). As I described, I want the dynamic view ("what happened to the system when I did X"). Huge difference. For day-to-day work I'm actually much more interested in the dynamic view than the static view. I can check the static view once in a while to make sure everything looks ok, but what is more important during development is that I can add/change/update pointcuts and the effects will be what I thought they were. If I can't see the changes (kind of like "diff" in CVS), there's no way that I can *know* that what I thought happened actually happened. And guessing just isn't good enough.

As an example, I solved this in my own framework by creating a tool that starts the runtime, exports the system configuration to an XML file, and then creates a visual comparison between different XML files. That way I could easily see what the sum total changes from one release of the product to another release would be, or between just changing one pointcut, or what happens after a refactoring of a bunch of pointcuts.

Ok I understand. But AspectWerkz is pretty human readable from what I could figure out. I admit AspectJ syntax is ... awkward.

Regarding the lack of tools, you are unfortunatelly right, this is valid for the entire java space. I suppose Eclipse is trying to fill that gap and to some extent it has already managed to.

Hi Rickard,

Can you describe what you mean by "system configuration"? Perhaps you can show an example system configuration. For what I understood, "system configuration" is a snapshot of join points matched during an execution of the system. If so, it should be possible to implement the same functionality through an aspect (more appropriately called a meta-aspect) in existing AOP systems.

There was a lot of discussion around tools during AOSD conference in Chicago, including around pointcut "diff" tool. Speaking from memory, Mik Kersten (an AspectJ committer) even has a prototype of the tool. That said, it would help a lot to learn from your experience, align the existing tools to meet the needs, and add missing capabilities.

-Ramnivas
http://ramnivas.com

Hi Rickard,Can you describe what you mean by "system configuration"? Perhaps you can show an example system configuration. For what I understood, "system configuration" is a snapshot of join points matched during an execution of the system.

Correct.

If so, it should be possible to implement the same functionality through an aspect (more appropriately called a meta-aspect) in existing AOP systems.

What you need is a way to deduce the set of joinpoints and for each joinpoint list what aspects have been bound to it. Not sure I see how that could be accomplished by an aspect. Seems like it would have to involve something *outside* of the application, like the weaver for example.

There was a lot of discussion around tools during AOSD conference in Chicago, including around pointcut "diff" tool. Speaking from memory, Mik Kersten (an AspectJ committer) even has a prototype of the tool. That said, it would help a lot to learn from your experience, align the existing tools to meet the needs, and add missing capabilities.

That's good to hear. For my own purposes, I just made it possible for the AOP runtime to dump its internal state as an XML file, and then wrote a tool that could generate a HTML report given two such files. Very simple really, once I had the XML dumps.

blockquote>There was a lot of discussion around tools during AOSD conference in Chicago, including around pointcut "diff" tool. Speaking from memory, Mik Kersten (an AspectJ committer) even has a prototype of the tool. That said, it would help a lot to learn from your experience, align the existing tools to meet the needs, and add missing capabilities.

That's good to hear. For my own purposes, I just made it possible for the AOP runtime to dump its internal state as an XML file, and then wrote a tool that could generate a HTML report given two such files. Very simple really, once I had the XML dumps.

The prototype diff tool shows you how the crosscutting structure of the system has changed since the last snapshot. So anything that wasn't advised before stands out, as do any join points that are no longer advised. By default the last snapshot is the last build. You can also 'pin' the diff to a particular build. So before you synch with CVS you can pin the model, and immediately see if someone else's aspects advise any code that you've been working on and vice-versa. Rickard, it's something like the XML structure that you're generating, but done within the Eclipse UI and using our incrementally-updated structure model.

It sounds like you and Ramnivas are indicating that it would be good for this tool to let you save and re-load a snapshot of the crosscutting structure. This is easy to do, but it would be great to hear a couple of concrete use cases that you're after (e.g. comparing how the crosscutting structure changed between release builds).

Regarding the maturity of AOP tools and the availability of such features, I think that it's important to keep in mind that these tools are continuing to evolve and keeping up with demand. A year ago nobody was asking for a diff tool. Now that we have bigger projects and teams using aspects we can expect these sorts of features to become increasingly available, and the various AOP tools to be responsive to such feature requests.

The prototype diff tool shows you how the crosscutting structure of the system has changed since the last snapshot. So anything that wasn't advised before stands out, as do any join points that are no longer advised. By default the last snapshot is the last build. You can also 'pin' the diff to a particular build. So before you synch with CVS you can pin the model, and immediately see if someone else's aspects advise any code that you've been working on and vice-versa. Rickard, it's something like the XML structure that you're generating, but done within the Eclipse UI and using our incrementally-updated structure model.

That's exactly what I'm after. If you've got that working it just got much easier to work with AOP on large projects.

It sounds like you and Ramnivas are indicating that it would be good for this tool to let you save and re-load a snapshot of the crosscutting structure. This is easy to do, but it would be great to hear a couple of concrete use cases that you're after (e.g. comparing how the crosscutting structure changed between release builds).

Well, you said it yourself. Sometimes doing diffs between builds is ok, but at the end of a release cycle you will want to do a check of the entire set of changes. Having snapshots of the last release would then be necessary.

Regarding the maturity of AOP tools and the availability of such features, I think that it's important to keep in mind that these tools are continuing to evolve and keeping up with demand. A year ago nobody was asking for a diff tool. Now that we have bigger projects and teams using aspects we can expect these sorts of features to become increasingly available, and the various AOP tools to be responsive to such feature requests.

Yes, I realize that. And because I think tools like these are hindering adoption it is very important that they exist. It removes a lot of usability questions with AOP I think.

Very nice indeed :-) Now I have to change my slides for the next AOP talk. Thanks!

Rickard,

While I agree that having an ability to compare the join points matched by a given pointcut before and after refactoring is a useful feature, I don't think it is nearly as important as having a good battery of unit tests. Just as with pure OO development, tools support for refactoring helps, but tests are critical to let you refactor with confidence.

You can also use tools support for AspectJ (e.g., in AJDT) to help with refactorings, e.g.,

// identifies possible false positive matches
before(): newPointcut() && !oldPointcut() {}

// identifies possible false negative matches
before(): !newPointcut() && oldPointcut() {}

One issue you allude to is the difference between static and dynamic resolution. If you have a pointcut that might match a number of points in a running system, reviewing the list of potential matches is clearly not a substitute for testing. I don't see how your system that exports XML handles that case, which is the heart of dynamic matching.

Rickard,While I agree that having an ability to compare the join points matched by a given pointcut before and after refactoring is a useful feature, I don't think it is nearly as important as having a good battery of unit tests. Just as with pure OO development, tools support for refactoring helps, but tests are critical to let you refactor with confidence.

Wow. I hope I misunderstood what you just wrote. Example: let's say you have an aspect that, for example, triggers a JMS event when a method is invoked, and that aspect is applied to 50 methods. Are then saying that you will have 50 unit tests that checks whether those methods trigger an event? And if you then refactor so that 100 methods are targeted by the aspect, will you add 50 more unit tests?

If so, then I think we have very different views of what a unit test should do. I would NEVER make a unit test that checks the above, and yet this is precisely what I would want from the tool I described: I have changed a pointcut to supposedly include more joinpoints, but only the tool showing changes between two states can give me confidence that I've actually done things correctly, and that I haven't included more joinpoints than I originally intended.

Sory, but I don't buy that unit tests will solve that.

You can also use tools support for AspectJ (e.g., in AJDT) to help with refactorings, e.g.,
// identifies possible false positive matches
before(): newPointcut() && !oldPointcut() {}
// identifies possible false negative matches
before(): !newPointcut() && oldPointcut() {}

Kind of works, but it's a kludge.

One issue you allude to is the difference between static and dynamic resolution. If you have a pointcut that might match a number of points in a running system, reviewing the list of potential matches is clearly not a substitute for testing. I don't see how your system that exports XML handles that case, which is the heart of dynamic matching.

I suppose it depends on what you mean by dynamic matching. I only use pointcuts that match on method/class signatures and annotations. Since those things are always static at load time I don't have a problem with the XML export thingy. If you want to use more dynamic matching, or even per-instance aspect weaving, then sure, no tool in the world (except possibly a standard debugger) is going to help.

To be more precise, I would have two levels of tests:
1. Unit test the pointcut by making sure that representative cases (positives and negatives) match properly. With any kind of reasonable pointcut, I don't need anything like 50 cases to be confident my pointcut is working correctly. To me, this is analogous to testing control flow: you will never write tests that test all paths through a method with a non-trivial loop. But achieving coverage is clearly important.
2. Integration test the collaborations, to make sure that the integrated result of my aspects and classes cooperate to achieve the expected results. If the aspect is fairly closely coupled with the class, then it is natural to check integrated behavior (e.g., database commits happen from the transaction management aspect). If not, then I might write an aspect that asserts expected behavior in relevant test cases, specified in a way that makes the pointcuts different. By doing tests rather than just verifying matches, I can test for correct integration semantics, rather than just identifying the points where advice applies.

While I can see some value in reviewing the join points that a pointcut matches and changes after refactoring as a sanity check, it seems to have the same problem as testing by stepping through a debugger: making the cost of regression testing/verification high enough to discourage refactoring. How many changes do you typically analyze on a given refactoring? Do you run this tool each time you extract method or add some code to the system?

And to test pointcuts that do depend on dynamic conditions (like cflow), my tool of choice is testing.

Richard,

"I suppose it depends on what you mean by dynamic matching. I only use pointcuts that match on method/class signatures and annotations. Since those things are always static at load time I don't have a problem with the XML export thingy."

"If you want to use more dynamic matching, or even per-instance aspect weaving, then sure, no tool in the world (except possibly a standard debugger) is going to help."

Ron,

"By doing tests rather than just verifying matches, I can test for correct integration semantics, rather than just identifying the points where advice applies."

I wonder what Richard thinks about EPIServer, the other CMS product in his area that is made in C#/.NET- do not use AOP at all and is (at least until now) +20 times more successful? Also what is his view on .NET at this point in time?

Regards
Rolf Tollerud

Richard,Regards Rolf Tollerud

It is Rickard not Richard. Some people never learn.

I wonder what Richard thinks about EPIServer, the other CMS product in his area that is made in C#/.NET- do not use AOP at all and is (at least until now) +20 times more successful? Also what is his view on .NET at this point in time?RegardsRolf Tollerud

Your numbers are a "little" off, but admittedly being a C#/.Net advocate does require wishful thinking so I suppose it goes with the territory ;-)

Your numbers are a "little" off

Why do you not correct me then. But the main thing is that I am very curious to what is your opinion of C# now after all this time. The thing is, so much effort, so much advanced programming has got into your product while the other guys probably is some - maybe not beginners but you know what I mean. Don't you think it is unfair?

The story reminds me about of the Ants and the Moose. The ants are the busiest living things in the forest, they always work, work. The Moose on the other hand is laziest thing alive. Having no enemies it just goes around and eats (if he’s not sleeping). Now and then, without noticing it, the moose inadvertently trod upon a Ants nest creating havoc and catastrophe for the ants..

Regards
Rolf Tollerud

The ants are the busiest living things in the forest, they always work, work. The Moose on the other hand is laziest thing alive. Having no enemies it just goes around and eats (if he’s not sleeping). Now and then, without noticing it, the moose inadvertently trod upon a Ants nest creating havoc and catastrophe for the ants..

rofl - the most sensible thing you've written on TSS, but lets not destroy *another* thread with .net v java comparisons. I agree that Rickard is a "Moose" within the java community and trying to keep up with him could cost you more time than is saves, but despite the AOP hype I don't know of many people using it in live scenarios. There is plenty to learn from Rickards first hand experience of using this technology and nothing to learn from another .net arguement. Hopefully everyone else reading this thread will ignore your bait and keep this on track for a change...

Back to the point, Rickard, is you AOP implementation proxy based or have you implemented compile-time weaving? If you were starting the project again would you take the same route of creating your own framework or do you think that the current frameworks have matured to a point that you would consider them instead?

The one implementation I would never consider is aspectj, a great implementation, but I would never want to burden a team with a lanaguage extention like that. Couldn't they have a least used a different compiler so javac could ignore them :@

Back to the point, Rickard, is you AOP implementation proxy based or have you implemented compile-time weaving?

The aspects need to consider runtime settings, such as system properties and runtime attributes(/annotations), so the earliest possible weaving time would be at load time.

About proxy/non-proxy. For an object model to scale references between objects need to be decoupled. We solve this by using proxies, a la EJB. Another way to do it would be to implement something like JDO. The easiest way (IMO) is to use proxies, and it at the same time represents a decent place to do weaving. That being said, there obviously are drawbacks with a proxy-based solution, such as difficulty with triggering aspects when the object calls itself, so a subclass-based, or bytecode-based, weaving can do more interesting things in that regard. If I were to do it again I would probably try bytecode-based weaving first, and then subclass-based weaving, but the framework as a whole would have to have some kind of proxy-support anyway for the mentioned reason.

If you were starting the project again would you take the same route of creating your own framework or do you think that the current frameworks have matured to a point that you would consider them instead?

I often ask myself the same thing, so I check out AspectWerkz (which is the main contender) now and then. So far it doesn't solve all my problems, but it is getting closer.

The one implementation I would never consider is aspectj, a great implementation, but I would never want to burden a team with a lanaguage extention like that.

Same here.

But the main thing is that I am very curious to what is your opinion of C# now after all this time.

The whole .Net platform is not very interesting for me, so I have never tried C#, so I don't really have an opinion. I try not to have opinions about things I know nothing about.

Wow. I hope I misunderstood what you just wrote. Example: let's say you have an aspect that, for example, triggers a JMS event when a method is invoked, and that aspect is applied to 50 methods. Are then saying that you will have 50 unit tests that checks whether those methods trigger an event? And if you then refactor so that 100 methods are targeted by the aspect, will you add 50 more unit tests? If so, then I think we have very different views of what a unit test should do.

The case you discribe requires an integration/functionality test, not a unit-test. There is a fundamental difference, between those two, even if boh of them are programmer tests written with JUnit or similiar.

Unit test, by definition, is a kind of test that tests a unit in isolation from other units. A functionality that is applied to 50 units can not be tested by a unit-test. Yet, it can be tested by an automated test.

So, generally, you should be able to write an automated test, but it will not be a unit-test, per se.

So, both of you may be right :)

Quick question here, I hope you are still watching this thread - AJDT is only for Aspect J right, or can this tool somehow be user with Spring?

Thanks!!

Mark

Hi Rickard,
I have a few questions based you your recent experience:

1. What's your opinion of JSR-170, the Content Repository API? Will your product implement it?

2. In developing your CMS portlets, how did you get around some of the limitations of the Portlet API (JSR-168) such as interportlet communication? Based on this experience, do you have any suggestions for the next version of the Portlet API spec?

3. Did you develop a WebWork-like framework for your CMS portlets that follows JSR-168? If so, is it something that you might consider contributing to the open source community?

1. What's your opinion of JSR-170, the Content Repository API? Will your product implement it?

Yes, for portlets wanting to access our internal structure JSR170 seems like a decent way to do it. I'm halfway through a Level-1 implementation.

2. In developing your CMS portlets, how did you get around some of the limitations of the Portlet API (JSR-168) such as interportlet communication? Based on this experience, do you have any suggestions for the next version of the Portlet API spec?

Basically, right now we have limited interportlet communication, and in the cases where one portlet needs to create a link to another portlet we have proprietary support for it. Basically a portlet config UI (which in our case is always a Swing dialog) can select a target portlet which can then be accessed and used by the portlet through the PortletPreferences.

3. Did you develop a WebWork-like framework for your CMS portlets that follows JSR-168? If so, is it something that you might consider contributing to the open source community?

Currently we are using WebWork as-is with a few minor modifications. It works reasonably well, but the drawback is that such portlets only use the render()-phase, even for actions. A JSR168-specific version of WW is in the works, but I'm not doing it so I don't know the status.

Rickard,
  
    Thank you for your comments on your work, JSR-170 and AOP. I have learnt so much just by reading the threads.

I like to hear a bit more about your opinion on JSR-170.

I felt the central concept of JSR-170 is fine, with root of nodes and properties etc. But the JSR-170 seems mandate a heriarchical repository. IMHO, the API should agnostic about the how data is stored internally. API only provides the ways to organize, store, and retreive etc. JSR-170 seems to have mixed the these organization functions with how the repository are stored.

Since I am still digesting the JSR-170, so my opinion could be wrong. But I do like to hear what's your view on this.

Best Regards,

Chester

Currently we are using WebWork as-is with a few minor modifications. It works reasonably well, but the drawback is that such portlets only use the render()-phase, even for actions.

Isn't that true that the render phase isn't guaranteed to be called by the container every time the portlet renders ? And the container can choose to render the portlet from cache ? Only an action request is everytime guaranteed to be processed w/o cache involvment every time.

Can you please give some hints of how did you integrate WebWork into portlets so that they remain JSR 168 compatible ?

A JSR168-specific version of WW is in the works, but I'm not doing it so I don't know the status.

Can you tell who's doing it, I would be interested in the status. I thought about writing an XWork based portlet that would comply with JSR 168, but using only XWork I'd loose alot of web specific functionality developed in Webwork.

Isn't that true that the render phase isn't guaranteed to be called by the container every time the portlet renders ? And the container can choose to render the portlet from cache ? Only an action request is everytime guaranteed to be processed w/o cache involvment every time.

Correct. However, since I am the container implementor it simplifies things immensely with regard to what I can expect from the container :-)

Can you please give some hints of how did you integrate WebWork into portlets so that they remain JSR 168 compatible ?

We just made a very thin portlet wrapper that allows action switching from a request parameter instead of looking at the URL. That and some minor configuration tweaks to allow for separate xwork.xml files per portlet was about it.

Can you tell who's doing it, I would be interested in the status. I thought about writing an XWork based portlet that would comply with JSR 168, but using only XWork I'd loose alot of web specific functionality developed in Webwork.

Check the WW dev archives. It's two guys working on it.

Hi Rickard,

You mentioned using an LDAP server. Can you suggest or recommend an all-Java LDAP server?

Thank you,
David

Hi Rickard,You mentioned using an LDAP server. Can you suggest or recommend an all-Java LDAP server?Thank you,David

We almost always use Novell eDirectory if we have a choice (we have free OEM licences). In the cases we don't have a choice we are often stuck with Active Directory. No other LDAP directories come close really, in terms of usage and deployment.

I'm very much looking forward to see what happens with the Apache Directory server though.