Brix CMS - current status and future
Korbinian
in the last months quite few has happened to brix cms. I myself find
this very sad - and I'm not saying this because I invested much time
on it and also deployed some brix installations during that time, but
also because I still can't imagine to put up a new content based
project in wicket without using brix.
So, to move brix back onto the lane where it should be, I want to
start a discussion what has to be done and where the road should go.
My ideas would be following:
1st.: brix-cms on github needs https://github.com/brix-cms/brix-cms/tree/master
as default ASAP else everyone has the impression nothing happened for
ages as the OSGI branch is current head
2nd.: Brix needs love to get updated dependencies like jackrabbit,
modeshape etc. - so a whole POM care; during this I also would like to
get rid of *any* lucene deps where not necessary (meaning lucene deps
are only allowed within the jackrabbit modules - else this is a pain
for all using lucene as its not compatible between versions)
3rd.: we need a decision on the OSGI thing; While OSGI is a good idea,
I currently see it a problem in performance as this forces BrixCMS to
have a Registry that is somewhat synchronized; In my project this lead
to a big performance impact once JMeter started hammering; Making it
unsynchronized cured this immediately but the donwside is that dynamic
module changes are not possible; - if someone has a solution to this
it would be really cool :)
4th.: create a smaller-demo app, called "brix-blueprint" demo
containing only the necessary bits for a fast start and an empty
workspace.xml so new projects can be put up within few minutes instead
of forcing people to strip out things from an bigger demo - this then
could be a basement for an maven quickstart project!
5th.: after 1-4 are clear an new beta cycle should start so a new brix
release will happen on time
This is just an suggestion and open to discussion for all. Please let
me know what you think and what is good/ bad in your point of view.
Beside this, I also want to point to an upcoming star that may be a
very very good companion to BrixCMS: CDI - in my project I started
using CDI within brix as its the best way to glue together any
components and those components dont even need to know the other one.
It is perfect for loose coupling and would allow to get rid of many
special brix interfaces like PageParametersAware etc. if brix would
employ CDI within its inner core. However, I dont know how good/ bad
this would affect the users of Brix.
Best,
KB
Brian Topping
These are good and relevant points. I have also put a lot of time (and significant personal money last year!) into Brix projects. It does seem to be a shame for it to get stuck, but of course every contributor will have requirements they need satisfied in order to contribute. OSGi, which started as a fascination for me at one point, has become a requirement for me with new projects that I start.
There are a lot of nuances to my position about it, including that it should not be impossible to use Brix without an OSGi container, but at the same time, there seemed to be enough temporal momentum against modular programming architecture in the larger Wicket community last year that I kind of gave up.
I think the difference in Brix versus Wicket though is there should be far more opportunity for people to contribute and make a difference. Open source projects with little or no activity have no business rejecting changes when it would be easier to just fork the project and pull the rare changes from upstream when they happen. Since few believe forking is a good thing, I hope anyone would find that it's a good time to get involved with making the changes they wish to see in Brix and have their changes accepted without hesitation. Github is of course the primary facilitator in making these changes with complete attribution, and recent changes by Dan Simko were accepted quickly as a point of reference.
Note that any investment that one makes in an OSS project is going to be enhanced by unit tests covering some large percentage of the code. It would be sad to watch a revival of the code base and a lot of investment in it, only to find that it became unstable over time and people's investments were less effective than they might otherwise have been.
As far as implications of OSGi, it's better thought of as a classloading and runtime linkage architecture only. As such, once bundles are loaded, OSGi gets out of the way and does not interfere with the requirements of one's architecture, which as you point out may require synchronization for threading. In other words, it's not possible for OSGi to introduce performance costs for any runtime configuration that is only available in straight Java (without OSGi). Whether OSGi is introduced is an open question though. If I were to do it, I would do it such that it is not a requirement for Brix to run, and the runtime behavior in those cases would lose runtime loading functionality. I think that's a big deal, others clearly would not. As it stands today, it is not implemented and you can develop without thinking about it.
Hope that helps,
Brian
> --
> You received this message because you are subscribed to the Google Groups "brix-cms-discuss" group.
> To post to this group, send email to brix-cms...@googlegroups.com.
> To unsubscribe from this group, send email to brix-cms-discu...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/brix-cms-discuss?hl=en.
>
Korbinian
thank you for your post. I hope nobody got the impression I'm pro or
con OSGi - im rather in a position that I'm good with both routes.
Just to clarify a bit:
to 1st: this reason was issued as the current osgi-branch was
unupdated for over 7 months while the current master had last update 2
months ago, so more a cosmetic thing as 7 month unupdated looks
abandoned and this one is currently displayed every time someone
stumbled over our github page;
to 3rd.: I'm neither pro nor con OSGI and I use OSGI everyday in my
glassfish server and this is super performant - this was just the
problem I see with brix OSGI at the moment and this needs IMHO be
solved as synchronized registry limits performance (solving = getting
rid of this synchronized, not OSGI per se);
Regarding the forking: I use a brix-fork currently myself, still on
wicket 1.4, but Seam-CDI enhanced and also some fixes in the JCR layer
(running on ModeShape, not Jackrabbit), CDI-abled caching (on
Workspace and Tilenode-level) and synchronization free (meaning I can
spit out an page holding over 50 tiles, where over half of tiles is
configured, in under 90ms time including server-gzipping);
However, I find it better to enhance brix together in the future so
the effort should be put together than divided among many people; Also
the upcoming shifts like Java 6/ 7/ 8, wicket 1.6, JCR 3.0, JEE 6/ 7
etc. in the future will require quite some necessary work to benefit
from all new possibilities.
Best,
KB
On 27 Feb., 15:12, Brian Topping <brian.topp...@gmail.com> wrote:
> Hi Korbinian,
>
> These are good and relevant points. I have also put a lot of time (and significant personal money last year!) into Brix projects. It does seem to be a shame for it to get stuck, but of course every contributor will have requirements they need satisfied in order to contribute. OSGi, which started as a fascination for me at one point, has become a requirement for me with new projects that I start.
>
> There are a lot of nuances to my position about it, including that it should not be impossible to use Brix without an OSGi container, but at the same time, there seemed to be enough temporal momentum against modular programming architecture in the larger Wicket community last year that I kind of gave up.
>
> I think the difference in Brix versus Wicket though is there should be far more opportunity for people to contribute and make a difference. Open source projects with little or no activity have no business rejecting changes when it would be easier to just fork the project and pull the rare changes from upstream when they happen. Since few believe forking is a good thing, I hope anyone would find that it's a good time to get involved with making the changes they wish to see in Brix and have their changes accepted without hesitation. Github is of course the primary facilitator in making these changes with complete attribution, and recent changes by Dan Simko were accepted quickly as a point of reference.
>
> Note that any investment that one makes in an OSS project is going to be enhanced by unit tests covering some large percentage of the code. It would be sad to watch a revival of the code base and a lot of investment in it, only to find that it became unstable over time and people's investments were less effective than they might otherwise have been.
>
> As far as implications of OSGi, it's better thought of as a classloading and runtime linkage architecture only. As such, once bundles are loaded, OSGi gets out of the way and does not interfere with the requirements of one's architecture, which as you point out may require synchronization for threading. In other words, it's not possible for OSGi to introduce performance costs for any runtime configuration that is only available in straight Java (without OSGi). Whether OSGi is introduced is an open question though. If I were to do it, I would do it such that it is not a requirement for Brix to run, and the runtime behavior in those cases would lose runtime loading functionality. I think that's a big deal, others clearly would not. As it stands today, it is not implemented and you can develop without thinking about it.
>
> Hope that helps,
>
> Brian
>
> On Feb 27, 2012, at 7:48 AM, Korbinian wrote:
>
>
>
>
>
>
>
> > Hello,
>
> > in the last months quite few has happened to brix cms. I myself find
> > this very sad - and I'm not saying this because I invested much time
> > on it and also deployed some brix installations during that time, but
> > also because I still can't imagine to put up a new content based
> > project in wicket without using brix.
>
> > So, to move brix back onto the lane where it should be, I want to
> > start a discussion what has to be done and where the road should go.
>
> > My ideas would be following:
>
D S
from my point of view is most important to finish migrating Brix to Wicket 1.5. There is still a lot of mess in core classes like BrixRequestMapper, BrixNodePageUrlMapper, etc.
Currently I am trying to solve issue that org.apache.wicket.settings.IPageSettings#setRecreateMountedPagesAfterExpiry(true) is not working. And I am afraid that without Igor's (or other core developer's) hands it is almost impossible.
Best, Dan
Martin Grigorov
On Wed, Feb 29, 2012 at 12:00 AM, D S <wick...@gmail.com> wrote:
> Hello guys,
>
> from my point of view is most important to finish migrating Brix to Wicket
> 1.5. There is still a lot of mess in core classes like BrixRequestMapper,
> BrixNodePageUrlMapper, etc.
> Currently I am trying to solve issue that
> org.apache.wicket.settings.IPageSettings#setRecreateMountedPagesAfterExpiry(true)
> is not working. And I am afraid that without Igor's (or other core
> developer's) hands it is almost impossible.
'true' is the default value. Yesterday someone reported that he
experience a problem with it - a Link cannot be found after session
expiration. Were that you ?
Create a quickstart and attach it to Wicket's Jira. it should be easy
to debug it.
D S
It wasn't me yesterday. I know that 'true' is default but what I wanted to say was that this feature is not working in Brix. You always get pageexpirationexception after session expiration. Problem is not in Wicket but in Brix, specifically in BrixRequestMapper implementation.
Thank you.
Martin Grigorov
Then you can backport any improvements which are not directly related
to 6.0 to 1.5.
Can you describe the problem in more details or explain how to
reproduce it with the demo app ?
D S
I'll try to migrate Brix to Wicket 6.0.
That is great news! Thanks!
Then you can backport any improvements which are not directly related
to 6.0 to 1.5.
Ok, I will.
Can you describe the problem in more details or explain how to
reproduce it with the demo app ?
Yes, for example when you put http://localhost:8080/demos/stockquote.html?3 (or other number instead of 3) to your browser you get "Page Expired". Without '3' you get correct page.
Korbinian
is this happening with the latest master branch from
https://github.com/brix-cms/brix-cms/commits/master ?
Because there was a commit 2 months ago for a page-expiry bug:
https://github.com/brix-cms/brix-cms/commit/da536af7d28aa086f5fd76bd3b73617605fcf150
As I suggested above, we need certain points to go through and also
make a new beta cycle where we can fix problems like these. I know
that wicket 1.4 and 1.5 have sometimes problems with the expiration of
pages, but I think these can be solved as the wicket core devs are
very eager to catch those buggers. My aim is also in long term to lock
brixCMS main-releases to wicket-main releases so both prohjects
benefit more.
However, before I will start any work on this, I want a definitive
saying from the community/ users if they want my path or not :)
Best,
KB
PS: I'm sure Igor will help us as he did many times in the past when
we had troubles - but I don't expect him to do our own homework as he
is not actively using Brix currently AFAIK;
On 29 Feb., 09:54, D S <wicke...@gmail.com> wrote:
> On Wed, Feb 29, 2012 at 9:26 AM, Martin Grigorov
> > I'll try to migrate Brix to Wicket 6.0.
>
> That is great news! Thanks!
>
> > Then you can backport any improvements which are not directly related
> > to 6.0 to 1.5.
>
> Ok, I will.
>
> Can you describe the problem in more details or explain how to
>
> > reproduce it with the demo app ?
>
> Without '3' you get correct page.
>
>
>
>
>
>
>
>
>
> > On Wed, Feb 29, 2012 at 10:21 AM, D S <wicke...@gmail.com> wrote:
> > > Hi Martin,
>
> > > It wasn't me yesterday. I know that 'true' is default but what I wanted
> > to
> > > say was that this feature is not working in Brix. You always get
> > > pageexpirationexception after session expiration. Problem is not in
> > Wicket
> > > but in Brix, specifically in BrixRequestMapper implementation.
>
> > > Thank you.
>
> > > On Wed, Feb 29, 2012 at 8:58 AM, Martin Grigorov <
> > > wrote:
>
> > >> Hi,
> > >> On Wed, Feb 29, 2012 at 12:00 AM, D S <wicke...@gmail.com> wrote:
> > >> > Hello guys,
>
> > >> > from my point of view is most important to finish migrating Brix to
> > >> > Wicket
> > >> > 1.5. There is still a lot of mess in core classes like
> > >> > BrixRequestMapper,
> > >> > BrixNodePageUrlMapper, etc.
> > >> > Currently I am trying to solve issue that
>
> > org.apache.wicket.settings.IPageSettings#setRecreateMountedPagesAfterExpiry(true)
> > >> > is not working. And I am afraid that without Igor's (or other core
> > >> > developer's) hands it is almost impossible.
>
> > >> 'true' is the default value. Yesterday someone reported that he
> > >> experience a problem with it - a Link cannot be found after session
> > >> expiration. Were that you ?
> > >> Create a quickstart and attach it to Wicket's Jira. it should be easy
> > >> to debug it.
>
> > >> > Best, Dan
>
> > >> > On Mon, Feb 27, 2012 at 10:32 PM, Korbinian
>
> Erfahren Sie mehr »
danisevsky
2012/2/29 Korbinian <korbini...@googlemail.com>:
> Hello DS,
>
> is this happening with the latest master branch from
> https://github.com/brix-cms/brix-cms/commits/master ?
yes
>
> Because there was a commit 2 months ago for a page-expiry bug:
> https://github.com/brix-cms/brix-cms/commit/da536af7d28aa086f5fd76bd3b73617605fcf150
Before this commit you got some other exception (maybe NPE, I don't
remember) and now you get pageexpiredexception. I know it because this
is my commit :)
>
> As I suggested above, we need certain points to go through and also
> make a new beta cycle where we can fix problems like these. I know
> that wicket 1.4 and 1.5 have sometimes problems with the expiration of
> pages, but I think these can be solved as the wicket core devs are
> very eager to catch those buggers. My aim is also in long term to lock
> brixCMS main-releases to wicket-main releases so both prohjects
> benefit more.
>
> However, before I will start any work on this, I want a definitive
> saying from the community/ users if they want my path or not :)
I fully agree with your first and second points from your first email.
Korbinian
> remember) and now you get pageexpiredexception. I know it because this
> is my commit :)
Honestly, DS, D S, danisevsky, wickeria - your not some kind of CIA
guy? :D
But I'm with you that we need a working brix cms - thats the reason im
still on my old 1.4 truck :X
On 29 Feb., 12:17, danisevsky <danisev...@gmail.com> wrote:
> Hello Korbinian
>
> 2012/2/29 Korbinian <korbinian.ba...@googlemail.com>:
> > Hello DS,
>
> > is this happening with the latest master branch from
> >https://github.com/brix-cms/brix-cms/commits/master?
>
> yes
>
>
>
> > Because there was a commit 2 months ago for a page-expiry bug:
>
> Erfahren Sie mehr »
danisevsky
>> Before this commit you got some other exception (maybe NPE, I don't
>> remember) and now you get pageexpiredexception. I know it because this
>> is my commit :)
>
> Pah - that was wickeria :P
>
> Honestly, DS, D S, danisevsky, wickeria - your not some kind of CIA
> guy? :D
:D sorry for confusing. I am using danis...@gamil.com for brix,
wicket, jackrabbit, scala conferences and wick...@gmail.com for
personal emails and brix conference and I have a little bit hockey in
it sometimes. My name is Dan Simko and "danisevsky" is nick from
childhood.
danisevsky
2012/2/29 Martin Grigorov <martin....@gmail.com>:
Korbinian
do a pull request to brix master? that'll be great!
On 29 Feb., 17:19, danisevsky <danisev...@gmail.com> wrote:
> Thank you very much Martin! I will try your patch at the evening.
>
>
> Erfahren Sie mehr »
Igor Vaynberg
you guys can apply your own patches.
cheers,
-igor
D S
Thanks guys!
Dan Simko
Korbinian
confirm the problem got solved?
If all would be good with it then I would overhaul the POM's and add
the blueprint project to BrixCMS in the coming week (I'm abroad till
wednesday);
On 29 Feb., 22:46, D S <wicke...@gmail.com> wrote:
> Thank you very much Igor! I just merged Martin's patch plus some my little
> changes and now Brix works great for me!
>
> Thanks guys!
>
> Dan Simko
>
>
> Erfahren Sie mehr »
Martin Grigorov
Commit: https://github.com/martin-g/brix-cms/commit/d7daddb7d4b26db595ae8bf867499a946974bb7a
I've set Brix's version to 6.0-SNAPSHOT as well.
Do you want me to pull this in wicket6 branch or we will make a new
branch for Brix+Wicket1.5 (ver. 1.3.0) and merge this in master ?
Brian Topping
Cheers, Brian
D S
Yes Korbinian I can confirm that problem is solved. Except one thing (reloading the same page instance) but it's not so important I think.
Cheers, Dan
Korbinian
@DS: sounds good!
Point 1 of my list was done by Igor today, so brix-cms under github
now looks alive again :)
Point 2 (poms clearing) is my todo for next week, especially the
lucene dep's need to go to the jackrabbit-module as they will conflict
with ModeShape 3;
Point 3 needs someone who is OSGI aware for the overlook what problems
are a.t.m and what should be done with regards to osgi - at least the
current synchronized registry *has* to go unsynchronized for
performance;
Question to all: do you see a problem in requiring CDI in BrixCMS?
On 1 Mrz., 18:03, D S <wicke...@gmail.com> wrote:
> Can't wait to try Brix 6.0!
>
> Yes Korbinian I can confirm that problem is solved. Except one thing
> (reloading the same page instance) but it's not so important I think.
>
> Cheers, Dan
>
>
> Erfahren Sie mehr »
Martin Grigorov
<korbini...@googlemail.com> wrote:
> thanks @Brian
>
> @DS: sounds good!
>
> Point 1 of my list was done by Igor today, so brix-cms under github
> now looks alive again :)
>
> Point 2 (poms clearing) is my todo for next week, especially the
> lucene dep's need to go to the jackrabbit-module as they will conflict
> with ModeShape 3;
>
> Point 3 needs someone who is OSGI aware for the overlook what problems
> are a.t.m and what should be done with regards to osgi - at least the
> current synchronized registry *has* to go unsynchronized for
> performance;
>
>
> Question to all: do you see a problem in requiring CDI in BrixCMS?
I'm OK. I'll have to work with wicket-cdi in Wicket 6.0 anyway.
What functionalities of CDI you need in Brix ?
Brian Topping
On Mar 1, 2012, at 12:21 PM, Korbinian wrote:
> Point 3 needs someone who is OSGI aware for the overlook what problems
> are a.t.m and what should be done with regards to osgi - at least the
> current synchronized registry *has* to go unsynchronized for
> performance;
I thought you said the synchronized registry was unrelated to OSGi?
> Question to all: do you see a problem in requiring CDI in BrixCMS?
Can you elaborate on what would be affected and some of the benefits?
Brian
Brian Topping
On Mar 1, 2012, at 12:42 PM, Brian Topping wrote:
>> Question to all: do you see a problem in requiring CDI in BrixCMS?
>
> Can you elaborate on what would be affected and some of the benefits?
I should have added, if a requirement of Brix is that it can run without OSGi, then we need to make sure that any CDI configuration can also run both with and without OSGi.
Who knows, it might be easier with CDI, I'm just trying to make sure we don't overlook anything. :-)
Korbinian
>> Point 3 needs someone who is OSGI aware for the overlook what problems
>> are a.t.m and what should be done with regards to osgi - at least the
>> current synchronized registry *has* to go unsynchronized for
>> performance;
>
> I thought you said the synchronized registry was unrelated to OSGi?
existing tiles/ plugins) seemed to me to be necessary for OSGI, as I
can't think of any
other reason why it needs to be synchronized else, as if BrixCMS is
run in a classical fashin all Plugin/ Tiles data is written just once
into a registry and never changed after that - so, to be honest, I
thought it was an OSGI related "need", but I'm not sure about it; Hope
this clarifies what I meant.
> What functionalities of CDI you need in Brix ?
"tie" together tiles. First I manually created some event system
similar to what wicket 1.5 has - it never worked so well as I wanted
it to be.
I somehow stumbled over CDI and were quite astonished how neat this
can help wicket and brix cms. In the end, CDI allows you to easily
share data over borders you usually can't cross simply.
In the simplest case you can hold data for an request and let as many
tiles request this data. As long as the access path is followed (first
set data, then get it afterwards - meaning, you can set any data you
want in wickets constructors, and later query for it in e.g.:
onInitilize/ onBeforeRender etc.) you can share data without very low
overhead in terms of CPU as CDI is quite well integrated into the
containers.
While this sounds good at first only for tiles, it also allows a
decoupled way of how to distribute brix-cms data into tiles and brix
components. So instead of relying on certain functions like
BrixPageParameters.get(), getPage() etc. functions those could be put
into an BrixRequest object that itself is a @RequestScoped bean. So if
you need any data from the current request you would have a single
entry point to get all valid and possible data. This would eleminate
many repeated calls into a single requestScoped bean. Also this would
make it possible to easily get data like current JCR session, current
Page, current WorkspaceId etc. without any additional overhead while
shrinking the tiles as we need no more special interfaces (e.g:
PageParemetersAware);
Beside this, it also allows for a centralized, dedicated TileCache.
The TileCache is just an @ApplicationScoped bean that could be queried
like this:
@Inject
TileCache cache;
private final static String fooKey = "foo";
constructor(String id, IModel<BrixNode> tileNode) {
Reference foo = cache.getTileCache(tileNode, fooKey);
if(foo == null) {
foo = get the expensive reference to foo
cache.setTileCache(tileNode, fooKey, foo);
)
}
This would enhance speed dramatically as data that is needed
frequently is just hold in the memory (no serilization needed or
happens) - in my project I used this appriach and it speed up my index
page (~70 tiles on 3 layers) from ~240ms build time down to just ~45ms
(on my iMac late 2009 in wicket-dev mode)! Beside time it also relaxes
CPU and (!) JCR usage.
I'm sure if we can achive it that all bits are just created once and
then be distributed in an @RequestScoped object (like described above)
performance will even enhance further as the typicall JCR2 way to get
the WorkspaceID, properties etc. is often quite heavy and not seldom
inflicts locks within the JCR engine meaning it will block another
request for a bit of time.
So I see in CDI the chance to slim down brix in requirements of
interfaces, enhance/ ease up usage of its requestObjects and improve
performance.
Of course this change is not simple nor done fast (it is even possible
to slowly offer one serice after another, e.g: caching now, rest
later) - and I primarily want to get feedback from you all what you
think about this.
Best
KB
PS: If CDI is new for someone or he wonders if this is true, read
Igors posts about wicket and CDI:
https://www.42lines.net/2011/11/15/integrating-cdi-into-wicket/
Igor Vaynberg
boundaries if brix is to use cdi.
for example, one may be tempted to use cdi instead of brix's registry.
for example looping over all tile factories in cdi can be done like
this:
@Inject Instance<TileFactory> factories;
...
for (TileFactory factory:factories) { .. }
however, a cdi context, like spring and many other ioc containers is
not built around the idea that modules/jars can come and go, therefore
it is fundamentally incompatible with osgi. ie, one cannot unload a
jar from a cdi context. cdi builds all metadata on boot and caches it.
so be cognizant of this impedance mismatch when tweaking brix to use
cdi, because i do not think any cool meta-data discovery facilities
can be used.
-igor
Brian Topping
The registry is something that has been there since well before I started working on the project. So it's definitely not in there "for OSGi". I haven't scrutinized the code, but it sounds like a misfeature if a synchronization is happening on every page load.
Such synchronization will be necessary when modifying what plugins and tiles are available, the modifications will happen extremely rarely on a relative basis. For instance, I change/add/update plugins to Confluence / Jira once every several months on average. On a system under active development, the updates would coincide with a release schedule, typically two weeks plus any bug fix releases. Millions of pages could be served in that amount of time.
As a bundle is being changed, the container lifecycle would trigger a BundleListener, which would modify the registry / cache as appropriate. Those blocks of changes would need to be synchronized.
Automatic CDI injection may not be possible with any component that has the potential to change because once the component is injected into a bean, the reference is cached for the lifetime of the bean. Not having looked at org.glassfish::osgi-cdi-api, I don't know if proxies for services are injected that manage the dynamic nature of the referenced service. If it does, that would make the changes a lot cleaner throughout the code.
One of the nice things about OSGi is we can have multiple different versions of the same library available by version number. If plugin references from pages included version numbers they were created with, a repository would not have to be completely upgraded before a backwards-incompatible plugin could be used. If that were the case, plugin resolution would match this version number against the ranges provided by loaded plugins and the best match would be chosen, without having to upgrade the entire repository for any incompatible plugin change.
Korbinian
enough on OSGI, though use it every day "under-the-hood" in my
glassfish (and I think that Jboss AS7 and Glassfish somehow must have
solved the CDI/ OSGI problem). What I understood there is that it is
not possible to have OSGI get @Inject instances if those come from
outside its OSGI module, did I get this right? Beside that I never
thought about the registry itself for this feature (I'm not yet keen
enough in the inner core details to fully understand all wiring yet)
but more on the request data that brix delivers in every call of an
page (and IMHO thats the section where we loose most performance);
Regarding this problem I can think of 2 possible solutions:
-> use CDI inside brix and let it be accessible via CDI for non OSGI
environments while OSGI environments should be able to access it via a
stub reference (e.g.: CurrentBrixRequest.get().getCache() - similar to
the BrixPageParemeters.get());
-> ignore OSGI and instead aim for JIGSAW later on as it can't ignore
CDI as both are part of upcoming spec (would be a big impact and be
possible in about 1-2 years from now earliest as we need Java8 at
least);
The second is technically tempting but not really what I would suggest
as it would be a big drawback for all OSGI attention so far. So I
wonder if some OSGI user could tell me if solution 1 would work? At
least it seems similar to the current way to access the centralized
registry, isn't it?
Brian Topping
On Mar 2, 2012, at 4:36 AM, Korbinian wrote:
> Regarding this problem I can think of 2 possible solutions:
>
> -> use CDI inside brix and let it be accessible via CDI for non OSGI
> environments while OSGI environments should be able to access it via a
> stub reference (e.g.: CurrentBrixRequest.get().getCache() - similar to
> the BrixPageParemeters.get());
>
> -> ignore OSGI and instead aim for JIGSAW later on as it can't ignore
> CDI as both are part of upcoming spec (would be a big impact and be
> possible in about 1-2 years from now earliest as we need Java8 at
> least);
Well, of course the third is not to use CDI at all.
Korbinian
True, but at the cost of future performance enhancement and complexity
reduction
Brian Topping
On Mar 2, 2012, at 11:30 AM, Korbinian wrote:
> True, but at the cost of future performance enhancement and complexity
> reduction
How complex would it be to create a dynamic runtime loaded module system for plugins? Could it be done more easily in some other way with less complexity?
In general, performance won't be affected by CDI. DI is an architectural pattern, not a performance improvement. As a pattern, it does reduce complexity, but more by creating a standard pattern for object aggregation, not because the patterns that DI promotes could not be done without CDI or a container that implements it like Spring. If developers write more efficient code because formalized DI forces them to, it's a little hard to argue that CDI was the source of the performance enhancement.
It's all semantics, I just want to make sure we're talking about the same thing and fill in any gaps I might have along the way.
Korbinian
One thing I don't yet understand is how OSGI locks itself in.
Basically as one needs to somehow access Brix from within its OSGI
module (else he can't do anything useful in his tiles), he needs to at
least be able to reach the current running Brix.get() - doesnt he need
to?
If he is able to reach Brix.get() he also should be able to call
Brix.get().getCurrentRequest() - giving back a stub of the
currentReqest() object?
This then means if currentRequest() is the entry point for OSGI users
- not as nice as e.g.: - @Inject CurrentRequest request - but not
much more difficult - and in terms of an centralized cache it also
would make no real difference as e.g.: Brix.get().getCache() is equal
to - @Inject Cache cache - as the Brix-instance itself is the only one
needed to be able to access the @ApplicationScoped resource, isnt this
true? Because then I don't see any problem as long as we provide 2
entry points - one for CDI users, one for OSGI.
Beside this theoretical discussion, my idea to introduce CDI is not by
starting by an imminent rewrite but instead add an module that
introduces the tile cache I mentioned above as this is already the
tool needed to speed up custom tiles and to show the might behind;
Later on we could even enhance brix own tiles with it by adding an
empty beans.xml, add @Inject cache in it and before quriying the cache
make a cache != null check as in non CDI environments - meaning your
OSGI didnt bootstrap OSGI - this won't affect anything (the @Inject is
just ignored leaving the cache an empty null field);
Really need to take a look at this next week....
Korbinian
that its written towards JCR 1.0 and uses many in JCR 2.0 deprecated
ways of obtaining data. So because of CDI's simple scope's I used this
to gather data and cache it within CDI beans - however, I also can
live with different ways of achiving this as long as we can simplify
brix usage.
> How complex would it be to create a dynamic runtime loaded module system for plugins? Could it be done more easily in some other way with less complexity?
can go without creating our own "osgi-container". I mean those modules
can bring tiles - easy in terms of some panels, but what when they
bring JPA modules with them? What happens when other resources are
needed? I somehow fear we come too close to reinventing OSGI at some
point... on the other hand, there is quite work going on to bring OSGI
and CDI together like e.g: http://www.slideshare.net/TrevorReznik/weldosgi-injecting-easiness-in-osgi
Brian Topping
Thus, when a static Brix instance is loaded inside an OSGi container, it does so exactly like it is done with a non-OSGi container and the lifecycle of the Brix instance is indistinguishable. Classes ask the classloader where to resolve a reference and the transitive closure of linkages are resolved. There is no dependency by any class on org.osgi.* from any class in a static Brix instance and CDI would work fine.
The problem with annotated DI references is they are *only* resolved and injected by the DI container when a service is loaded. Unless there is some hotshot dynamic proxy voodoo going on with the injected dependencies, a problem occurs when a service is dynamically unloaded because now you have a stale reference to an unloaded OSGi service sitting in some other service.
Note that an @ApplicationScoped injection is probably not going to cause any problem if it is never unloaded. I don't see why that would require different APIs, but differences in how Brix is bootstrapped between static and dynamic classpathing is probably going to be required.
The key to me is what classes depend on org.osgi.*. The implementation needs to have strong containment for these compile-time dependencies to a small section of code (not plugins). If we can pull that off, we should be good.
For my part in this, I am not against CDI. Quite to the contrary it would may well be a benefit for deploying OSGi.
Brian Topping
On Mar 2, 2012, at 12:20 PM, Korbinian wrote:
> I somehow fear we come too close to reinventing OSGI at some
> point...
Exactly my point.
Korbinian
either fix or revert to the point prior we tried it :D
Brian Topping
Martin Grigorov
I just pushed my 'wicket6' branch to
https://github.com/brix-cms/brix-cms/tree/wicket6.
About OSGi+CDI: I guess you are aware of PAX-Wicket
(https://github.com/ops4j/org.ops4j.pax.wicket). It provides
integrations with Aries Blueprint and SpringDM. I guess it wont be
hard to add yet another integration for CDI. Andreas PIeber is
subscribed here so he can help with anything related to PAX.
Andreas Pieber
Basically implementing CDI iteself wouldn't be too hard. Everything
required therefore should be already available in pax-wicket. I see
ways bigger problems in the conceptional planning of the integration
instead of the real implementation. For example: I assume you would
like to source the beans directly from the OSGi registry? From spring
and blueprint? An problem here (independent of the source) is that
osgi does not know any concept of stateful beans. There is no concept
to create new instances of services for each injection. Therefore
we'll also need to add factories here... Just to name one of (as I
assume) many problems.
Kind regards,
Andreas
Korbinian
just got back from a long trip;
@Marting Grig. : nice work - from what I've seen is that most changes
are packages and some minor tweaks like the Ajaxxxx.get() - somehwo
seems as wicket1.5 -> wicket 6 move is smaller than 1.4 to 1.5, isn't
it?
@Andreas:
thank you for the comment; I'm not very keen on OSGI but I do see the
problem you mention, so I'm asking myself if there is another approach
to solve our coming needs. So instead of injecting CDI into OSGI
modules, wouldn't it be possible to have the brix-core a static method
to retrieve the - within the core request - injected instance from any
outside CDI module? At least I expect that the OSGI module will have
to know the core, else it can't use Brix.
In the end, we need 2 Scopes somehow solved. First we need an
application wide scope to be used as a memory caching instance. While
CDI takes away its handling and some concurrent problems, it also
could be solved by using a central class from brix-core (initilized in
the init() method, stored in Brix instance, called by a "static"
Brix.get().getCache... method) - however, we also need an object that
is tied to the Request itself - RequestScoped in CDI - as we need to
put data for the servlet/page request and JCR request in it with
request based "short-caching" and this is where I don't know how to
solve it in a way that also the central class mentioned first can
access the request data as it needs it for cached querying (problem
is: to cache data we need to have a key thats composed upon cache-id,
tile-node id and (!) workspaceId
{
1st: we can't guarantee that 2 tiles wont have same name for an cache
2nd: we can't guarantee that different workspaces dont use same tile-
node-id's - especially when cloned
3rd: we can't guarantee that we only have 1 workspace having the same
tiles
})
On 5 Mrz., 11:58, Andreas Pieber <anpie...@gmail.com> wrote:
> Hey Guys,
>
> Basically implementing CDI iteself wouldn't be too hard. Everything
> required therefore should be already available in pax-wicket. I see
> ways bigger problems in the conceptional planning of the integration
> instead of the real implementation. For example: I assume you would
> like to source the beans directly from the OSGi registry? From spring
> and blueprint? An problem here (independent of the source) is that
> osgi does not know any concept of stateful beans. There is no concept
> to create new instances of services for each injection. Therefore
> we'll also need to add factories here... Just to name one of (as I
> assume) many problems.
>
> Kind regards,
> Andreas
>
>
>
>
>
>
>
> On Mon, Mar 5, 2012 at 10:31, Martin Grigorov <martin.grigo...@gmail.com> wrote:
> > Hi,
>
> > I just pushed my 'wicket6' branch to
> >https://github.com/brix-cms/brix-cms/tree/wicket6.
>
> > About OSGi+CDI: I guess you are aware of PAX-Wicket
> > (https://github.com/ops4j/org.ops4j.pax.wicket). It provides
> > integrations with Aries Blueprint and SpringDM. I guess it wont be
> > hard to add yet another integration for CDI. Andreas PIeber is
> > subscribed here so he can help with anything related to PAX.
>
Martin Grigorov
<korbini...@googlemail.com> wrote:
> Hiya,
>
> just got back from a long trip;
>
> @Marting Grig. : nice work - from what I've seen is that most changes
> are packages and some minor tweaks like the Ajaxxxx.get() - somehwo
> seems as wicket1.5 -> wicket 6 move is smaller than 1.4 to 1.5, isn't
> it?
Yes. The transition to 6.0 should be much easier than 1.4->1.5.
Roadmap: https://cwiki.apache.org/confluence/display/WICKET/Wicket+6.0+Roadmap
Migration: https://cwiki.apache.org/confluence/x/oayoAQ
I'm moving some more classes around atm to make Wicket more friendly
for OSGi users.
Andreas Pieber
JSR-299 and doing some whiteboard work I think we might find a neat
way to integrate osgi & CDI & (pax-)wicket; nevertehless this will
need some more than trivial example to make this work properly. One
way to go might be: use CDI and base osgi/IOC rules for brix (clean
package structure, api/internal seperation, ...) for brix. Once the
base functionality is working with "plain" wicket/weld we can create a
new branch and start replacing WELD with an implementation in
pax-wicket side by side. Once we're happy with this branch it can be
merged back into the master. I think brix could be an interesting,
non-trivial prototype for CDI/osgi/wicket integration.
Kind regards,
Andreas
Korbinian
sounds very promising and good -
I can set up an special brix-branch in my repo where I use current
brix master and enhance the demo with the CDI caching example I posted
earlier and a demo tile if you like!
I'm not sure I have time tomorrow, but friday at latest it'll be
ready.
>
> Erfahren Sie mehr »
Martin Grigorov
Weld team will work on OSGi integration
Andreas Pieber
Thx for the pointer Martin.
Kind regards,
Andreas