Brainstorming about the Framework: General

[David E. Jones-2]

If you could change anything about the OFBiz framework (not related to a specific tier), what would it be? This could be about how OFBiz is deployed, how the tools fit together, how application components are written and organized, and so on.

All comments are welcome. If there is another tool you'd like to see used, please describe what you like about it (like "I've found the aspect oriented inversion of control approach nice because I can plugin all sorts of tools and the full life cycle of the tools are managed for me") instead of just mentioning the tool (like "let's use Spring!").

Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.

BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or UI tiers) please use the other threads on those.

-David

[Chris Snow-3]

1) replace the ofbiz component loader (i.e. ofbiz configuration) with
technology like OSGi or DI (e.g. spring)

BENEFITS:
+ reduce the amount of time a new ofbiz developer working on the ofbiz
framework will have to spend understanding the component loader
+ help manage the dependencies and interfaces between each component
making them easier to test and operate independently of the whole
framework (e.g. allowing use of the entity engine with grails, or entity
engine + service engine with grails)
+ make ofbiz more desirable to framework developers

2) move the components (e.g. entity engine, service engine) to their own
svn repositories, and move the component config files to a separate
location away from the code.

BENEFITS:
+ make it easier to manage patching, for example bug fixes to the entity
engine would just be packaged into ofbiz-entity.jar and replace the
existing jar in an ofbiz installation

3) make running in tomcat as a war an OOTB option.

BENEFITS:
+ makes ofbiz more attractive to enterprises wanting ofbiz to fit in to
their existing JEE architecture.


... probably more to follow ...

> If you could change anything about the OFBiz framework (not related to a specific tier), what would it be? This could be about how OFBiz is deployed, how the tools fit together, how application components are written and organized, and so on.
>
> All comments are welcome. If there is another tool you'd like to see used, please describe what you like about it (like "I've found the aspect oriented inversion of control approach nice because I can plugin all sorts of tools and the full life cycle of the tools are managed for me") instead of just mentioning the tool (like "let's use Spring!").
>
> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>
> BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or UI tiers) please use the other threads on those.
>
> -David
>
>  

[Ruth Hoffman-2]

Hi David:
Could we add something to help manage role based security? Roles, user's
resources etc. all in one place? I don't mean within the Party
component. Roles have just as much to do with resources as they do with
users.
Regards,
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
[hidden email]


David E Jones wrote:

> If you could change anything about the OFBiz framework (not related to a specific tier), what would it be? This could be about how OFBiz is deployed, how the tools fit together, how application components are written and organized, and so on.
>
> All comments are welcome. If there is another tool you'd like to see used, please describe what you like about it (like "I've found the aspect oriented inversion of control approach nice because I can plugin all sorts of tools and the full life cycle of the tools are managed for me") instead of just mentioning the tool (like "let's use Spring!").
>
> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>
> BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or UI tiers) please use the other threads on those.
>
> -David
>
>
>  

[David E. Jones-2]

I really did just mean for this to be a brainstorming thread... so could we add? Yeah, I guess we could add/change/etc anything in theory. Whether these things happen or not is another question and issue altogether (or more importantly how they happen, I do believe there's a chance for anything).

Anyway, when say "role based security" what does that mean to you? Could you describe some scenarios you'd like to see supported and maybe what the configuration might look like?

-David


On Mar 11, 2010, at 8:26 AM, Ruth Hoffman wrote:

> Hi David:
> Could we add something to help manage role based security? Roles, user's resources etc. all in one place? I don't mean within the Party component. Roles have just as much to do with resources as they do with users.
> Regards,
> Ruth
> ----------------------------------------------------
> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
> [hidden email]
>
>
> David E Jones wrote:
>> If you could change anything about the OFBiz framework (not related to a specific tier), what would it be? This could be about how OFBiz is deployed, how the tools fit together, how application components are written and organized, and so on.
>>
>> All comments are welcome. If there is another tool you'd like to see used, please describe what you like about it (like "I've found the aspect oriented inversion of control approach nice because I can plugin all sorts of tools and the full life cycle of the tools are managed for me") instead of just mentioning the tool (like "let's use Spring!").
>>
>> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>>
>> BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or UI tiers) please use the other threads on those.
>>
>> -David
>>
>>
>>  

[Ruth Hoffman-2]

Hi David:
re: "role based security". Let me get back to you on that. It will take
me some time to give details on this.

Thanks for asking.
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
[hidden email]


David E Jones wrote:

> I really did just mean for this to be a brainstorming thread... so could we add? Yeah, I guess we could add/change/etc anything in theory. Whether these things happen or not is another question and issue altogether (or more importantly how they happen, I do believe there's a chance for anything).
>
> Anyway, when say "role based security" what does that mean to you? Could you describe some scenarios you'd like to see supported and maybe what the configuration might look like?
>
> -David
>
>
> On Mar 11, 2010, at 8:26 AM, Ruth Hoffman wrote:
>
>  
>> Hi David:
>> Could we add something to help manage role based security? Roles, user's resources etc. all in one place? I don't mean within the Party component. Roles have just as much to do with resources as they do with users.
>> Regards,
>> Ruth
>> ----------------------------------------------------
>> Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
>> [hidden email]
>>
>>
>> David E Jones wrote:
>>    
>>> If you could change anything about the OFBiz framework (not related to a specific tier), what would it be? This could be about how OFBiz is deployed, how the tools fit together, how application components are written and organized, and so on.
>>>
>>> All comments are welcome. If there is another tool you'd like to see used, please describe what you like about it (like "I've found the aspect oriented inversion of control approach nice because I can plugin all sorts of tools and the full life cycle of the tools are managed for me") instead of just mentioning the tool (like "let's use Spring!").
>>>
>>> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>>>
>>> BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or UI tiers) please use the other threads on those.
>>>
>>> -David
>>>
>>>
>>>  
>>>      
>
>
>  

[rajsaini]

Hi David,

One thing could be useful in the long run is moving to OSGi based
components. There are numerous benefits of OSGi and you can find a a lot
about it on the net. The kind of modularity OSGi brings is not possible
in other components modules. Dynamic bundle loading and unloading is
useful during development and run time. During development, for example
if you have changed some Java code in one of the bundle, you do not need
to restart the complete server to load the new code. Just update or
stop/start the bundle and you are ready to test. One more advantage I
see is exporting OFBiz services as web services or distributed OSGi
services. Eclipse ECF and Apache CXF provide distributed OSGi
implementation. Integration with other applications such as ServiceMix
should also be very easier as they are already run on OSGi platform.

Thanks,

Raj


I recently completed a prototype to run the OFBiz framework embedded in
the Equinox OSGi runtime and it worked fine with little changes here and
there.
David E Jones wrote:

> If you could change anything about the OFBiz framework (not related to a specific tier), what would it be? This could be about how OFBiz is deployed, how the tools fit together, how application components are written and organized, and so on.
>
> All comments are welcome. If there is another tool you'd like to see used, please describe what you like about it (like "I've found the aspect oriented inversion of control approach nice because I can plugin all sorts of tools and the full life cycle of the tools are managed for me") instead of just mentioning the tool (like "let's use Spring!").
>
> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>
> BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or UI tiers) please use the other threads on those.
>
> -David
>
>
>  

[David E. Jones-2]

I like many of the ideas about OSGi (even if it isn't quite what some people think it is).

From your point of view, how specifically do you see OSGi used in OFBiz? Are you thinking it could replace the OFBiz component functionality or just be used to deploy java code arbitrarily at run-time?

If you are thinking it could be used to replace the OFBiz component stuff, how would you handle each part of the ofbiz-component.xml file (especially the non-classpath parts)?

I've looked into it, but not enough to get past that, so any thoughts you (or anyone else) has would be interesting.

-David


On Mar 12, 2010, at 1:53 AM, Raj Saini wrote:

> Hi David,
>
> One thing could be useful in the long run is moving to OSGi based components. There are numerous benefits of OSGi and you can find a a lot about it on the net. The kind of modularity OSGi brings is not possible in other components modules. Dynamic bundle loading and unloading is useful during development and run time. During development, for example if you have changed some Java code in one of the bundle, you do not need to restart the complete server to load the new code. Just update or stop/start the bundle and you are ready to test. One more advantage I see is exporting OFBiz services as web services or distributed OSGi services. Eclipse ECF and Apache CXF provide distributed OSGi implementation. Integration with other applications such as ServiceMix should also be very easier as they are already run on OSGi platform.
>
> Thanks,
>
> Raj
>
>
> I recently completed a prototype to run the OFBiz framework embedded in the Equinox OSGi runtime and it worked fine with little changes here and there.
> David E Jones wrote:
>> If you could change anything about the OFBiz framework (not related to a specific tier), what would it be? This could be about how OFBiz is deployed, how the tools fit together, how application components are written and organized, and so on.
>>
>> All comments are welcome. If there is another tool you'd like to see used, please describe what you like about it (like "I've found the aspect oriented inversion of control approach nice because I can plugin all sorts of tools and the full life cycle of the tools are managed for me") instead of just mentioning the tool (like "let's use Spring!").
>>
>> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>>
>> BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or UI tiers) please use the other threads on those.
>>
>> -David
>>
>>
>>  
>

[Jacques Le Roux]

Hi Raj,

As I see much interest in OSDGI (not particularly me, I mean in the community) I would suggest to create an entry at
http://ofbiz.uservoice.com/
or
http://ofbiz.ideascale.com/
as you like

Thanks

Jacques


From: "Raj Saini" <[hidden email]>

> Hi David,
>
> One thing could be useful in the long run is moving to OSGi based components. There are numerous benefits of OSGi and you can find
> a a lot about it on the net. The kind of modularity OSGi brings is not possible in other components modules. Dynamic bundle
> loading and unloading is useful during development and run time. During development, for example if you have changed some Java
> code in one of the bundle, you do not need to restart the complete server to load the new code. Just update or stop/start the
> bundle and you are ready to test. One more advantage I see is exporting OFBiz services as web services or distributed OSGi
> services. Eclipse ECF and Apache CXF provide distributed OSGi implementation. Integration with other applications such as
> ServiceMix should also be very easier as they are already run on OSGi platform.
>
> Thanks,
>
> Raj
>
>
> I recently completed a prototype to run the OFBiz framework embedded in the Equinox OSGi runtime and it worked fine with little
> changes here and there.
> David E Jones wrote:
>> If you could change anything about the OFBiz framework (not related to a specific tier), what would it be? This could be about
>> how OFBiz is deployed, how the tools fit together, how application components are written and organized, and so on.
>>
>> All comments are welcome. If there is another tool you'd like to see used, please describe what you like about it (like "I've
>> found the aspect oriented inversion of control approach nice because I can plugin all sorts of tools and the full life cycle of
>> the tools are managed for me") instead of just mentioning the tool (like "let's use Spring!").
>>
>> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to
>> actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in
>> the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had
>> ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I
>> think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>>
>> BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or UI tiers) please use the other threads on those.
>>
>> -David
>>
>>
>>
>

[rajsaini]

Hi David,

I see it at both levels but in a phased manner. In the first phase, we
can use the OSGi to manage the run time and component code and leave let
OFBiz containers and load using OFBiz component model. This is the part
my prototype addresses and can help us creating binary releases.

I have not thought much about the how to replace the OFbiz component
model with the OSGi one. However, I see no reason it cant be done using
the standard MANIFEST  files of OFBiz. We would need to extend the OSGi
(creating one bundle to handle this stuff) similar to the way Spring and
Eclipse do.

Thanks,

Raj

David E Jones wrote:

> I like many of the ideas about OSGi (even if it isn't quite what some people think it is).
>
> >From your point of view, how specifically do you see OSGi used in OFBiz? Are you thinking it could replace the OFBiz component functionality or just be used to deploy java code arbitrarily at run-time?
>
> If you are thinking it could be used to replace the OFBiz component stuff, how would you handle each part of the ofbiz-component.xml file (especially the non-classpath parts)?
>
> I've looked into it, but not enough to get past that, so any thoughts you (or anyone else) has would be interesting.
>
> -David
>
>
> On Mar 12, 2010, at 1:53 AM, Raj Saini wrote:
>
>  
>> Hi David,
>>
>> One thing could be useful in the long run is moving to OSGi based components. There are numerous benefits of OSGi and you can find a a lot about it on the net. The kind of modularity OSGi brings is not possible in other components modules. Dynamic bundle loading and unloading is useful during development and run time. During development, for example if you have changed some Java code in one of the bundle, you do not need to restart the complete server to load the new code. Just update or stop/start the bundle and you are ready to test. One more advantage I see is exporting OFBiz services as web services or distributed OSGi services. Eclipse ECF and Apache CXF provide distributed OSGi implementation. Integration with other applications such as ServiceMix should also be very easier as they are already run on OSGi platform.
>>
>> Thanks,
>>
>> Raj
>>
>>
>> I recently completed a prototype to run the OFBiz framework embedded in the Equinox OSGi runtime and it worked fine with little changes here and there.
>> David E Jones wrote:
>>    
>>> If you could change anything about the OFBiz framework (not related to a specific tier), what would it be? This could be about how OFBiz is deployed, how the tools fit together, how application components are written and organized, and so on.
>>>
>>> All comments are welcome. If there is another tool you'd like to see used, please describe what you like about it (like "I've found the aspect oriented inversion of control approach nice because I can plugin all sorts of tools and the full life cycle of the tools are managed for me") instead of just mentioning the tool (like "let's use Spring!").
>>>
>>> Why am I asking? This topic comes up every once in a while, and it's true that many suggestions never get enough support to actually happen (or on further research it is decided that the idea is not tenable), but brainstorming about them to get ideas in the open is still a great thing. The history of OFBiz is full of things like this where users and more casual contributors had ideas and saw possibilities that others, even more involved contributors, totally missed or never looked at that way. What I think would be fun, and ultimately useful too, is to keep this mostly to brainstorming and not do too much comparing of ideas.
>>>
>>> BTW, if you want to brainstorm about one of the tiers (ie the Data, Logic, or UI tiers) please use the other threads on those.
>>>
>>> -David
>>>
>>>
>>>  
>>>      
>
>
>  

[rajsaini]

Done  :-)

Jacques Le Roux wrote:

> Hi Raj,
>
> As I see much interest in OSDGI (not particularly me, I mean in the
> community) I would suggest to create an entry at
> http://ofbiz.uservoice.com/
> or
> http://ofbiz.ideascale.com/
> as you like
>
> Thanks
>
> Jacques
>
>
> From: "Raj Saini" <[hidden email]>
>> Hi David,
>>
>> One thing could be useful in the long run is moving to OSGi based
>> components. There are numerous benefits of OSGi and you can find a a
>> lot about it on the net. The kind of modularity OSGi brings is not
>> possible in other components modules. Dynamic bundle loading and
>> unloading is useful during development and run time. During
>> development, for example if you have changed some Java code in one of
>> the bundle, you do not need to restart the complete server to load
>> the new code. Just update or stop/start the bundle and you are ready
>> to test. One more advantage I see is exporting OFBiz services as web
>> services or distributed OSGi services. Eclipse ECF and Apache CXF
>> provide distributed OSGi implementation. Integration with other
>> applications such as ServiceMix should also be very easier as they
>> are already run on OSGi platform.
>>
>> Thanks,
>>
>> Raj
>>
>>
>> I recently completed a prototype to run the OFBiz framework embedded
>> in the Equinox OSGi runtime and it worked fine with little changes
>> here and there.
>> David E Jones wrote:
>>> If you could change anything about the OFBiz framework (not related
>>> to a specific tier), what would it be? This could be about how OFBiz
>>> is deployed, how the tools fit together, how application components
>>> are written and organized, and so on.
>>>
>>> All comments are welcome. If there is another tool you'd like to see
>>> used, please describe what you like about it (like "I've found the
>>> aspect oriented inversion of control approach nice because I can
>>> plugin all sorts of tools and the full life cycle of the tools are
>>> managed for me") instead of just mentioning the tool (like "let's
>>> use Spring!").
>>>
>>> Why am I asking? This topic comes up every once in a while, and it's
>>> true that many suggestions never get enough support to actually
>>> happen (or on further research it is decided that the idea is not
>>> tenable), but brainstorming about them to get ideas in the open is
>>> still a great thing. The history of OFBiz is full of things like
>>> this where users and more casual contributors had ideas and saw
>>> possibilities that others, even more involved contributors, totally
>>> missed or never looked at that way. What I think would be fun, and
>>> ultimately useful too, is to keep this mostly to brainstorming and
>>> not do too much comparing of ideas.
>>>
>>> BTW, if you want to brainstorm about one of the tiers (ie the Data,
>>> Logic, or UI tiers) please use the other threads on those.
>>>
>>> -David
>>>
>>>
>>>
>>
>
>
>

[rajsaini]

Thought a bit more about it and we can use the ofbiz-componet.xml as it
is similar to the plugin.xml of Eclipse. I will work on a prototype to
evaluate it.

Thanks,

Raj

Raj Saini wrote:

> Hi David,
>
> I see it at both levels but in a phased manner. In the first phase, we
> can use the OSGi to manage the run time and component code and leave
> let OFBiz containers and load using OFBiz component model. This is the
> part my prototype addresses and can help us creating binary releases.
>
> I have not thought much about the how to replace the OFbiz component
> model with the OSGi one. However, I see no reason it cant be done
> using the standard MANIFEST  files of OFBiz. We would need to extend
> the OSGi (creating one bundle to handle this stuff) similar to the way
> Spring and Eclipse do.
>
> Thanks,
>
> Raj
>
> David E Jones wrote:
>> I like many of the ideas about OSGi (even if it isn't quite what some
>> people think it is).
>>
>> >From your point of view, how specifically do you see OSGi used in
>> OFBiz? Are you thinking it could replace the OFBiz component
>> functionality or just be used to deploy java code arbitrarily at
>> run-time?
>>
>> If you are thinking it could be used to replace the OFBiz component
>> stuff, how would you handle each part of the ofbiz-component.xml file
>> (especially the non-classpath parts)?
>>
>> I've looked into it, but not enough to get past that, so any thoughts
>> you (or anyone else) has would be interesting.
>>
>> -David
>>
>>
>> On Mar 12, 2010, at 1:53 AM, Raj Saini wrote:
>>
>>  
>>> Hi David,
>>>
>>> One thing could be useful in the long run is moving to OSGi based
>>> components. There are numerous benefits of OSGi and you can find a a
>>> lot about it on the net. The kind of modularity OSGi brings is not
>>> possible in other components modules. Dynamic bundle loading and
>>> unloading is useful during development and run time. During
>>> development, for example if you have changed some Java code in one
>>> of the bundle, you do not need to restart the complete server to
>>> load the new code. Just update or stop/start the bundle and you are
>>> ready to test. One more advantage I see is exporting OFBiz services
>>> as web services or distributed OSGi services. Eclipse ECF and Apache
>>> CXF provide distributed OSGi implementation. Integration with other
>>> applications such as ServiceMix should also be very easier as they
>>> are already run on OSGi platform.
>>>
>>> Thanks,
>>>
>>> Raj
>>>
>>>
>>> I recently completed a prototype to run the OFBiz framework embedded
>>> in the Equinox OSGi runtime and it worked fine with little changes
>>> here and there.
>>> David E Jones wrote:
>>>    
>>>> If you could change anything about the OFBiz framework (not related
>>>> to a specific tier), what would it be? This could be about how
>>>> OFBiz is deployed, how the tools fit together, how application
>>>> components are written and organized, and so on.
>>>>
>>>> All comments are welcome. If there is another tool you'd like to
>>>> see used, please describe what you like about it (like "I've found
>>>> the aspect oriented inversion of control approach nice because I
>>>> can plugin all sorts of tools and the full life cycle of the tools
>>>> are managed for me") instead of just mentioning the tool (like
>>>> "let's use Spring!").
>>>>
>>>> Why am I asking? This topic comes up every once in a while, and
>>>> it's true that many suggestions never get enough support to
>>>> actually happen (or on further research it is decided that the idea
>>>> is not tenable), but brainstorming about them to get ideas in the
>>>> open is still a great thing. The history of OFBiz is full of things
>>>> like this where users and more casual contributors had ideas and
>>>> saw possibilities that others, even more involved contributors,
>>>> totally missed or never looked at that way. What I think would be
>>>> fun, and ultimately useful too, is to keep this mostly to
>>>> brainstorming and not do too much comparing of ideas.
>>>>
>>>> BTW, if you want to brainstorm about one of the tiers (ie the Data,
>>>> Logic, or UI tiers) please use the other threads on those.
>>>>
>>>> -David
>>>>
>>>>
>>>>  
>>>>      
>>
>>
>>  
>
>

[Jacques Le Roux]

Thanks Raj,

Fun isn'it? :D
I think if we do it seriouly we can benefit from this better organized way for suggestions.
Is anybody against putting a link from the main site?
I guess I will use http://ofbiz.uservoice.com/ since Raj put the 1st real question there
We could create as much as forums as we need, but for now this one is clearly enough.

Jacques

From: "Raj Saini" <[hidden email]>

> Done  :-)
>
> Jacques Le Roux wrote:
>> Hi Raj,
>>
>> As I see much interest in OSDGI (not particularly me, I mean in the
>> community) I would suggest to create an entry at
>> http://ofbiz.uservoice.com/
>> or
>> http://ofbiz.ideascale.com/
>> as you like
>>
>> Thanks
>>
>> Jacques
>>
>>
>> From: "Raj Saini" <[hidden email]>
>>> Hi David,
>>>
>>> One thing could be useful in the long run is moving to OSGi based
>>> components. There are numerous benefits of OSGi and you can find a a
>>> lot about it on the net. The kind of modularity OSGi brings is not
>>> possible in other components modules. Dynamic bundle loading and
>>> unloading is useful during development and run time. During
>>> development, for example if you have changed some Java code in one of
>>> the bundle, you do not need to restart the complete server to load
>>> the new code. Just update or stop/start the bundle and you are ready
>>> to test. One more advantage I see is exporting OFBiz services as web
>>> services or distributed OSGi services. Eclipse ECF and Apache CXF
>>> provide distributed OSGi implementation. Integration with other
>>> applications such as ServiceMix should also be very easier as they
>>> are already run on OSGi platform.
>>>
>>> Thanks,
>>>
>>> Raj
>>>
>>>
>>> I recently completed a prototype to run the OFBiz framework embedded
>>> in the Equinox OSGi runtime and it worked fine with little changes
>>> here and there.
>>> David E Jones wrote:
>>>> If you could change anything about the OFBiz framework (not related
>>>> to a specific tier), what would it be? This could be about how OFBiz
>>>> is deployed, how the tools fit together, how application components
>>>> are written and organized, and so on.
>>>>
>>>> All comments are welcome. If there is another tool you'd like to see
>>>> used, please describe what you like about it (like "I've found the
>>>> aspect oriented inversion of control approach nice because I can
>>>> plugin all sorts of tools and the full life cycle of the tools are
>>>> managed for me") instead of just mentioning the tool (like "let's
>>>> use Spring!").
>>>>
>>>> Why am I asking? This topic comes up every once in a while, and it's
>>>> true that many suggestions never get enough support to actually
>>>> happen (or on further research it is decided that the idea is not
>>>> tenable), but brainstorming about them to get ideas in the open is
>>>> still a great thing. The history of OFBiz is full of things like
>>>> this where users and more casual contributors had ideas and saw
>>>> possibilities that others, even more involved contributors, totally
>>>> missed or never looked at that way. What I think would be fun, and
>>>> ultimately useful too, is to keep this mostly to brainstorming and
>>>> not do too much comparing of ideas.
>>>>
>>>> BTW, if you want to brainstorm about one of the tiers (ie the Data,
>>>> Logic, or UI tiers) please use the other threads on those.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

[Joe Eckard]

Something I've thought about from time to time but never followed  
through all the way to make sure there are no glaring problems: switch  
UtilProperties to use something like Commons Configuration.

This would essentially put all configuration variables into one  
namespace, where they would be accessed via XPath expressions. You  
could pull and merge from various sources like properties files or XML  
files, get (optional) automatic saving / reloading, and (optional)  
property overriding.

The main reason for this would be to have a single file you could use  
for deployment (dev.xml, staging.xml, production.xml, etc) - drop this  
in your hot-deploy component and have it override the values in  
framework / applications.

[Adrian Crum-2]

That is a great idea!

-Adrian

--- On Sun, 3/14/10, Joe Eckard <[hidden email]> wrote:

> From: Joe Eckard <[hidden email]>
> Subject: Re: Brainstorming about the Framework: General
> To: [hidden email]
> Date: Sunday, March 14, 2010, 9:57 AM
> Something I've thought about from
> time to time but never followed through all the way to make
> sure there are no glaring problems: switch UtilProperties to
> use something like Commons Configuration.
>
> This would essentially put all configuration variables into
> one namespace, where they would be accessed via XPath
> expressions. You could pull and merge from various sources
> like properties files or XML files, get (optional) automatic
> saving / reloading, and (optional) property overriding.
>
> The main reason for this would be to have a single file you
> could use for deployment (dev.xml, staging.xml,
> production.xml, etc) - drop this in your hot-deploy
> component and have it override the values in framework /
> applications.

     

[Erwan de FERRIERES]

Le 14/03/2010 17:57, Joe Eckard a écrit :

> Something I've thought about from time to time but never followed
> through all the way to make sure there are no glaring problems: switch
> UtilProperties to use something like Commons Configuration.
>
> This would essentially put all configuration variables into one
> namespace, where they would be accessed via XPath expressions. You could
> pull and merge from various sources like properties files or XML files,
> get (optional) automatic saving / reloading, and (optional) property
> overriding.
>
> The main reason for this would be to have a single file you could use
> for deployment (dev.xml, staging.xml, production.xml, etc) - drop this
> in your hot-deploy component and have it override the values in
> framework / applications.

Very good thought ! Have you already got a POC ?

--
Erwan de FERRIERES
www.nereide.biz

[Jacques Le Roux]

I stumbled upon this discussion while looking at
http://commons.apache.org/configuration/userguide/howto_filebased.html#Automatic_Reloading
I have no plans at the moment, but I'd like to use something like that indeed

Jacques

From: "Erwan de FERRIERES" <[hidden email]>

> Le 14/03/2010 17:57, Joe Eckard a écrit :
>> Something I've thought about from time to time but never followed
>> through all the way to make sure there are no glaring problems: switch
>> UtilProperties to use something like Commons Configuration.
>>
>> This would essentially put all configuration variables into one
>> namespace, where they would be accessed via XPath expressions. You could
>> pull and merge from various sources like properties files or XML files,
>> get (optional) automatic saving / reloading, and (optional) property
>> overriding.
>>
>> The main reason for this would be to have a single file you could use
>> for deployment (dev.xml, staging.xml, production.xml, etc) - drop this
>> in your hot-deploy component and have it override the values in
>> framework / applications.
>
> Very good thought ! Have you already got a POC ?
>
> --
> Erwan de FERRIERES
> www.nereide.biz
>

[Atul Vani]

+1

Can get something like Managed Reloading added in the webtools, will be handy.

----- Original Message -----
From: "Jacques Le Roux" <[hidden email]>
To: [hidden email]
Sent: Saturday, July 16, 2011 2:56:30 PM
Subject: Re: Brainstorming about the Framework: General

I stumbled upon this discussion while looking at
http://commons.apache.org/configuration/userguide/howto_filebased.html#Automatic_Reloading
I have no plans at the moment, but I'd like to use something like that indeed

Jacques

From: "Erwan de FERRIERES" <[hidden email]>

> Le 14/03/2010 17:57, Joe Eckard a écrit :
>> Something I've thought about from time to time but never followed
>> through all the way to make sure there are no glaring problems: switch
>> UtilProperties to use something like Commons Configuration.
>>
>> This would essentially put all configuration variables into one
>> namespace, where they would be accessed via XPath expressions. You could
>> pull and merge from various sources like properties files or XML files,
>> get (optional) automatic saving / reloading, and (optional) property
>> overriding.
>>
>> The main reason for this would be to have a single file you could use
>> for deployment (dev.xml, staging.xml, production.xml, etc) - drop this
>> in your hot-deploy component and have it override the values in
>> framework / applications.
>
> Very good thought ! Have you already got a POC ?
>
> --
> Erwan de FERRIERES
> www.nereide.biz
>