You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Charles Moulliard <cm...@gmail.com> on 2011/03/02 18:37:10 UTC
[suggestion] - OSGI WebConsole
Hi,
As three users of Apache Felix WebConsole project, I contact you to
have your opinion regarding to frameworks (JSon, javascript, ...)
usage made with Apache Felix WebConsole. The project has been made
light to avoid dependencies with external librairies but the way that
it is used today lack of structure, complicate the
development of screens and decrease development productivity, html
code is mixed in javascript, json variables are set everywhere in the
code and use in several of javascript functions, no template is used
to render html pages, locale is not used by all of us to translate
text, ....
The consequence of that is that some developers are very frustrated
and would like to make some suggestions about Webconsole. Within Karaf
community we already started this discussion and now we would like to
share with you some ideas about the future roadmap of Felix
WebConsole.
Here are the different scenario possible :
(1) Improve the existing usage of the frameworks JSon, OSGI and
javascript by defining/providing a "template" project containing dummy
code + guidelines/best practices to develop properly and so
improve/increase productivity. This could be done with an archetype
(2) Switch the existing architectural model to use frameworks like
Apache Wicket or Vaadin where the content is clearly separated from
the server side code. Apache Wicket and Vaadin librairies are already
osgified so their integration in project like karaf, sling or felix
will be done seamless even if we have the overhead to deploy them. But
this is also the same for bundles like PAX-Web, ...
No matter which scenario we will decide to adopt, we could also create
a project to develop all together the OSGI WebConsole used by our
projects and promote it as a new Apache project --> Name suggested
Apache Orion. The scope of this project could be extended to include
additional management, registration of datasources, ....
What do you think my propositions ?
Regards,
Charles Moulliard
Apache Committer
Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard
Re: [suggestion] - OSGI WebConsole
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Charles,
Thanks for launching the idea that we discussed on IRC.
As I said, my point of view is that we need a kind of median console
projects for Apache middleware projects.
For instance, a lot of stuff is share in all web console of these
projects (user authentication, authentication backend, JMX client, etc,
etc).
By projects, I've identified: Karaf, Felix, ServiceMix, CXF, Camel,
Geronimo, (maybe ACE), ActiveMQ, Sling, Tomcat, DS, James, certainly
others :).
If we can provide a plug and play and branding WebConsole, all these
projects can use it.
My vision is that we need a generic console (monitoring, management
oriented) that could be extended by each project.
Depending of the different communities feedback, it could have sense to
submit to the incubator mailing list. Maybe we can think about an Apache
Operational Network Console (Apache ONC) with plugins provided by the
Apache projects.
Regards
JB
On 03/02/2011 06:37 PM, Charles Moulliard wrote:
> Hi,
>
> As three users of Apache Felix WebConsole project, I contact you to
> have your opinion regarding to frameworks (JSon, javascript, ...)
> usage made with Apache Felix WebConsole. The project has been made
> light to avoid dependencies with external librairies but the way that
> it is used today lack of structure, complicate the
> development of screens and decrease development productivity, html
> code is mixed in javascript, json variables are set everywhere in the
> code and use in several of javascript functions, no template is used
> to render html pages, locale is not used by all of us to translate
> text, ....
>
> The consequence of that is that some developers are very frustrated
> and would like to make some suggestions about Webconsole. Within Karaf
> community we already started this discussion and now we would like to
> share with you some ideas about the future roadmap of Felix
> WebConsole.
>
> Here are the different scenario possible :
>
> (1) Improve the existing usage of the frameworks JSon, OSGI and
> javascript by defining/providing a "template" project containing dummy
> code + guidelines/best practices to develop properly and so
> improve/increase productivity. This could be done with an archetype
>
> (2) Switch the existing architectural model to use frameworks like
> Apache Wicket or Vaadin where the content is clearly separated from
> the server side code. Apache Wicket and Vaadin librairies are already
> osgified so their integration in project like karaf, sling or felix
> will be done seamless even if we have the overhead to deploy them. But
> this is also the same for bundles like PAX-Web, ...
>
> No matter which scenario we will decide to adopt, we could also create
> a project to develop all together the OSGI WebConsole used by our
> projects and promote it as a new Apache project --> Name suggested
> Apache Orion. The scope of this project could be extended to include
> additional management, registration of datasources, ....
>
> What do you think my propositions ?
>
> Regards,
>
> Charles Moulliard
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
Re: [suggestion] - OSGI WebConsole
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Charles,
Thanks for launching the idea that we discussed on IRC.
As I said, my point of view is that we need a kind of median console
projects for Apache middleware projects.
For instance, a lot of stuff is share in all web console of these
projects (user authentication, authentication backend, JMX client, etc,
etc).
By projects, I've identified: Karaf, Felix, ServiceMix, CXF, Camel,
Geronimo, (maybe ACE), ActiveMQ, Sling, Tomcat, DS, James, certainly
others :).
If we can provide a plug and play and branding WebConsole, all these
projects can use it.
My vision is that we need a generic console (monitoring, management
oriented) that could be extended by each project.
Depending of the different communities feedback, it could have sense to
submit to the incubator mailing list. Maybe we can think about an Apache
Operational Network Console (Apache ONC) with plugins provided by the
Apache projects.
Regards
JB
On 03/02/2011 06:37 PM, Charles Moulliard wrote:
> Hi,
>
> As three users of Apache Felix WebConsole project, I contact you to
> have your opinion regarding to frameworks (JSon, javascript, ...)
> usage made with Apache Felix WebConsole. The project has been made
> light to avoid dependencies with external librairies but the way that
> it is used today lack of structure, complicate the
> development of screens and decrease development productivity, html
> code is mixed in javascript, json variables are set everywhere in the
> code and use in several of javascript functions, no template is used
> to render html pages, locale is not used by all of us to translate
> text, ....
>
> The consequence of that is that some developers are very frustrated
> and would like to make some suggestions about Webconsole. Within Karaf
> community we already started this discussion and now we would like to
> share with you some ideas about the future roadmap of Felix
> WebConsole.
>
> Here are the different scenario possible :
>
> (1) Improve the existing usage of the frameworks JSon, OSGI and
> javascript by defining/providing a "template" project containing dummy
> code + guidelines/best practices to develop properly and so
> improve/increase productivity. This could be done with an archetype
>
> (2) Switch the existing architectural model to use frameworks like
> Apache Wicket or Vaadin where the content is clearly separated from
> the server side code. Apache Wicket and Vaadin librairies are already
> osgified so their integration in project like karaf, sling or felix
> will be done seamless even if we have the overhead to deploy them. But
> this is also the same for bundles like PAX-Web, ...
>
> No matter which scenario we will decide to adopt, we could also create
> a project to develop all together the OSGI WebConsole used by our
> projects and promote it as a new Apache project --> Name suggested
> Apache Orion. The scope of this project could be extended to include
> additional management, registration of datasources, ....
>
> What do you think my propositions ?
>
> Regards,
>
> Charles Moulliard
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
Re: [suggestion] - OSGI WebConsole
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
First: This is the last cross posted message from me. Future
communication should and will take place on the Felix list.
Please, come to that list and discuss with us here !
Am Donnerstag, den 03.03.2011, 07:40 +0000 schrieb Charles Moulliard:
> On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
> > Hi,
> >
> > As the original developer of the Web Console I am flattered by this
> > activity ;-)
> >
> > Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
> >> Hi,
> >>
> >> As three users of Apache Felix WebConsole project, I contact you to
> >> have your opinion regarding to frameworks (JSon, javascript, ...)
> >> usage made with Apache Felix WebConsole. The project has been made
> >> light to avoid dependencies with external librairies but the way that
> >> it is used today lack of structure, complicate the
> >
> > Why lack of structure ?
>
> >>> Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble.
Well, this is just an implementation detail of the plugins coming with
the Web Console proper. Nowhere is it prescribed that you have to do it
this way.
I think Guillaume has clearly described the issues around this.
>
> >
> >> development of screens and decrease development productivity, html
> >> code is mixed in javascript, json variables are set everywhere in the
> >> code and use in several of javascript functions, no template is used
> >> to render html pages, locale is not used by all of us to translate
> >> text, ....
> >
> > That's all not required. The simplest plugin is a Servlet service with
> > two service properties. Nothing fancy, really ;-)
> >
> >>
> >> The consequence of that is that some developers are very frustrated
> >> and would like to make some suggestions about Webconsole. Within Karaf
> >> community we already started this discussion and now we would like to
> >> share with you some ideas about the future roadmap of Felix
> >> WebConsole.
> >
> > I'm sorry you are "very frustrated" .. at the same time I do not
> > understand why you don't come to the Felix dev or user list to ask
> > questions ? This is a bit frustrating to me.
> >
>
> >>> The word "frustrated" was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation.
The Web Console lives in the Apache Felix project. So please, come to
use and talk to us. Start the discussion here and with us. We will
listen to you.
>
> >>
> >> Here are the different scenario possible :
> >>
> >> (1) Improve the existing usage of the frameworks JSon, OSGI and
> >> javascript by defining/providing a "template" project containing dummy
> >> code + guidelines/best practices to develop properly and so
> >> improve/increase productivity. This could be done with an archetype
> >
> > Sounds like an excellent idea.
> >
> >>
> >> (2) Switch the existing architectural model to use frameworks like
> >> Apache Wicket or Vaadin where the content is clearly separated from
> >> the server side code. Apache Wicket and Vaadin librairies are already
> >> osgified so their integration in project like karaf, sling or felix
> >> will be done seamless even if we have the overhead to deploy them. But
> >> this is also the same for bundles like PAX-Web, ...
> >
> > Sounds like not soo go an idea. There is a reason why we don't use any
> > of these frameworks: We wanted (and still want) to minimize
> > dependencies. Adding such a nice GUI framework to the game makes it more
> > complicated (remember the simple Servlet service mentioned above ?) and
> > heavy weight.
>
> >>> Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact.
I know very well about the functionality provided by those platforms.
But all these platforms come with additional dependencies. And this is
where I start placing question marks.
Also be reminded that Web Console is currently being used in embedded
platforms which don't have place to spare for the developers delight.
>
> >
> > However, this is not to say, that we should not explore ways on how
> > mechanism like JSP (or generic server side scripting) etc. can be used.
> >
> >>
> >> No matter which scenario we will decide to adopt, we could also create
> >> a project to develop all together the OSGI WebConsole used by our
> >> projects and promote it as a new Apache project --> Name suggested
> >> Apache Orion. The scope of this project could be extended to include
> >> additional management, registration of datasources, ....
> >
> > What would be the advantage of developing the Web Console in its own
> > TLP ? Is there something missing when living in the Felix project ?
>
> >>> If we add new features/functionalities (like also mentioned by Jean Baptiste D' Onofre), the debate about the location
> of this project is not insignifiant and becomes relevant like also
> that this project becomes a TLP. I do not at all defend a point of
> view to move this Felix sub-project but open the debate
Will bring this to a different thread.
Regards
Felix
>
> >
> > Regards
> > Felix
> >
> >>
> >> What do you think my propositions ?
> >>
> >> Regards,
> >>
> >> Charles Moulliard
> >> Apache Committer
> >>
> >> Blog : http://cmoulliard.blogspot.com
> >> Twitter : http://twitter.com/cmoulliard
> >> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> >> Skype: cmoulliard
> >
> >
> >
Re: [suggestion] - OSGI WebConsole
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
First: This is the last cross posted message from me. Future
communication should and will take place on the Felix list.
Please, come to that list and discuss with us here !
Am Donnerstag, den 03.03.2011, 07:40 +0000 schrieb Charles Moulliard:
> On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
> > Hi,
> >
> > As the original developer of the Web Console I am flattered by this
> > activity ;-)
> >
> > Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
> >> Hi,
> >>
> >> As three users of Apache Felix WebConsole project, I contact you to
> >> have your opinion regarding to frameworks (JSon, javascript, ...)
> >> usage made with Apache Felix WebConsole. The project has been made
> >> light to avoid dependencies with external librairies but the way that
> >> it is used today lack of structure, complicate the
> >
> > Why lack of structure ?
>
> >>> Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble.
Well, this is just an implementation detail of the plugins coming with
the Web Console proper. Nowhere is it prescribed that you have to do it
this way.
I think Guillaume has clearly described the issues around this.
>
> >
> >> development of screens and decrease development productivity, html
> >> code is mixed in javascript, json variables are set everywhere in the
> >> code and use in several of javascript functions, no template is used
> >> to render html pages, locale is not used by all of us to translate
> >> text, ....
> >
> > That's all not required. The simplest plugin is a Servlet service with
> > two service properties. Nothing fancy, really ;-)
> >
> >>
> >> The consequence of that is that some developers are very frustrated
> >> and would like to make some suggestions about Webconsole. Within Karaf
> >> community we already started this discussion and now we would like to
> >> share with you some ideas about the future roadmap of Felix
> >> WebConsole.
> >
> > I'm sorry you are "very frustrated" .. at the same time I do not
> > understand why you don't come to the Felix dev or user list to ask
> > questions ? This is a bit frustrating to me.
> >
>
> >>> The word "frustrated" was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation.
The Web Console lives in the Apache Felix project. So please, come to
use and talk to us. Start the discussion here and with us. We will
listen to you.
>
> >>
> >> Here are the different scenario possible :
> >>
> >> (1) Improve the existing usage of the frameworks JSon, OSGI and
> >> javascript by defining/providing a "template" project containing dummy
> >> code + guidelines/best practices to develop properly and so
> >> improve/increase productivity. This could be done with an archetype
> >
> > Sounds like an excellent idea.
> >
> >>
> >> (2) Switch the existing architectural model to use frameworks like
> >> Apache Wicket or Vaadin where the content is clearly separated from
> >> the server side code. Apache Wicket and Vaadin librairies are already
> >> osgified so their integration in project like karaf, sling or felix
> >> will be done seamless even if we have the overhead to deploy them. But
> >> this is also the same for bundles like PAX-Web, ...
> >
> > Sounds like not soo go an idea. There is a reason why we don't use any
> > of these frameworks: We wanted (and still want) to minimize
> > dependencies. Adding such a nice GUI framework to the game makes it more
> > complicated (remember the simple Servlet service mentioned above ?) and
> > heavy weight.
>
> >>> Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact.
I know very well about the functionality provided by those platforms.
But all these platforms come with additional dependencies. And this is
where I start placing question marks.
Also be reminded that Web Console is currently being used in embedded
platforms which don't have place to spare for the developers delight.
>
> >
> > However, this is not to say, that we should not explore ways on how
> > mechanism like JSP (or generic server side scripting) etc. can be used.
> >
> >>
> >> No matter which scenario we will decide to adopt, we could also create
> >> a project to develop all together the OSGI WebConsole used by our
> >> projects and promote it as a new Apache project --> Name suggested
> >> Apache Orion. The scope of this project could be extended to include
> >> additional management, registration of datasources, ....
> >
> > What would be the advantage of developing the Web Console in its own
> > TLP ? Is there something missing when living in the Felix project ?
>
> >>> If we add new features/functionalities (like also mentioned by Jean Baptiste D' Onofre), the debate about the location
> of this project is not insignifiant and becomes relevant like also
> that this project becomes a TLP. I do not at all defend a point of
> view to move this Felix sub-project but open the debate
Will bring this to a different thread.
Regards
Felix
>
> >
> > Regards
> > Felix
> >
> >>
> >> What do you think my propositions ?
> >>
> >> Regards,
> >>
> >> Charles Moulliard
> >> Apache Committer
> >>
> >> Blog : http://cmoulliard.blogspot.com
> >> Twitter : http://twitter.com/cmoulliard
> >> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> >> Skype: cmoulliard
> >
> >
> >
Re: [suggestion] - OSGI WebConsole
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Mar 3, 2011 at 08:40, Charles Moulliard <cm...@gmail.com> wrote:
> On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Hi,
>>
>> As the original developer of the Web Console I am flattered by this
>> activity ;-)
>>
>> Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
>>> Hi,
>>>
>>> As three users of Apache Felix WebConsole project, I contact you to
>>> have your opinion regarding to frameworks (JSon, javascript, ...)
>>> usage made with Apache Felix WebConsole. The project has been made
>>> light to avoid dependencies with external librairies but the way that
>>> it is used today lack of structure, complicate the
>>
>> Why lack of structure ?
>
>>>> Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble
That's a really common thing when using AJAX to render data. I think
you missed the point that the servlet render JSON data which could be
used by another tool / plugin with a different view.
So the data acces / json rendering is done on the server side while
the html pages usually use javascript to render the json data into
html. That's a clean separation and allows reloading the page without
reloading the full html page.
.
>
>>
>>> development of screens and decrease development productivity, html
>>> code is mixed in javascript, json variables are set everywhere in the
>>> code and use in several of javascript functions, no template is used
>>> to render html pages, locale is not used by all of us to translate
>>> text, ....
>>
>> That's all not required. The simplest plugin is a Servlet service with
>> two service properties. Nothing fancy, really ;-)
>>
>>>
>>> The consequence of that is that some developers are very frustrated
>>> and would like to make some suggestions about Webconsole. Within Karaf
>>> community we already started this discussion and now we would like to
>>> share with you some ideas about the future roadmap of Felix
>>> WebConsole.
>>
>> I'm sorry you are "very frustrated" .. at the same time I do not
>> understand why you don't come to the Felix dev or user list to ask
>> questions ? This is a bit frustrating to me.
>>
>
>>>> The word "frustrated" was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation.
>>>
>>> Here are the different scenario possible :
>>>
>>> (1) Improve the existing usage of the frameworks JSon, OSGI and
>>> javascript by defining/providing a "template" project containing dummy
>>> code + guidelines/best practices to develop properly and so
>>> improve/increase productivity. This could be done with an archetype
>>
>> Sounds like an excellent idea.
>>
>>>
>>> (2) Switch the existing architectural model to use frameworks like
>>> Apache Wicket or Vaadin where the content is clearly separated from
>>> the server side code. Apache Wicket and Vaadin librairies are already
>>> osgified so their integration in project like karaf, sling or felix
>>> will be done seamless even if we have the overhead to deploy them. But
>>> this is also the same for bundles like PAX-Web, ...
>>
>> Sounds like not soo go an idea. There is a reason why we don't use any
>> of these frameworks: We wanted (and still want) to minimize
>> dependencies. Adding such a nice GUI framework to the game makes it more
>> complicated (remember the simple Servlet service mentioned above ?) and
>> heavy weight.
>
>>>> Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact.
>
>>
>> However, this is not to say, that we should not explore ways on how
>> mechanism like JSP (or generic server side scripting) etc. can be used.
>>
>>>
>>> No matter which scenario we will decide to adopt, we could also create
>>> a project to develop all together the OSGI WebConsole used by our
>>> projects and promote it as a new Apache project --> Name suggested
>>> Apache Orion. The scope of this project could be extended to include
>>> additional management, registration of datasources, ....
>>
>> What would be the advantage of developing the Web Console in its own
>> TLP ? Is there something missing when living in the Felix project ?
>
>>>> If we add new features/functionalities (like also mentioned by Jean Baptiste D' Onofre), the debate about the location
> of this project is not insignifiant and becomes relevant like also
> that this project becomes a TLP. I do not at all defend a point of
> view to move this Felix sub-project but open the debate
>
>>
>> Regards
>> Felix
>>
>>>
>>> What do you think my propositions ?
>>>
>>> Regards,
>>>
>>> Charles Moulliard
>>> Apache Committer
>>>
>>> Blog : http://cmoulliard.blogspot.com
>>> Twitter : http://twitter.com/cmoulliard
>>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>>> Skype: cmoulliard
>>
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [suggestion] - OSGI WebConsole
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
First: This is the last cross posted message from me. Future
communication should and will take place on the Felix list.
Please, come to that list and discuss with us here !
Am Donnerstag, den 03.03.2011, 07:40 +0000 schrieb Charles Moulliard:
> On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
> > Hi,
> >
> > As the original developer of the Web Console I am flattered by this
> > activity ;-)
> >
> > Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
> >> Hi,
> >>
> >> As three users of Apache Felix WebConsole project, I contact you to
> >> have your opinion regarding to frameworks (JSon, javascript, ...)
> >> usage made with Apache Felix WebConsole. The project has been made
> >> light to avoid dependencies with external librairies but the way that
> >> it is used today lack of structure, complicate the
> >
> > Why lack of structure ?
>
> >>> Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble.
Well, this is just an implementation detail of the plugins coming with
the Web Console proper. Nowhere is it prescribed that you have to do it
this way.
I think Guillaume has clearly described the issues around this.
>
> >
> >> development of screens and decrease development productivity, html
> >> code is mixed in javascript, json variables are set everywhere in the
> >> code and use in several of javascript functions, no template is used
> >> to render html pages, locale is not used by all of us to translate
> >> text, ....
> >
> > That's all not required. The simplest plugin is a Servlet service with
> > two service properties. Nothing fancy, really ;-)
> >
> >>
> >> The consequence of that is that some developers are very frustrated
> >> and would like to make some suggestions about Webconsole. Within Karaf
> >> community we already started this discussion and now we would like to
> >> share with you some ideas about the future roadmap of Felix
> >> WebConsole.
> >
> > I'm sorry you are "very frustrated" .. at the same time I do not
> > understand why you don't come to the Felix dev or user list to ask
> > questions ? This is a bit frustrating to me.
> >
>
> >>> The word "frustrated" was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation.
The Web Console lives in the Apache Felix project. So please, come to
use and talk to us. Start the discussion here and with us. We will
listen to you.
>
> >>
> >> Here are the different scenario possible :
> >>
> >> (1) Improve the existing usage of the frameworks JSon, OSGI and
> >> javascript by defining/providing a "template" project containing dummy
> >> code + guidelines/best practices to develop properly and so
> >> improve/increase productivity. This could be done with an archetype
> >
> > Sounds like an excellent idea.
> >
> >>
> >> (2) Switch the existing architectural model to use frameworks like
> >> Apache Wicket or Vaadin where the content is clearly separated from
> >> the server side code. Apache Wicket and Vaadin librairies are already
> >> osgified so their integration in project like karaf, sling or felix
> >> will be done seamless even if we have the overhead to deploy them. But
> >> this is also the same for bundles like PAX-Web, ...
> >
> > Sounds like not soo go an idea. There is a reason why we don't use any
> > of these frameworks: We wanted (and still want) to minimize
> > dependencies. Adding such a nice GUI framework to the game makes it more
> > complicated (remember the simple Servlet service mentioned above ?) and
> > heavy weight.
>
> >>> Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact.
I know very well about the functionality provided by those platforms.
But all these platforms come with additional dependencies. And this is
where I start placing question marks.
Also be reminded that Web Console is currently being used in embedded
platforms which don't have place to spare for the developers delight.
>
> >
> > However, this is not to say, that we should not explore ways on how
> > mechanism like JSP (or generic server side scripting) etc. can be used.
> >
> >>
> >> No matter which scenario we will decide to adopt, we could also create
> >> a project to develop all together the OSGI WebConsole used by our
> >> projects and promote it as a new Apache project --> Name suggested
> >> Apache Orion. The scope of this project could be extended to include
> >> additional management, registration of datasources, ....
> >
> > What would be the advantage of developing the Web Console in its own
> > TLP ? Is there something missing when living in the Felix project ?
>
> >>> If we add new features/functionalities (like also mentioned by Jean Baptiste D' Onofre), the debate about the location
> of this project is not insignifiant and becomes relevant like also
> that this project becomes a TLP. I do not at all defend a point of
> view to move this Felix sub-project but open the debate
Will bring this to a different thread.
Regards
Felix
>
> >
> > Regards
> > Felix
> >
> >>
> >> What do you think my propositions ?
> >>
> >> Regards,
> >>
> >> Charles Moulliard
> >> Apache Committer
> >>
> >> Blog : http://cmoulliard.blogspot.com
> >> Twitter : http://twitter.com/cmoulliard
> >> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> >> Skype: cmoulliard
> >
> >
> >
Re: [suggestion] - OSGI WebConsole
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
First: This is the last cross posted message from me. Future
communication should and will take place on the Felix list.
Please, come to that list and discuss with us here !
Am Donnerstag, den 03.03.2011, 07:40 +0000 schrieb Charles Moulliard:
> On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
> > Hi,
> >
> > As the original developer of the Web Console I am flattered by this
> > activity ;-)
> >
> > Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
> >> Hi,
> >>
> >> As three users of Apache Felix WebConsole project, I contact you to
> >> have your opinion regarding to frameworks (JSon, javascript, ...)
> >> usage made with Apache Felix WebConsole. The project has been made
> >> light to avoid dependencies with external librairies but the way that
> >> it is used today lack of structure, complicate the
> >
> > Why lack of structure ?
>
> >>> Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble.
Well, this is just an implementation detail of the plugins coming with
the Web Console proper. Nowhere is it prescribed that you have to do it
this way.
I think Guillaume has clearly described the issues around this.
>
> >
> >> development of screens and decrease development productivity, html
> >> code is mixed in javascript, json variables are set everywhere in the
> >> code and use in several of javascript functions, no template is used
> >> to render html pages, locale is not used by all of us to translate
> >> text, ....
> >
> > That's all not required. The simplest plugin is a Servlet service with
> > two service properties. Nothing fancy, really ;-)
> >
> >>
> >> The consequence of that is that some developers are very frustrated
> >> and would like to make some suggestions about Webconsole. Within Karaf
> >> community we already started this discussion and now we would like to
> >> share with you some ideas about the future roadmap of Felix
> >> WebConsole.
> >
> > I'm sorry you are "very frustrated" .. at the same time I do not
> > understand why you don't come to the Felix dev or user list to ask
> > questions ? This is a bit frustrating to me.
> >
>
> >>> The word "frustrated" was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation.
The Web Console lives in the Apache Felix project. So please, come to
use and talk to us. Start the discussion here and with us. We will
listen to you.
>
> >>
> >> Here are the different scenario possible :
> >>
> >> (1) Improve the existing usage of the frameworks JSon, OSGI and
> >> javascript by defining/providing a "template" project containing dummy
> >> code + guidelines/best practices to develop properly and so
> >> improve/increase productivity. This could be done with an archetype
> >
> > Sounds like an excellent idea.
> >
> >>
> >> (2) Switch the existing architectural model to use frameworks like
> >> Apache Wicket or Vaadin where the content is clearly separated from
> >> the server side code. Apache Wicket and Vaadin librairies are already
> >> osgified so their integration in project like karaf, sling or felix
> >> will be done seamless even if we have the overhead to deploy them. But
> >> this is also the same for bundles like PAX-Web, ...
> >
> > Sounds like not soo go an idea. There is a reason why we don't use any
> > of these frameworks: We wanted (and still want) to minimize
> > dependencies. Adding such a nice GUI framework to the game makes it more
> > complicated (remember the simple Servlet service mentioned above ?) and
> > heavy weight.
>
> >>> Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact.
I know very well about the functionality provided by those platforms.
But all these platforms come with additional dependencies. And this is
where I start placing question marks.
Also be reminded that Web Console is currently being used in embedded
platforms which don't have place to spare for the developers delight.
>
> >
> > However, this is not to say, that we should not explore ways on how
> > mechanism like JSP (or generic server side scripting) etc. can be used.
> >
> >>
> >> No matter which scenario we will decide to adopt, we could also create
> >> a project to develop all together the OSGI WebConsole used by our
> >> projects and promote it as a new Apache project --> Name suggested
> >> Apache Orion. The scope of this project could be extended to include
> >> additional management, registration of datasources, ....
> >
> > What would be the advantage of developing the Web Console in its own
> > TLP ? Is there something missing when living in the Felix project ?
>
> >>> If we add new features/functionalities (like also mentioned by Jean Baptiste D' Onofre), the debate about the location
> of this project is not insignifiant and becomes relevant like also
> that this project becomes a TLP. I do not at all defend a point of
> view to move this Felix sub-project but open the debate
Will bring this to a different thread.
Regards
Felix
>
> >
> > Regards
> > Felix
> >
> >>
> >> What do you think my propositions ?
> >>
> >> Regards,
> >>
> >> Charles Moulliard
> >> Apache Committer
> >>
> >> Blog : http://cmoulliard.blogspot.com
> >> Twitter : http://twitter.com/cmoulliard
> >> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> >> Skype: cmoulliard
> >
> >
> >
Re: [suggestion] - OSGI WebConsole
Posted by Charles Moulliard <cm...@gmail.com>.
On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> As the original developer of the Web Console I am flattered by this
> activity ;-)
>
> Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
>> Hi,
>>
>> As three users of Apache Felix WebConsole project, I contact you to
>> have your opinion regarding to frameworks (JSon, javascript, ...)
>> usage made with Apache Felix WebConsole. The project has been made
>> light to avoid dependencies with external librairies but the way that
>> it is used today lack of structure, complicate the
>
> Why lack of structure ?
>>> Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble.
>
>> development of screens and decrease development productivity, html
>> code is mixed in javascript, json variables are set everywhere in the
>> code and use in several of javascript functions, no template is used
>> to render html pages, locale is not used by all of us to translate
>> text, ....
>
> That's all not required. The simplest plugin is a Servlet service with
> two service properties. Nothing fancy, really ;-)
>
>>
>> The consequence of that is that some developers are very frustrated
>> and would like to make some suggestions about Webconsole. Within Karaf
>> community we already started this discussion and now we would like to
>> share with you some ideas about the future roadmap of Felix
>> WebConsole.
>
> I'm sorry you are "very frustrated" .. at the same time I do not
> understand why you don't come to the Felix dev or user list to ask
> questions ? This is a bit frustrating to me.
>
>>> The word "frustrated" was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation.
>>
>> Here are the different scenario possible :
>>
>> (1) Improve the existing usage of the frameworks JSon, OSGI and
>> javascript by defining/providing a "template" project containing dummy
>> code + guidelines/best practices to develop properly and so
>> improve/increase productivity. This could be done with an archetype
>
> Sounds like an excellent idea.
>
>>
>> (2) Switch the existing architectural model to use frameworks like
>> Apache Wicket or Vaadin where the content is clearly separated from
>> the server side code. Apache Wicket and Vaadin librairies are already
>> osgified so their integration in project like karaf, sling or felix
>> will be done seamless even if we have the overhead to deploy them. But
>> this is also the same for bundles like PAX-Web, ...
>
> Sounds like not soo go an idea. There is a reason why we don't use any
> of these frameworks: We wanted (and still want) to minimize
> dependencies. Adding such a nice GUI framework to the game makes it more
> complicated (remember the simple Servlet service mentioned above ?) and
> heavy weight.
>>> Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact.
>
> However, this is not to say, that we should not explore ways on how
> mechanism like JSP (or generic server side scripting) etc. can be used.
>
>>
>> No matter which scenario we will decide to adopt, we could also create
>> a project to develop all together the OSGI WebConsole used by our
>> projects and promote it as a new Apache project --> Name suggested
>> Apache Orion. The scope of this project could be extended to include
>> additional management, registration of datasources, ....
>
> What would be the advantage of developing the Web Console in its own
> TLP ? Is there something missing when living in the Felix project ?
>>> If we add new features/functionalities (like also mentioned by Jean Baptiste D' Onofre), the debate about the location
of this project is not insignifiant and becomes relevant like also
that this project becomes a TLP. I do not at all defend a point of
view to move this Felix sub-project but open the debate
>
> Regards
> Felix
>
>>
>> What do you think my propositions ?
>>
>> Regards,
>>
>> Charles Moulliard
>> Apache Committer
>>
>> Blog : http://cmoulliard.blogspot.com
>> Twitter : http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>> Skype: cmoulliard
>
>
>
Re: [suggestion] - OSGI WebConsole
Posted by Charles Moulliard <cm...@gmail.com>.
On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> As the original developer of the Web Console I am flattered by this
> activity ;-)
>
> Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
>> Hi,
>>
>> As three users of Apache Felix WebConsole project, I contact you to
>> have your opinion regarding to frameworks (JSon, javascript, ...)
>> usage made with Apache Felix WebConsole. The project has been made
>> light to avoid dependencies with external librairies but the way that
>> it is used today lack of structure, complicate the
>
> Why lack of structure ?
>>> Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble.
>
>> development of screens and decrease development productivity, html
>> code is mixed in javascript, json variables are set everywhere in the
>> code and use in several of javascript functions, no template is used
>> to render html pages, locale is not used by all of us to translate
>> text, ....
>
> That's all not required. The simplest plugin is a Servlet service with
> two service properties. Nothing fancy, really ;-)
>
>>
>> The consequence of that is that some developers are very frustrated
>> and would like to make some suggestions about Webconsole. Within Karaf
>> community we already started this discussion and now we would like to
>> share with you some ideas about the future roadmap of Felix
>> WebConsole.
>
> I'm sorry you are "very frustrated" .. at the same time I do not
> understand why you don't come to the Felix dev or user list to ask
> questions ? This is a bit frustrating to me.
>
>>> The word "frustrated" was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation.
>>
>> Here are the different scenario possible :
>>
>> (1) Improve the existing usage of the frameworks JSon, OSGI and
>> javascript by defining/providing a "template" project containing dummy
>> code + guidelines/best practices to develop properly and so
>> improve/increase productivity. This could be done with an archetype
>
> Sounds like an excellent idea.
>
>>
>> (2) Switch the existing architectural model to use frameworks like
>> Apache Wicket or Vaadin where the content is clearly separated from
>> the server side code. Apache Wicket and Vaadin librairies are already
>> osgified so their integration in project like karaf, sling or felix
>> will be done seamless even if we have the overhead to deploy them. But
>> this is also the same for bundles like PAX-Web, ...
>
> Sounds like not soo go an idea. There is a reason why we don't use any
> of these frameworks: We wanted (and still want) to minimize
> dependencies. Adding such a nice GUI framework to the game makes it more
> complicated (remember the simple Servlet service mentioned above ?) and
> heavy weight.
>>> Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact.
>
> However, this is not to say, that we should not explore ways on how
> mechanism like JSP (or generic server side scripting) etc. can be used.
>
>>
>> No matter which scenario we will decide to adopt, we could also create
>> a project to develop all together the OSGI WebConsole used by our
>> projects and promote it as a new Apache project --> Name suggested
>> Apache Orion. The scope of this project could be extended to include
>> additional management, registration of datasources, ....
>
> What would be the advantage of developing the Web Console in its own
> TLP ? Is there something missing when living in the Felix project ?
>>> If we add new features/functionalities (like also mentioned by Jean Baptiste D' Onofre), the debate about the location
of this project is not insignifiant and becomes relevant like also
that this project becomes a TLP. I do not at all defend a point of
view to move this Felix sub-project but open the debate
>
> Regards
> Felix
>
>>
>> What do you think my propositions ?
>>
>> Regards,
>>
>> Charles Moulliard
>> Apache Committer
>>
>> Blog : http://cmoulliard.blogspot.com
>> Twitter : http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>> Skype: cmoulliard
>
>
>
Re: [suggestion] - OSGI WebConsole
Posted by Charles Moulliard <cm...@gmail.com>.
On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> As the original developer of the Web Console I am flattered by this
> activity ;-)
>
> Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
>> Hi,
>>
>> As three users of Apache Felix WebConsole project, I contact you to
>> have your opinion regarding to frameworks (JSon, javascript, ...)
>> usage made with Apache Felix WebConsole. The project has been made
>> light to avoid dependencies with external librairies but the way that
>> it is used today lack of structure, complicate the
>
> Why lack of structure ?
>>> Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble.
>
>> development of screens and decrease development productivity, html
>> code is mixed in javascript, json variables are set everywhere in the
>> code and use in several of javascript functions, no template is used
>> to render html pages, locale is not used by all of us to translate
>> text, ....
>
> That's all not required. The simplest plugin is a Servlet service with
> two service properties. Nothing fancy, really ;-)
>
>>
>> The consequence of that is that some developers are very frustrated
>> and would like to make some suggestions about Webconsole. Within Karaf
>> community we already started this discussion and now we would like to
>> share with you some ideas about the future roadmap of Felix
>> WebConsole.
>
> I'm sorry you are "very frustrated" .. at the same time I do not
> understand why you don't come to the Felix dev or user list to ask
> questions ? This is a bit frustrating to me.
>
>>> The word "frustrated" was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation.
>>
>> Here are the different scenario possible :
>>
>> (1) Improve the existing usage of the frameworks JSon, OSGI and
>> javascript by defining/providing a "template" project containing dummy
>> code + guidelines/best practices to develop properly and so
>> improve/increase productivity. This could be done with an archetype
>
> Sounds like an excellent idea.
>
>>
>> (2) Switch the existing architectural model to use frameworks like
>> Apache Wicket or Vaadin where the content is clearly separated from
>> the server side code. Apache Wicket and Vaadin librairies are already
>> osgified so their integration in project like karaf, sling or felix
>> will be done seamless even if we have the overhead to deploy them. But
>> this is also the same for bundles like PAX-Web, ...
>
> Sounds like not soo go an idea. There is a reason why we don't use any
> of these frameworks: We wanted (and still want) to minimize
> dependencies. Adding such a nice GUI framework to the game makes it more
> complicated (remember the simple Servlet service mentioned above ?) and
> heavy weight.
>>> Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact.
>
> However, this is not to say, that we should not explore ways on how
> mechanism like JSP (or generic server side scripting) etc. can be used.
>
>>
>> No matter which scenario we will decide to adopt, we could also create
>> a project to develop all together the OSGI WebConsole used by our
>> projects and promote it as a new Apache project --> Name suggested
>> Apache Orion. The scope of this project could be extended to include
>> additional management, registration of datasources, ....
>
> What would be the advantage of developing the Web Console in its own
> TLP ? Is there something missing when living in the Felix project ?
>>> If we add new features/functionalities (like also mentioned by Jean Baptiste D' Onofre), the debate about the location
of this project is not insignifiant and becomes relevant like also
that this project becomes a TLP. I do not at all defend a point of
view to move this Felix sub-project but open the debate
>
> Regards
> Felix
>
>>
>> What do you think my propositions ?
>>
>> Regards,
>>
>> Charles Moulliard
>> Apache Committer
>>
>> Blog : http://cmoulliard.blogspot.com
>> Twitter : http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>> Skype: cmoulliard
>
>
>
Re: [suggestion] - OSGI WebConsole
Posted by Charles Moulliard <cm...@gmail.com>.
On Wed, Mar 2, 2011 at 11:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> As the original developer of the Web Console I am flattered by this
> activity ;-)
>
> Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
>> Hi,
>>
>> As three users of Apache Felix WebConsole project, I contact you to
>> have your opinion regarding to frameworks (JSon, javascript, ...)
>> usage made with Apache Felix WebConsole. The project has been made
>> light to avoid dependencies with external librairies but the way that
>> it is used today lack of structure, complicate the
>
> Why lack of structure ?
>>> Because by example we fill data (for a table) in different java methods and render it using also different javascripts function. This is really paintful to rebuild the global picture regarding what we see in the html (code source) of the browser with where in the code, the different parts are prepare and assemble.
>
>> development of screens and decrease development productivity, html
>> code is mixed in javascript, json variables are set everywhere in the
>> code and use in several of javascript functions, no template is used
>> to render html pages, locale is not used by all of us to translate
>> text, ....
>
> That's all not required. The simplest plugin is a Servlet service with
> two service properties. Nothing fancy, really ;-)
>
>>
>> The consequence of that is that some developers are very frustrated
>> and would like to make some suggestions about Webconsole. Within Karaf
>> community we already started this discussion and now we would like to
>> share with you some ideas about the future roadmap of Felix
>> WebConsole.
>
> I'm sorry you are "very frustrated" .. at the same time I do not
> understand why you don't come to the Felix dev or user list to ask
> questions ? This is a bit frustrating to me.
>
>>> The word "frustrated" was certainly too excessive and in fact, the discussion that we have started here is a good starting point to collect/gather opinions and improve the existing situation.
>>
>> Here are the different scenario possible :
>>
>> (1) Improve the existing usage of the frameworks JSon, OSGI and
>> javascript by defining/providing a "template" project containing dummy
>> code + guidelines/best practices to develop properly and so
>> improve/increase productivity. This could be done with an archetype
>
> Sounds like an excellent idea.
>
>>
>> (2) Switch the existing architectural model to use frameworks like
>> Apache Wicket or Vaadin where the content is clearly separated from
>> the server side code. Apache Wicket and Vaadin librairies are already
>> osgified so their integration in project like karaf, sling or felix
>> will be done seamless even if we have the overhead to deploy them. But
>> this is also the same for bundles like PAX-Web, ...
>
> Sounds like not soo go an idea. There is a reason why we don't use any
> of these frameworks: We wanted (and still want) to minimize
> dependencies. Adding such a nice GUI framework to the game makes it more
> complicated (remember the simple Servlet service mentioned above ?) and
> heavy weight.
>>> Before to take a definitive decision, I propose that we investigate the possibilities offered by Apache Wicket, PAX-Wicket or even Vaadin using a few rendering components and analyse if the approach suggested is worse or can provide enhancements for the existing platform without too much impact.
>
> However, this is not to say, that we should not explore ways on how
> mechanism like JSP (or generic server side scripting) etc. can be used.
>
>>
>> No matter which scenario we will decide to adopt, we could also create
>> a project to develop all together the OSGI WebConsole used by our
>> projects and promote it as a new Apache project --> Name suggested
>> Apache Orion. The scope of this project could be extended to include
>> additional management, registration of datasources, ....
>
> What would be the advantage of developing the Web Console in its own
> TLP ? Is there something missing when living in the Felix project ?
>>> If we add new features/functionalities (like also mentioned by Jean Baptiste D' Onofre), the debate about the location
of this project is not insignifiant and becomes relevant like also
that this project becomes a TLP. I do not at all defend a point of
view to move this Felix sub-project but open the debate
>
> Regards
> Felix
>
>>
>> What do you think my propositions ?
>>
>> Regards,
>>
>> Charles Moulliard
>> Apache Committer
>>
>> Blog : http://cmoulliard.blogspot.com
>> Twitter : http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>> Skype: cmoulliard
>
>
>
Re: [suggestion] - OSGI WebConsole
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
As the original developer of the Web Console I am flattered by this
activity ;-)
Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
> Hi,
>
> As three users of Apache Felix WebConsole project, I contact you to
> have your opinion regarding to frameworks (JSon, javascript, ...)
> usage made with Apache Felix WebConsole. The project has been made
> light to avoid dependencies with external librairies but the way that
> it is used today lack of structure, complicate the
Why lack of structure ?
> development of screens and decrease development productivity, html
> code is mixed in javascript, json variables are set everywhere in the
> code and use in several of javascript functions, no template is used
> to render html pages, locale is not used by all of us to translate
> text, ....
That's all not required. The simplest plugin is a Servlet service with
two service properties. Nothing fancy, really ;-)
>
> The consequence of that is that some developers are very frustrated
> and would like to make some suggestions about Webconsole. Within Karaf
> community we already started this discussion and now we would like to
> share with you some ideas about the future roadmap of Felix
> WebConsole.
I'm sorry you are "very frustrated" .. at the same time I do not
understand why you don't come to the Felix dev or user list to ask
questions ? This is a bit frustrating to me.
>
> Here are the different scenario possible :
>
> (1) Improve the existing usage of the frameworks JSon, OSGI and
> javascript by defining/providing a "template" project containing dummy
> code + guidelines/best practices to develop properly and so
> improve/increase productivity. This could be done with an archetype
Sounds like an excellent idea.
>
> (2) Switch the existing architectural model to use frameworks like
> Apache Wicket or Vaadin where the content is clearly separated from
> the server side code. Apache Wicket and Vaadin librairies are already
> osgified so their integration in project like karaf, sling or felix
> will be done seamless even if we have the overhead to deploy them. But
> this is also the same for bundles like PAX-Web, ...
Sounds like not soo go an idea. There is a reason why we don't use any
of these frameworks: We wanted (and still want) to minimize
dependencies. Adding such a nice GUI framework to the game makes it more
complicated (remember the simple Servlet service mentioned above ?) and
heavy weight.
However, this is not to say, that we should not explore ways on how
mechanism like JSP (or generic server side scripting) etc. can be used.
>
> No matter which scenario we will decide to adopt, we could also create
> a project to develop all together the OSGI WebConsole used by our
> projects and promote it as a new Apache project --> Name suggested
> Apache Orion. The scope of this project could be extended to include
> additional management, registration of datasources, ....
What would be the advantage of developing the Web Console in its own
TLP ? Is there something missing when living in the Felix project ?
Regards
Felix
>
> What do you think my propositions ?
>
> Regards,
>
> Charles Moulliard
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
Re: [suggestion] - OSGI WebConsole
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Charles,
Thanks for launching the idea that we discussed on IRC.
As I said, my point of view is that we need a kind of median console
projects for Apache middleware projects.
For instance, a lot of stuff is share in all web console of these
projects (user authentication, authentication backend, JMX client, etc,
etc).
By projects, I've identified: Karaf, Felix, ServiceMix, CXF, Camel,
Geronimo, (maybe ACE), ActiveMQ, Sling, Tomcat, DS, James, certainly
others :).
If we can provide a plug and play and branding WebConsole, all these
projects can use it.
My vision is that we need a generic console (monitoring, management
oriented) that could be extended by each project.
Depending of the different communities feedback, it could have sense to
submit to the incubator mailing list. Maybe we can think about an Apache
Operational Network Console (Apache ONC) with plugins provided by the
Apache projects.
Regards
JB
On 03/02/2011 06:37 PM, Charles Moulliard wrote:
> Hi,
>
> As three users of Apache Felix WebConsole project, I contact you to
> have your opinion regarding to frameworks (JSon, javascript, ...)
> usage made with Apache Felix WebConsole. The project has been made
> light to avoid dependencies with external librairies but the way that
> it is used today lack of structure, complicate the
> development of screens and decrease development productivity, html
> code is mixed in javascript, json variables are set everywhere in the
> code and use in several of javascript functions, no template is used
> to render html pages, locale is not used by all of us to translate
> text, ....
>
> The consequence of that is that some developers are very frustrated
> and would like to make some suggestions about Webconsole. Within Karaf
> community we already started this discussion and now we would like to
> share with you some ideas about the future roadmap of Felix
> WebConsole.
>
> Here are the different scenario possible :
>
> (1) Improve the existing usage of the frameworks JSon, OSGI and
> javascript by defining/providing a "template" project containing dummy
> code + guidelines/best practices to develop properly and so
> improve/increase productivity. This could be done with an archetype
>
> (2) Switch the existing architectural model to use frameworks like
> Apache Wicket or Vaadin where the content is clearly separated from
> the server side code. Apache Wicket and Vaadin librairies are already
> osgified so their integration in project like karaf, sling or felix
> will be done seamless even if we have the overhead to deploy them. But
> this is also the same for bundles like PAX-Web, ...
>
> No matter which scenario we will decide to adopt, we could also create
> a project to develop all together the OSGI WebConsole used by our
> projects and promote it as a new Apache project --> Name suggested
> Apache Orion. The scope of this project could be extended to include
> additional management, registration of datasources, ....
>
> What do you think my propositions ?
>
> Regards,
>
> Charles Moulliard
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
Re: [suggestion] - OSGI WebConsole
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Charles,
Thanks for launching the idea that we discussed on IRC.
As I said, my point of view is that we need a kind of median console
projects for Apache middleware projects.
For instance, a lot of stuff is share in all web console of these
projects (user authentication, authentication backend, JMX client, etc,
etc).
By projects, I've identified: Karaf, Felix, ServiceMix, CXF, Camel,
Geronimo, (maybe ACE), ActiveMQ, Sling, Tomcat, DS, James, certainly
others :).
If we can provide a plug and play and branding WebConsole, all these
projects can use it.
My vision is that we need a generic console (monitoring, management
oriented) that could be extended by each project.
Depending of the different communities feedback, it could have sense to
submit to the incubator mailing list. Maybe we can think about an Apache
Operational Network Console (Apache ONC) with plugins provided by the
Apache projects.
Regards
JB
On 03/02/2011 06:37 PM, Charles Moulliard wrote:
> Hi,
>
> As three users of Apache Felix WebConsole project, I contact you to
> have your opinion regarding to frameworks (JSon, javascript, ...)
> usage made with Apache Felix WebConsole. The project has been made
> light to avoid dependencies with external librairies but the way that
> it is used today lack of structure, complicate the
> development of screens and decrease development productivity, html
> code is mixed in javascript, json variables are set everywhere in the
> code and use in several of javascript functions, no template is used
> to render html pages, locale is not used by all of us to translate
> text, ....
>
> The consequence of that is that some developers are very frustrated
> and would like to make some suggestions about Webconsole. Within Karaf
> community we already started this discussion and now we would like to
> share with you some ideas about the future roadmap of Felix
> WebConsole.
>
> Here are the different scenario possible :
>
> (1) Improve the existing usage of the frameworks JSon, OSGI and
> javascript by defining/providing a "template" project containing dummy
> code + guidelines/best practices to develop properly and so
> improve/increase productivity. This could be done with an archetype
>
> (2) Switch the existing architectural model to use frameworks like
> Apache Wicket or Vaadin where the content is clearly separated from
> the server side code. Apache Wicket and Vaadin librairies are already
> osgified so their integration in project like karaf, sling or felix
> will be done seamless even if we have the overhead to deploy them. But
> this is also the same for bundles like PAX-Web, ...
>
> No matter which scenario we will decide to adopt, we could also create
> a project to develop all together the OSGI WebConsole used by our
> projects and promote it as a new Apache project --> Name suggested
> Apache Orion. The scope of this project could be extended to include
> additional management, registration of datasources, ....
>
> What do you think my propositions ?
>
> Regards,
>
> Charles Moulliard
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
Re: [suggestion] - OSGI WebConsole
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
As the original developer of the Web Console I am flattered by this
activity ;-)
Am Mittwoch, den 02.03.2011, 17:37 +0000 schrieb Charles Moulliard:
> Hi,
>
> As three users of Apache Felix WebConsole project, I contact you to
> have your opinion regarding to frameworks (JSon, javascript, ...)
> usage made with Apache Felix WebConsole. The project has been made
> light to avoid dependencies with external librairies but the way that
> it is used today lack of structure, complicate the
Why lack of structure ?
> development of screens and decrease development productivity, html
> code is mixed in javascript, json variables are set everywhere in the
> code and use in several of javascript functions, no template is used
> to render html pages, locale is not used by all of us to translate
> text, ....
That's all not required. The simplest plugin is a Servlet service with
two service properties. Nothing fancy, really ;-)
>
> The consequence of that is that some developers are very frustrated
> and would like to make some suggestions about Webconsole. Within Karaf
> community we already started this discussion and now we would like to
> share with you some ideas about the future roadmap of Felix
> WebConsole.
I'm sorry you are "very frustrated" .. at the same time I do not
understand why you don't come to the Felix dev or user list to ask
questions ? This is a bit frustrating to me.
>
> Here are the different scenario possible :
>
> (1) Improve the existing usage of the frameworks JSon, OSGI and
> javascript by defining/providing a "template" project containing dummy
> code + guidelines/best practices to develop properly and so
> improve/increase productivity. This could be done with an archetype
Sounds like an excellent idea.
>
> (2) Switch the existing architectural model to use frameworks like
> Apache Wicket or Vaadin where the content is clearly separated from
> the server side code. Apache Wicket and Vaadin librairies are already
> osgified so their integration in project like karaf, sling or felix
> will be done seamless even if we have the overhead to deploy them. But
> this is also the same for bundles like PAX-Web, ...
Sounds like not soo go an idea. There is a reason why we don't use any
of these frameworks: We wanted (and still want) to minimize
dependencies. Adding such a nice GUI framework to the game makes it more
complicated (remember the simple Servlet service mentioned above ?) and
heavy weight.
However, this is not to say, that we should not explore ways on how
mechanism like JSP (or generic server side scripting) etc. can be used.
>
> No matter which scenario we will decide to adopt, we could also create
> a project to develop all together the OSGI WebConsole used by our
> projects and promote it as a new Apache project --> Name suggested
> Apache Orion. The scope of this project could be extended to include
> additional management, registration of datasources, ....
What would be the advantage of developing the Web Console in its own
TLP ? Is there something missing when living in the Felix project ?
Regards
Felix
>
> What do you think my propositions ?
>
> Regards,
>
> Charles Moulliard
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
Re: [suggestion] - OSGI WebConsole
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 02.03.11 18:37, "Charles Moulliard" <cm...@gmail.com> wrote:
>(2) Switch the existing architectural model to use frameworks like
>Apache Wicket or Vaadin where the content is clearly separated from
>the server side code. Apache Wicket and Vaadin librairies are already
>osgified so their integration in project like karaf, sling or felix
>will be done seamless even if we have the overhead to deploy them. But
>this is also the same for bundles like PAX-Web, ...
>From a Sling perspective, which is a web application framework, using
Sling to render the web console pages would be cool :-)
However, I think there is a good reason that the web console
implementation(s) are as simple as possible: if they rely on too much
external bundles and services, chances are higher that things can break.
The console is typically an important management interface that should
always be running, even if the system it manages is mostly down (because
bundles are updating, not resolved etc.). So if it is for example used to
manage Sling, but also run by Sling, you get cyclic dependency hell and if
Sling is down, the console has a problem, too.
One could also embed those libraries in the web console bundle(s), but
then you have to do it every single time, as most screens are provided as
plugins, residing in their own bundles. Thus bundle sizes explode and
version management can be difficult.
So I think one should be careful in adding complex dependencies.
The current plain servlets are very robust in this regard. But I agree
that not having a templating mechanism such as JSP makes it hard to work
on it.
Just my 2 cents,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: [suggestion] - OSGI WebConsole
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 02.03.11 18:37, "Charles Moulliard" <cm...@gmail.com> wrote:
>(2) Switch the existing architectural model to use frameworks like
>Apache Wicket or Vaadin where the content is clearly separated from
>the server side code. Apache Wicket and Vaadin librairies are already
>osgified so their integration in project like karaf, sling or felix
>will be done seamless even if we have the overhead to deploy them. But
>this is also the same for bundles like PAX-Web, ...
>From a Sling perspective, which is a web application framework, using
Sling to render the web console pages would be cool :-)
However, I think there is a good reason that the web console
implementation(s) are as simple as possible: if they rely on too much
external bundles and services, chances are higher that things can break.
The console is typically an important management interface that should
always be running, even if the system it manages is mostly down (because
bundles are updating, not resolved etc.). So if it is for example used to
manage Sling, but also run by Sling, you get cyclic dependency hell and if
Sling is down, the console has a problem, too.
One could also embed those libraries in the web console bundle(s), but
then you have to do it every single time, as most screens are provided as
plugins, residing in their own bundles. Thus bundle sizes explode and
version management can be difficult.
So I think one should be careful in adding complex dependencies.
The current plain servlets are very robust in this regard. But I agree
that not having a templating mechanism such as JSP makes it hard to work
on it.
Just my 2 cents,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel