from:"Marc Morin"

Re: getter/setter facade

2010-12-12 Thread Marc Morin

We chose to use the full model reader when running the entity-gen since there 
are not trivial manipulations of the en*xml  files, such as extending, 
auto-relationships, auto-indexes, materialized views, view optimizations...

We don't entiy-gen on every build. Manually done. This is a bit of a pain, 
would be better if it was performed when needed.

- Original Message -
 Marc Morin wrote:
  We statically generate all the classes during build as you
  mentioned. We have a new ant target 'entity-gen' that runs
  after framework base util entity have been compiled. It is
  a custom container that reads the entity model, puts stuff
  into a context, then uses an ftl for the template of each
  the classes.
 
 container isn't needed. Use xslt, that reads all
 ofbiz-component.xml+component-load.xml, recursively, then all entity
 models(again, recursively), to output java.
 
 I've done something like this to generate makefiles that convert
 entitymodel to sql stmts(CREATE TABLE (field type), CREATE VIEW AS
 SELECT). I then used that to verify that my new enhanced sql reader
 could read all the same model that the standard classes could.
 
 The xslt method would run faster, then launching a quicky ofbiz
 instance, and your special container.
 
  This generates two artifacts:
 
  - a class for each entity and view-entity in the system.
  - a .properties file used by GenericValue.create() to instantiate
  the correct class for the entity.
 
 I wouldn't generate a properties file. I would generate each java
 file, compile it, store it into it's own .jar(in build/lib in the
 component), and then add a META-INF/services file that lists each
 entity.
 
 It might be nice to extend your system to handle the
 Party/Person/PartyGroup pattern as well(delegator would need to be
 enhanced to load the base values).

getter/setter facade (was: Re: O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition)))

2010-12-11 Thread Marc Morin

Now it's pretty obvious that many are reading the incorrectly renamed O-R 
mapping subject and saying it's counter to OFBiz entity model, core philosophy, 
discussed before... go away you Object lovin' Java developer... ;-)

I don't want to repeat the topic, but it is a getter/setter decorator around 
the Entity/Delegator API that you all love.  Not hibernate, not OO 
persistence...

I don't know how anyone can say that the following code is nicer, safer, 
easier to maintain

GenericValue order = delegator.findOne(OrderHeader, 
UtilMisc.toList(orderId, orderId), true);
Timestamp entryDate = order.getTimestamp(entryDate);
ListGenericValue orderItems = order.getRelated(OrderItem);

vs (evil Object facade, what a Java developer would expect to see, IDE 
auto-completion, type safety)

OrderHeader order = OrderHeader.findOne(delegator,orderId);
Timestamp entryDate = order.getEntryDate();
ListOrderItem orderItems = order.getOrderItemList();

My point is, there is a simple facade we can present on all the goodness of the 
GenericValue, delegator, dispatcher, transactions, that makes the Java purest 
feel better about OFBiz.  (been easier to find Java developers than OFBiz 
ones...)

We have been using this exact decorator pattern in our OFBiz application for 
over 2 years, it feels natural when writing Java code (ie. when in Rome act 
like a Roman), haven't heard any developers say they don't want to use it in 
favor of the String way, once exposed to it and writing new code.  When 
modifying existing code, they want to change all GenericValues to their 
appropriate object decorator. (we aren't doing this in app/framework so we can 
merge easier, but would love to do see it done/do it)

Well, looks like we'll continue on our own marry way on this one, keep our 
forked technology to ourselves  I can feel the rope pushing that I 
mentioned previously. ;-)

Re: getter/setter facade

2010-12-11 Thread Marc Morin

We statically generate all the classes during build as you mentioned.  We have 
a new ant target 'entity-gen' that runs after framework base util entity have 
been compiled.  It is a custom container that reads the entity model, puts 
stuff into a context, then uses an ftl for the template of each the classes.

This generates two artifacts:

- a class for each entity and view-entity in the system.
- a .properties file used by GenericValue.create() to instantiate the correct 
class for the entity.  

Since our current implementation runs after the entity is loaded, all extending 
is done already. Anticipating the next question, as it reads the entire model 
and all extends and relations, it will generate a single global map and linking 
for entities.  (Entity model is global to all applications)

We just use List as a convention, debated just using 's' (like 
order.getOrderItems()) which feels normal.  We don't worry about the namespace 
collision of field X and relation to entity X using the same getX() gettor, 
haven't observed it.

So, if you create entity X in your hot-deploy application, it will see X and 
generate it along with the base entities... any relations to and from X to base 
entities will result in regenerating X and the base entities (not a good thing).

You'd really like to generate the decorator in each application area where the 
entities are defined  so application X would see a class X with 
getter/setters and relations as it was defined.

Application Y extends entity X, means that it should see Y's version...  likely 
could be done with a classpath search order, but behind the scenes, you can 
only create a single class X for entity named X, no matter what application 
is using it!

We've side stepped this issue by living with the global generation issue.

NB. Extending means entity-extend AND adding a relation to/from that entity 
since gettors will be generated for the getRelated.

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Original Message -
 Marc Morin wrote:
  Now it's pretty obvious that many are reading the incorrectly
  renamed O-R mapping subject and saying it's counter to OFBiz entity
  model, core philosophy, discussed before... go away you Object
  lovin' Java developer... ;-)
 
  I don't want to repeat the topic, but it is a getter/setter
  decorator around the Entity/Delegator API that you all love. Not
  hibernate, not OO persistence...
 
  I don't know how anyone can say that the following code is nicer,
  safer, easier to maintain
 
  GenericValue order = delegator.findOne(OrderHeader,
  UtilMisc.toList(orderId, orderId), true);
  Timestamp entryDate = order.getTimestamp(entryDate);
  ListGenericValue orderItems = order.getRelated(OrderItem);
 
  vs (evil Object facade, what a Java developer would expect to see,
  IDE auto-completion, type safety)
 
  OrderHeader order = OrderHeader.findOne(delegator,orderId);
  Timestamp entryDate = order.getEntryDate();
  ListOrderItem orderItems = order.getOrderItemList();
 
 Only one suggestion on the api. getOrderItemList should not have a
 list suffix on the method. The type return is defined by the entity
 definition(in this case, 'many'). Plus, once removing the list
 suffix, OrderItem could conflict by name with a field named the same.
 So, in such cases, remove the get prefix. order.OrderItem().
 
 Have you extended the base-line non-typed get() method to support
 relation fetching? So, in groovy, I could do order.entryDate(which is
 possible now), or order.OrderItem(because the first char is capital,
 it would do a relation fetch).
 
 As for those of us that have been resisting, I don't want to be one of
 those. Ofbiz is for a community, and if people want this, then we
 shouldn't really say no. I have moved back and forth several times
 over the years about this.
 
 The interface wouldn't be hard to write. At build type, something
 similar to javacc/jjtree would be run, that would auto-generate a java
 class, based on any entity.
 
 Er, oops, I just found a problem with your idea. How do you handle
 extend-entity?

Re: getter/setter facade

2010-12-11 Thread Marc Morin

Well the good old GenericValue is an object as well. ;-)


Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Original Message -
 when you use a Class it is an object.
 getter and setter are methods by another name.
 if you instantiate a class all the methods are carried with it whether
 they are used or not.
 so regardless of your argument it is OO.
 
 if you are familar with c then create a hello world function and
 compile then create a class hello world. not the difference in size
 and look at
 the stack for a call to both.
 
 the last time I did this the function compiled to 1K the class compile
 was 10K with no methods in the class.
 
 then put getter and setter in the hellow world and watch the size and
 the stack when using the class.
 
 this will give you an idea of what is being talked about.
 
 
 
 =
 BJ Freeman
 Strategic Power Office with Supplier Automation
 http://www.businessesnetwork.com/automation/viewforum.php?f=52
 Specialtymarket.com http://www.specialtymarket.com/
 Systems Integrator-- Glad to Assist
 
 Chat Y! messenger: bjfr33man
 
 Marc Morin sent the following on 12/11/2010 12:40 PM:
 
 
  Now it's pretty obvious that many are reading the incorrectly
  renamed O-R mapping subject and saying it's counter to OFBiz entity
  model, core philosophy, discussed before... go away you Object
  lovin' Java developer... ;-)
 
  I don't want to repeat the topic, but it is a getter/setter
  decorator around the Entity/Delegator API that you all love. Not
  hibernate, not OO persistence...
 
  I don't know how anyone can say that the following code is nicer,
  safer, easier to maintain
 
   GenericValue order = delegator.findOne(OrderHeader,
   UtilMisc.toList(orderId, orderId), true);
   Timestamp entryDate = order.getTimestamp(entryDate);
   ListGenericValue orderItems = order.getRelated(OrderItem);
 
  vs (evil Object facade, what a Java developer would expect to see,
  IDE auto-completion, type safety)
 
   OrderHeader order = OrderHeader.findOne(delegator,orderId);
   Timestamp entryDate = order.getEntryDate();
   ListOrderItem orderItems = order.getOrderItemList();
 
  My point is, there is a simple facade we can present on all the
  goodness of the GenericValue, delegator, dispatcher, transactions,
  that makes the Java purest feel better about OFBiz. (been easier to
  find Java developers than OFBiz ones...)
 
  We have been using this exact decorator pattern in our OFBiz
  application for over 2 years, it feels natural when writing Java
  code (ie. when in Rome act like a Roman), haven't heard any
  developers say they don't want to use it in favor of the String
  way, once exposed to it and writing new code. When modifying
  existing code, they want to change all GenericValues to their
  appropriate object decorator. (we aren't doing this in app/framework
  so we can merge easier, but would love to do see it done/do it)
 
  Well, looks like we'll continue on our own marry way on this one,
  keep our forked technology to ourselves I can feel the rope
  pushing that I mentioned previously. ;-)

Re: getter/setter facade

2010-12-11 Thread Marc Morin


 Have you extended the base-line non-typed get() method to support
 relation fetching? So, in groovy, I could do order.entryDate(which is
 possible now), or order.OrderItem(because the first char is capital,
 it would do a relation fetch).
 

So we haven't but that is something that should be done in 
GenericValue.get(fieldName). Good idea.

Re: getter/setter facade

2010-12-11 Thread Marc Morin

We have talked and lamented on handling in the framework the Entity 
sub-classing *Type entities with the hasTable and *TypeId hierarchy

both on loading and the is A operator on entities and their types...

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Original Message -
 Marc Morin wrote:
  We statically generate all the classes during build as you
  mentioned. We have a new ant target 'entity-gen' that runs
  after framework base util entity have been compiled. It is
  a custom container that reads the entity model, puts stuff
  into a context, then uses an ftl for the template of each
  the classes.
 
 container isn't needed. Use xslt, that reads all
 ofbiz-component.xml+component-load.xml, recursively, then all entity
 models(again, recursively), to output java.
 
 I've done something like this to generate makefiles that convert
 entitymodel to sql stmts(CREATE TABLE (field type), CREATE VIEW AS
 SELECT). I then used that to verify that my new enhanced sql reader
 could read all the same model that the standard classes could.
 
 The xslt method would run faster, then launching a quicky ofbiz
 instance, and your special container.
 
  This generates two artifacts:
 
  - a class for each entity and view-entity in the system.
  - a .properties file used by GenericValue.create() to instantiate
  the correct class for the entity.
 
 I wouldn't generate a properties file. I would generate each java
 file, compile it, store it into it's own .jar(in build/lib in the
 component), and then add a META-INF/services file that lists each
 entity.
 
 It might be nice to extend your system to handle the
 Party/Person/PartyGroup pattern as well(delegator would need to be
 enhanced to load the base values).

Re: findByAnd(Map) ws findList(EntityCondition)

2010-12-10 Thread Marc Morin

In the spirit of changing the entity/delegator interface more object friendly, 
why not take this to then next step and generate POJO interfaces for each 
entity.  These would extend GenericValue but provide a simple gettor/settor 
facade allowing compile time type checking and removing of the string code 
for much of the business logic written in java.

We have done such a thing (again in our forked application), and it makes the 
Java code much more readable and easier to use.  The general structure is


public class Person extends AbstractGenericValuePerson
{
public static final String ENTITY = Person;
 
// constructor, only called from makeValue, MUST be associated with a 
delegator
protected Person(Delegator delegator) {...}

// factory method
public static Person newInstance(Delegator delegator) {...}

// generate finders, by pkey, etc...
public static Person findOne(Delegator delegator, String partyId){...}

// getter and settors
public String getFirstName() {
return getString(firstName);
}
public Person setFirstName(String value) {
set(firstName, value);
return this;
}

// relationships 
public Party getParty() throws GenericEntityException {...}
public PartyNameView getPartyNameView() throws GenericEntityException{...}
}

This allows code that is much easier to debug and less error prone.. example 
below is for navigating orders.

OrderHeader orderHeader = OrderHeader.findOne(delegator, orderId);

// get the orderItems
ListOrderItem orderItems = orderHeader.getOrderItemList();

BigDecimal totalQuantity = BigDecimal.ZERO;
for (OrderItem orderItem: orderItems) {

 totalQuantity = totalQuantity.add(orderItem.getQuantity());
}

I know we want to encourage business logic in minlang, etc... but if it is 
written in java, and there is a LOT of code in java, shopping cart, etc...  
this makes that code MUST more readable and maintainable.  The binding between 
the entity model and the java implementation can be caught as a compile time 
error...  significantly lowers the maintenance cost of the code.

This may be pushing a rope, but we use this ALL the time for our groovy and 
java code. (would also apply to jsp code obviously). Minilang code can be type 
checked by the reader... (want to check for static errors in code, without the 
need to run the code).

We have implemented the generators, and the refactoring/abstracting to enable 
this.  We find it works great and doesn't break ANY of the nice ofbiz extend 
entity semantics, etc  Of course if you extend an entity and then want java 
business logic to use it... you need to access those items either with 
strings as stock ofbiz, or redo an entity-gen.  But if there is no java code 
using the entities, no need to auto-gen.

As another note, we have done a similar thing with the service interface as 
you might have guessed, we're a fan of ofbiz extensibility, but NOT on how it 
encourages poor Java implementation practices. (String object references, 
non-type safe, public static methods everywhere etc...) 

Marc
- Original Message -
 On 10/12/2010, at 8:54 AM, Adam Heath wrote:
 
  On 12/09/2010 01:48 PM, Scott Gray wrote:
  On 10/12/2010, at 5:53 AM, Adam Heath wrote:
 
  On 12/09/2010 12:03 AM, Scott Gray wrote:
  On 9/12/2010, at 11:50 AM, Adam Heath wrote:
 
  On 12/08/2010 03:00 PM, Scott Gray wrote:
  On 8/12/2010, at 4:29 AM, Adam Heath wrote:
 
  I've deprecated findByAnd locally, replacing calls with a
  variant that
  takes a boolean, which specifies whether to use the cache.
 
  Initially, my replacement just added a new findByAnd. However,
  I'm now starting to lean towards replacing with findList
  instead. However, in my opinion, I think that will make
  programming ofbiz more
  difficult.
 
  I'd like to add a findList variant, that takes a Map instead
  of an
  EntityCondition. Without this new variant, there would be ton
  of variants that would only need to import EntityCondition,
  just to
  create a condition.
 
  There are also performance considerations to consider.
 
  EntityCondition.makeCondition(Map) directly takes the map,
  doing no
  processing. However, EntityCondition.makeCondition(Object...)
  eventually calls EntityUtil.makeFields, which does a little
  more than
  UtilMisc. In addition to the iteration over the array, it also
  does a
  check on the value for Comparable/Serializable. This latter
  check seems a bit superfluous, as eventually the base
  condition classes
  check the values against the model.
 
  So, from a purist stand point, even tho findByAnd could be
  replaced by
  findList, I think it is too useful; it saves enough code in
  application layers, imho.
 
 
  This reminded me of the query objects with method chaining that
  I suggested a while back so I threw them together this morning.
 
  Here are some examples:
  thisContent = delegator.findByPrimaryKeyCache(Content,

Re: O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition))

2010-12-10 Thread Marc Morin

The facade doesn't instantiate more objects than current, but the class 
hierarchy is taller.  (ie.  when GenericValue.makeValue() currently 
instantiates a GenericValue(), that factory would then instantiate a class 
based on the entity name, that derives from GenericValue()).

The speed of the extra layer for the getter/setter is not worth mentioning.

I disagree that OOTB OFBiz should not use this in any part of the offering.  
The Entity engine should not be dependent on any Entity instance as it isn't, 
but OFBiz's applications benefits tremendously! Even framework code such as the 
ControlServlet that is accessing the Visit entity, it has a code dependency 
between the Visit entity and the Java code, using a Visit facade over 
GenericValue with visitId,etc... doesn't hurt. The code for orders, product, 
etc.. become much easier to understand, follow and maintain.   I don't see any 
downside on any OFBiz code implemented in Java not using this pattern.

Am I pushing a rope on this issue?  If so, I will stop debating...

Marc

- Original Message -
 I am happy as long as not OOTB
 I doubt that there will be any effort to optimize, under current
 design, if they are done in OO way. as you said the path of least
 resistance with the fact that the volunteer group does not have energy
 to do that.
 
 
 
 
 
 
 BJ Freeman
 Strategic Power Office with Supplier Automation
 http://www.businessesnetwork.com/automation/viewforum.php?f=52
 Specialtymarket.com http://www.specialtymarket.com/
 Systems Integrator-- Glad to Assist
 
 Chat Y! messenger: bjfr33man
 
 
 Adam Heath sent the following on 12/10/2010 10:17 AM:
  On 12/10/2010 11:54 AM, BJ Freeman wrote:
  the facade is exactly what ofbiz wants to avoid.
  the extra overhead of the conversion.
 
  I disagree.
 
  OOTB ofbiz should not use any such facades. But having them
  available for end-users to make use of is a win, IMHO. Makes it
  easier for new
  people to get involved in ofbiz.
 
  This facade pattern will obviously be slower; it contains more
  object instantiations, and more method calls. And, in groovy at
  least, those
  end up using reflection. But if it allows people to write more
  application code, which can later be optimized to be faster, then
  I'm all for it.

Re: O-R Mapping (Was: findByAnd(Map) ws findList(EntityCondition))

2010-12-10 Thread Marc Morin

Yes, permgen space needs to be increased with this. 

Sorry, I mis-understood your objection as a performance related to speed of the 
newInstance() vs more classes.

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Original Message -
 On 12/10/2010 06:37 PM, Marc Morin wrote:
  The facade doesn't instantiate more objects than current, but the
  class hierarchy is taller. (ie. when GenericValue.makeValue()
  currently instantiates a GenericValue(), that factory would then
  instantiate a class based on the entity name, that derives from
  GenericValue()).
 
 A class based on GenericValue(even one generated dynamically at
 runtime, into a custom classloader), is still a class. Said class is
 not loaded on the heap. It's bytecode is placed into permgen. More
 classes would increase permgen pressure.

[jira] Commented: (OFBIZ-4041) Materialized views

2010-12-08 Thread Marc Morin (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969414#action_12969414
]

Marc Morin commented on OFBIZ-4041:
---

Good point Scott. We have removed the bulk operations in our implementation
for specifically that reason... We've noticed that even though these are bulk
operations, they don't appear to be from an API point of view. There isn't
much to help guide the developer that using these API's will circumvent all ECA
activity

We had thought about only doing the bulk operation iff there are no ECAs
defined for the entity and operation defined. Otherwise, leave it as bulk.
But that too would appear to be dangerous since there are unknown side affects
of not running the ECA.

Not sure what the best/good compromise is for the bulk vs normal operation is.
Just seems incorrect to bypass the ECA. Not that disabling the eca via the
entityengine.xml also causes the materialized views to not always maintaining
it's results.

Materialized views
--

Key: OFBIZ-4041
URL: https://issues.apache.org/jira/browse/OFBIZ-4041
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: Release Branch 10.04
Reporter: Marc Morin
Attachments: OFBIZ-4041.patch

We make extensive use of view entities in our ofbiz application. We have
noticed that when there is a large dataset and under some complex views, the
query performance was not the best (not a index issue, just complex joins,
etc...).
With some commercial databases like Oracle, etc... we would have used
materialized view semantics available for these dbms, but we are using
PostgreSQL.
So, we have extended the entity layer in Ofbiz to perform the
materialization. This is pretty slick as all you need to do is the following:
view-entity name=myView materialize=true.../view-entity
and the system will do the following:
- create a backing entity called myView that has the same fields as the view
- backing entity has all the indexes inherited from the component entities
- relations (fk,...) inherited from the component entities.
- perform all the ECA actions automatically on all entities used in the view
(direct members and nested members if case of view on views). (This is an
eager update strategy only).
So, the application doesn't change, it still accesses myView, but now, it's
result is returned from the backing entity instead of the complex SQL
statement.
We're pretty excited about this feature!!! Really pushes Ofbiz framework to
next level and allows materialized views to be more broadly used on dbms that
don't naturally support it.
We are prepared to contribute this feature back to the community if desired.
A note of caution about it though we have added a visitor pattern to the
model entities and this feature makes use of it. It would need to come with
it.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-4041) Materialized views

2010-12-08 Thread Marc Morin (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969573#action_12969573
]

Marc Morin commented on OFBIZ-4041:
---

Adam, are you commenting on the materialized view problem vs the bulk
operations? Either way, both use the same logic of cascading possible
operations to dependent model items (either in the cache) or materlalized
views. If you look at the patch, the materialized views use the EXACT same
ModelConversion information that the cache uses to propage, but instead of
clearing values, it clears and rebuilds.

Materialized views
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-4041) Materialized views

2010-12-06 Thread Marc Morin (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marc Morin updated OFBIZ-4041:
--

Attachment: OFBIZ-4041.patch

Patch for implementation of Materialized views. This implementation used a
visitor pattern, on the ModelEntity (and related classes) so they are part of
the patch. Also, since entities are created by code, as opposed to by reading
XML files, a number of getters and setters were added to the model objects.

A new class, ModelMaterializedEntity is created when a view is read having
materialized=true property. It creates an ECA for all the dependent
entities used by the view.

There is NO checking on the usefulness or expense of the materialized views.
It should also only be used on views where the pkey of the underlying entity is
exposed as a field in the view, since this makes the ECA more efficient.

CheckDb will rebuild all materialized views since there is no way currently in
OFBIZ to detect that the view's definition has changed. In our implementation,
we record an MD5 of the view as a comment on the table thereby detecting if
we need to rebuild. That wasn't included at this time.

No ECA to prevent store/remove on the backing entity.

Materialized views
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: findFoo(cache=false), without modification, in a transaction, issue warning

2010-12-06 Thread Marc Morin

We've found that our application is not useable (according to our customers) 
without entity caching enabled.

Like I emailed previously, we've made extensive improvements on the entity 
cache to increase the hit rate (only store value once if fetched by pkey and 
then in an entity condition) and lower memory consumption, store objects in 
dictionary, so that singleton for each Object fetched from db, String.intern() 
some Field values to make PARTY.equals(..) checks faster, etc  All these 
changes are required for multi-tenant systems where the is a rather high degree 
of redundant information in each tenant instance. (think of enumerations, 
types, etc...)

Copy on write database objects, so developer doesn't need to worry about 
corrupting other users of the data if they want/need to modify an entity.

Transactional support for the cache. (bug vs design choice in my opinion).

We've turned on entity caching by default, and would like to remove the 
useCache from the api.  Don't mind returning a non-caching delegator via a 
delegator decorator, that way, there is no API difference.

The don't need to cache issue is handled by adding a WeakReference cache 
instance on top of SoftReference.  This makes it so that as long as the JVM has 
it in memory, why not re-use it?

I prefer to let the framework take care caching (and for how long, etc...) for 
me.

Marc

Re: findFoo(cache=false), without modification, in a transaction, issue warning

2010-12-06 Thread Marc Morin

 
 ==
 extend-entity name=Person absorb-condition-values=true/
 if (modelEntity.getAbsorbConditionValues()) {
 for (GenericValue value: list) {
 cache.putToCache(value) }
 } ==
 extend-entity name=Party
 extend-field name=partyTypeId intern-value=true/
 /extend-entity if (modelField.getInternValue()) {
 value = value.intern()
 } ==
 
 It would be very difficult to store the same FooType once for multiple
 tenants, as the timestamp fields might be different across
 databases(depending on when the last time seed install was run). It
 might be possible to cache value instances, using a combined weak/soft
 value map.

We maintain a weak reference map of all objects fetched from the jdbc driver.   
This ensures that only a single object (being identical) will be in the JVM's 
memory at a time.  We don't even try to see if there is a low probability...  
just put all objects into it.

 
  Copy on write database objects, so developer doesn't need to
  worry about corrupting other users of the data if they want/need
  to modify an entity.
 
 In some cases, you know beforehand that you will be modifying a
 generic value; in those cases, it makes no sense to store anything at
 all into the cache. This implies you'd want an api to support
 skipping cache storage, so we are right back to having a useCache flag
 in the api.

Yes, but the JVM will keep it in memory until the garbage collector decides to 
discard it.  The implementation,
using WeakReferences would make it available until the JVM decides it is not 
present anymore.

 
  Transactional support for the cache. (bug vs design choice in my
  opinion).
 
 The last time I looked for a transactional aware map(using jta), it
 didn't support generics. I found one that was close on jakarta.

We implemented our own using a Synchronization instance with the transaction 
manager, one for each open transaction.  Only really care about rollback or 
commit.  The implementation essentially guards the committed cache with a 
per-transaction cache.  New puts to the cache a put into the pre-transaction 
maps,  then posted to the real cache on commit.  On rollback, they are 
discarded.  Cache gets check the transaction cache and if nothing present, 
checks the commited cache.

Invalidations on the cache, occur on both the per-transaction cache and the 
committed cache.

In the end, not difficult, just needed a layer between the EntityCache and the 
UtilCache code.



 
  We've turned on entity caching by default, and would like to
  remove the useCache from the api. Don't mind returning a
  non-caching delegator via a delegator decorator, that way, there
  is no API difference.
 
 Delegator proxies is something I'd like to support. However, because
 GenericEntity/GenericPK/GenericValue are classes, it makes it hard to
 proxy in all cases, so that getDelegator() returns the correct
 instance.

With our copy-on-write work, we've essentially made the GenericEntity an 
interface and GenericValue extends GenericEntityDecorator.  Might make it 
easier to break the delegator from the entity itself.

Re: GenericValue.getRelatedOne/Cache

2010-12-03 Thread Marc Morin

Just my $0.02, but I am not a fan of the cache/no-cache paradigm in ofbiz.  
Forcing the application developer to know about the cache leads to unstable 
code and usually slower execution of the application (ie. being conservative 
and saying cache-off, since it MAY be modified).

The cache is something that the application developer should never need to 
concern themselves with.  Of course, with ofbiz, this isn't the case, and it 
has to do with the fact that the cache returns immutable objects.

I'd like to open up a discussion about changing/improving the implementation of 
the entity/condition cache layer to improve this.  The goals are:

- cache is passively managed by the framework. Application layer NEVER exposes 
cache boolean or cache variant methods.
- goal to maintain a single object reference for the same pkey.  (ie.  
findByPrimaryKey() and and search by and returning same value point to the same 
instance).
- soft reference on cache (ofbiz does this already).
- weak reference on entities marked non-cached (if it's in the jvm memory 
already, why not return it).
- entity definition cache flag, as it is now. (controls hard/soft vs weak)
- respect transaction boundaries (current cache doesn't... try insert entity, 
find it, rollback entity remains in cache).
- objects fetched from delegator are always mutable.  (use a copy on write 
semantic for cache).
- distributed cache semantics (already in ofbiz)
- nested views on views and proper cache behavior

Now, I am not just trying to create a make work project here.   We have already 
implemented all of these changes in our application's use of ofbiz.  I'd be 
prepared to package this up and contribute it back to the community.   Please 
advise.


Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Original Message -
 A while back, I started adding more variants of
 GenericDelegator.findByPrimaryKey. The outcome of that was to remove
 those variants, and reduce the methods.
 
 However, while looking at unrelated code tonight, I thought we should
 do the same to the lookup methods in GenericValue. For instance, I
 saw this pattern:
 
 if (booleanValue) {
 nextValue = value.getRelatedOneCache(relation);
 } else {
 nextValue = value.getRelatedOne(relation);
 }
 
 I think it would be better to change that to getRelatedOne(relation,
 boolean).
 
 Do others agree? What about the other methods in that class?

Materialized views

2010-12-03 Thread Marc Morin

We make extensive use of view entities in our ofbiz application.  We have 
noticed that when there is a large dataset and under some complex views, the 
query performance was not the best (not a index issue, just complex joins, 
etc...).

With some commercial databases like Oracle, etc... we would have used 
materialized view semantics available for these dbms, but we are using 
PostgreSQL.

So, we have extended the entity layer in Ofbiz to perform the materialization.  
This is pretty slick as all you need to do is the following:

view-entity name=myView materialize=true.../view-entity

and the system will do the following:

- create a backing entity called myView that has the same fields as the view
- backing entity has all the indexes inherited from the component entities
- relations (fk,...) inherited from the component entities.
- perform all the ECA actions automatically on all entities used in the view 
(direct members and nested members if case of view on views). (This is an eager 
update strategy only).

So, the application doesn't change, it still accesses myView, but now, it's 
result is returned from the backing entity instead of the complex SQL statement.

We're pretty excited about this feature!!!  Really pushes Ofbiz framework to 
next level and allows materialized views to be more broadly used on dbms that 
don't naturally support it.

We are prepared to contribute this feature back to the community if desired.  A 
note of caution about it though we have added a visitor pattern to the 
model entities and this feature makes use of it.  It would need to come with 
it.   

Please advise.


Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com

Re: Materialized views

2010-12-03 Thread Marc Morin

The implementation of materialized views will work with any SQL database 
server. MySql, postgres, derby, oracle, etc.

It is implemented using 100% ofbiz application layer constructs, entity model, 
and entity-eca's.

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Original Message -
 the Idea is good.
 Consideration though should be at a layer where all DB used by ofbiz
 can implements something similar. mysql and Postgresql are two main
 ones used. ms sql is also used.
 this is the reason, for instance that all indexes are limited to 30
 since one of the db, that is its maximum index length.
 you will find in the Data layer that ofbiz creates temporary procedure
 or Functions calls to those DB that support that.
 
 =
 BJ Freeman
 Strategic Power Office with Supplier Automation
 http://www.businessesnetwork.com/automation/viewforum.php?f=52
 Specialtymarket.com http://www.specialtymarket.com/
 Systems Integrator-- Glad to Assist
 
 Chat Y! messenger: bjfr33man
 
 
 Marc Morin sent the following on 12/3/2010 6:26 AM:
  We make extensive use of view entities in our ofbiz application. We
  have noticed that when there is a large dataset and under some
  complex views, the query performance was not the best (not a index
  issue, just complex joins, etc...).
 
  With some commercial databases like Oracle, etc... we would have
  used materialized view semantics available for these dbms, but we
  are using PostgreSQL.
 
  So, we have extended the entity layer in Ofbiz to perform the
  materialization. This is pretty slick as all you need to do is the
  following:
 
  view-entity name=myView materialize=true.../view-entity
 
  and the system will do the following:
 
  - create a backing entity called myView that has the same fields
  as the view
  - backing entity has all the indexes inherited from the component
  entities - relations (fk,...) inherited from the component entities.
  - perform all the ECA actions automatically on all entities used in
  the view (direct members and nested members if case of view on
  views). (This is an eager update strategy only).
 
  So, the application doesn't change, it still accesses myView, but
  now, it's result is returned from the backing entity instead of the
  complex SQL statement.
 
  We're pretty excited about this feature!!! Really pushes Ofbiz
  framework to next level and allows materialized views to be more
  broadly used on dbms that don't naturally support it.
 
  We are prepared to contribute this feature back to the community if
  desired. A note of caution about it though we have added a
  visitor pattern to the model entities and this feature makes use of
  it. It would need to come with it.
 
  Please advise.
 
 
  Marc Morin
  Emforium Group Inc.
  ALL-IN Software
  519-772-6824 ext 201
  mmo...@emforium.com

[jira] Created: (OFBIZ-4041) Materialized views

2010-12-03 Thread Marc Morin (JIRA)

Materialized views
--

 Key: OFBIZ-4041
 URL: https://issues.apache.org/jira/browse/OFBIZ-4041
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Affects Versions: Release Branch 10.04
Reporter: Marc Morin


We make extensive use of view entities in our ofbiz application.  We have 
noticed that when there is a large dataset and under some complex views, the 
query performance was not the best (not a index issue, just complex joins, 
etc...).

With some commercial databases like Oracle, etc... we would have used 
materialized view semantics available for these dbms, but we are using 
PostgreSQL.

So, we have extended the entity layer in Ofbiz to perform the materialization.  
This is pretty slick as all you need to do is the following:

view-entity name=myView materialize=true.../view-entity

and the system will do the following:

- create a backing entity called myView that has the same fields as the view
- backing entity has all the indexes inherited from the component entities
- relations (fk,...) inherited from the component entities.
- perform all the ECA actions automatically on all entities used in the view 
(direct members and nested members if case of view on views). (This is an eager 
update strategy only).

So, the application doesn't change, it still accesses myView, but now, it's 
result is returned from the backing entity instead of the complex SQL statement.

We're pretty excited about this feature!!!  Really pushes Ofbiz framework to 
next level and allows materialized views to be more broadly used on dbms that 
don't naturally support it.

We are prepared to contribute this feature back to the community if desired.  A 
note of caution about it though we have added a visitor pattern to the 
model entities and this feature makes use of it.  It would need to come with 
it.   



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-4041) Materialized views

2010-12-03 Thread Marc Morin (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966673#action_12966673
]

Marc Morin commented on OFBIZ-4041:
---

Not yet, I would need to pull it out of our OFbiz source tree... which is about
a year old and co-mingled with a lot of other framework goodies...

I am prepared to do the work though if the community wants the feature.

Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
mmo...@emforium.com

- Original Message -

Materialized views
--

Key: OFBIZ-4041
URL: https://issues.apache.org/jira/browse/OFBIZ-4041
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: Release Branch 10.04
Reporter: Marc Morin

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Commented: (OFBIZ-4041) Materialized views

2010-12-03 Thread Marc Morin

Ok, I will try to spend some time this weekend in order to pull a patch
together for this.
- Original Message -
[
https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966681#action_12966681
]

Jacques Le Roux commented on OFBIZ-4041:

I'm interested...

Materialized views
--

Key: OFBIZ-4041
URL:
https://issues.apache.org/jira/browse/OFBIZ-4041
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: Release Branch 10.04
Reporter: Marc Morin

We make extensive use of view entities in our ofbiz application. We
have noticed that when there is a large dataset and under some
complex views, the query performance was not the best (not a index
issue, just complex joins, etc...).
With some commercial databases like Oracle, etc... we would have
used materialized view semantics available for these dbms, but we
are using PostgreSQL.
So, we have extended the entity layer in Ofbiz to perform the
materialization. This is pretty slick as all you need to do is the
following: view-entity name=myView
materialize=true.../view-entity
and the system will do the following:
- create a backing entity called myView that has the same fields
as the view
- backing entity has all the indexes inherited from the component
entities - relations (fk,...) inherited from the component entities.
- perform all the ECA actions automatically on all entities used in
the view (direct members and nested members if case of view on
views). (This is an eager update strategy only).
So, the application doesn't change, it still accesses myView, but
now, it's result is returned from the backing entity instead of the
complex SQL statement.
We're pretty excited about this feature!!! Really pushes Ofbiz
framework to next level and allows materialized views to be more
broadly used on dbms that don't naturally support it.
We are prepared to contribute this feature back to the community if
desired. A note of caution about it though we have added a
visitor pattern to the model entities and this feature makes use of
it. It would need to come with it.

-- This message is automatically generated by JIRA.
- You can reply to this email to add a comment to the issue online.

Re: jquey

2010-12-02 Thread Marc Morin

+1, always better to merge sooner, get more testing on it...

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Original Message -
 You're welcome
 +1
 
 Would be a great Xmas present to merge all the stuff into the trunk
 :-)
 
 Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES
 erwan.de-ferrie...@nereide.fr:
 
  Le 02/12/2010 10:35, Jacques Le Roux a écrit :
  Looks like, apart Bruno, we are all on the same page so far
 
  Other opinions, ideas?
 
  Thanks
 
  Jacques
 
 
  The sooner the better !
 
  Thanks for all your work, Jacques and Sascha
 
  -- Erwan de FERRIERES
  www.nereide.biz

Re: Woop! Confluence data imported into git and displayed with webslinger!

2010-10-12 Thread Marc Morin

With all the other technologies in ofbiz, seems like webslinger just adds more 
stuff onto the pile.  I don't want to argue the technical merits of database or 
file system persistence for a CMS, but it appears like ofbiz would benefit from 
reducing the number of technologies used, and increase the amount of re-use of 
technologies it already has.

So, for me, that means entity/service/screen/presentment models are the core 
technologies.   Galvanizing initiatives around those appear to provide leverage.

Now don't get me wrong, the CMS that is native in ofbiz is incomplete and 
needs a lot of work...  and for our use case of providing self edited web sites 
and ecommerce sites, that appears a better starting point.  We have done things 
to add self editing etc... but we need to put a lot more effort into that to 
ensure that there is a real solution.

my $0.02.


Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Original Message -
 On 10/11/2010 10:07 PM, Nico Toerl wrote:
  On 10/12/10 01:41, Adam Heath wrote:
 
  snip
  Now, here it comes. The url to the site.
  http://ofbizdemo.brainfood.com/.
 
  Things to note. There are *no* database calls *at all*. It's all
  done with files on disk. History browsing is backed by git, using
  jgit to read it directly in java. CSS styling is rather poor. Most
  unimplemented pages should do something nice(instead of a big read
  'Not Yet Implemented'); at least there shouldn't be an exceptions
  on those pages.
 
  that sounded real interesting and i thought i have to have a look at
  this, unfortunately all i got is:
 
 
 HTTP Status 500 -
 
  
 
  *type* Exception report
 
  *message*
 
  *description* _The server encountered an internal error () that
  prevented it from fulfilling this request._
 
  *exception*
 
  java.lang.NullPointerException
  
  WEB_45$INF.Events.System.Request.DetectUserAgent_46$jn.run(DetectUserAgent.jn:166)
 
 Hmm, nice, thanks.
 
 Your user-agent is:
 
 Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.9.2.9)
 Gecko/20100824 Firefox/3.6.9
 
 The (x86_64) is what is causing the problem, I hadn't seen this type
 of string in the wild. The regex doesn't like nested (). It's fixed
 now.

Re: Woop! Confluence data imported into git and displayed with webslinger!

2010-10-12 Thread Marc Morin

All of your examples are developer examples.  We are focused on end-users, so 
we don't expect them to use vi, grep, or anything like that.

- Original Message -
 On 10/12/2010 10:25 AM, Adrian Crum wrote:
  Actually, a discussion of database versus filesystem storage of
  content would be worthwhile. So far there has been some hyperbole,
  but few facts.
 
 How do you edit database content? What is the procedure? Can a
 simple editor be used? By simple, I mean low-level, like vi.

No, you run the UI editor/configuration tool.

 
 How do you find all items in your content store that contain a certain
 text word? Can grep and find be used?

can't use grep.

 
 How do you handle moving changes between a production server, that is
 being directly managed by the client, and multiple developer
 workstations, which then all have to go first to a staging server?
 Each system in this case has its own set of code changes, and
 config+data changes, that then have to be selectively picked for
 staging, before finally being merged with production.
 
 What about revision control? Can you go back in time to see what the
 code+data looked like? Are there separate revision systems, one for
 the database, and another for the content? And what about the code?

In our use case, there is no code.  Only a construction of gadgets to make up 
pages.  The code is for the gadgets.
Yes, think of Concrete 5, Joomla, etall.

 
 For users/systems that aren't capable of using revision control, is
 there a way for them to mount/browse the content store? Think
 nfs/samba here.

Nope.

 
 Storing everything directly into the filesystem lets you reuse
 existing tools, that have been perfected over countless generations of
 man-years.

If your a developer.

 
 
  -Adrian
 
  On 10/12/2010 7:32 AM, Marc Morin wrote:
  With all the other technologies in ofbiz, seems like webslinger
  just adds more stuff onto the pile. I don't want to argue the
  technical merits of database or file system persistence for a CMS,
  but it
  appears like ofbiz would benefit from reducing the number of
  technologies used, and increase the amount of re-use of
  technologies it already has.
 
  So, for me, that means entity/service/screen/presentment models are
  the core technologies. Galvanizing initiatives around those appear
  to provide leverage.
 
  Now don't get me wrong, the CMS that is native in ofbiz is
  incomplete and needs a lot of work... and for our use case of
  providing self edited web sites and ecommerce sites, that appears a
  better starting point. We have done things to add self editing
  etc... but we need to put a lot more effort into that to ensure
  that there is
  a real solution.
 
  my $0.02.
 
 
  Marc Morin
  Emforium Group Inc.
  ALL-IN Software
  519-772-6824 ext 201
  mmo...@emforium.com
 
  - Original Message -
  On 10/11/2010 10:07 PM, Nico Toerl wrote:
  On 10/12/10 01:41, Adam Heath wrote:
 
  snip
  Now, here it comes. The url to the site.
  http://ofbizdemo.brainfood.com/.
 
  Things to note. There are *no* database calls *at all*. It's all
  done with files on disk. History browsing is backed by git,
  using jgit to read it directly in java. CSS styling is rather
  poor. Most
  unimplemented pages should do something nice(instead of a big
  read 'Not Yet Implemented'); at least there shouldn't be an
  exceptions on those pages.
 
  that sounded real interesting and i thought i have to have a look
  at
  this, unfortunately all i got is:
 
 
  HTTP Status 500 -
 
  
 
 
  *type* Exception report
 
  *message*
 
  *description* _The server encountered an internal error () that
  prevented it from fulfilling this request._
 
  *exception*
 
  java.lang.NullPointerException
  WEB_45$INF.Events.System.Request.DetectUserAgent_46$jn.run(DetectUserAgent.jn:166)
 
 
  Hmm, nice, thanks.
 
  Your user-agent is:
 
  Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.9.2.9)
  Gecko/20100824 Firefox/3.6.9
 
  The (x86_64) is what is causing the problem, I hadn't seen this
  type of string in the wild. The regex doesn't like nested (). It's
  fixed now.

Re: Developers Note: Screen Widget Model Classes

2010-05-29 Thread Marc Morin

With a well behaved model system, no processing state should be stored in the 
model object.

The renderer uses a modified visitor pattern, (should be real pattern), then 
the state for the rendering instance can and should the be store in the 
renderer/visitor instance.


- Adrian Crum adrian.c...@yahoo.com wrote:

 That could be done too. I don't see where it would be safer. You can
 push/pop a state object in the renderer.
 
 -Adrian
 
 --- On Fri, 5/28/10, Harmeet Bedi harmeet.b...@gmail.com wrote:
The state data doesn't need to
  be stored in the model objects ... can
  be stored just as easily in the renderer.
 
  I think safer practice should be to store state in context
  not renderer.
  So push new map on context, call sub-widget rendering and
  pop map on
  child widget render finish.
 
  Renderer instance is single per screen render. I think of
  it as
  something like global context. So would need to clean state
  after use.
 
  Context(MapStack) may be better suited for this ?
 
  Harmeet
 
  On 29/05/10 4:23 AM, Adrian Crum wrote:
   --- On Fri, 5/28/10, Harmeet Bediharmeet.b...@gmail.com 
  wrote:
   Forms/Screens are specified in XML with a key -
  based on
   xml file and name of element. XML Specifications
  is
   converted into Object model using model classes.
  These
   objects are then used to render.
  
   Since model classes are cached and shared, the
  model must
   accurately represent the XML specification at the
  start of
   rendering.
  
   So a way could be immutable classes
   Another way could be to return cloned copy of
  cached object
   at the start of rendering. If you do this it does
  not matter
   if anyone makes a mistake in the dozens of model
  classes
   wrt. cloned. (which many people may do over life
  of project
   because it is human to make stupid mistakes)
  
   It may also be worth asking why cache. To me
  answer is
   performance due to cost of XML parsing and
  conversion from
   XML to object model.
   Creating Flexible string expander instance
  variables in the
   model classes may also be a cost but it is not due
  to
   FlexibleStringExpander cache.
  
   Actually, there is no reason to create
  FlexibleStringExpander instances - you can call the static
  expandString method with very little performance loss.
  
   Wondering if the following proposal makes sense:
   - Generate Model Classes from XSD using something
  like
   JAXB. These would not have any flexible string
  expander
   instance variables.
   - Cache the key (resource+name) to Model for
  lookup of
   screens and forms
   - In cache lookup. Clone copy of Model root. Wrap
  the
   cloned copy with a dynamic proxy. Dynamic proxy
  also stores
   reference to context.
   - Getters from the dynamic proxy return values by
  applying
   FlexibleStringExpander.getInstance(..) on the
  value obtained
   from underlying cloned model.
   - Change Render classes to use these generated
  JAXB
   objects.
  
   That would eliminate the unmarshalling code.
  
   Advantage could be
   - Most of the handwritten code for Model Classes
  goes
   away.
  
   I don't know about most. From my perspective, the
  unmarshalling code is a small percentage of the screen
  widget code (basically just the class constructors).
  
   If we used the builder pattern, we could unmarshall
  the XML files by using a builder class that builds the model
  objects. Builder classes could build model objects from XML
  files, or from another source - like a database, a CMS, or
  another file format.
  
   - Model classes and XML specification are tied
  together and
   specified only by XSD.
   - Rendering presents a pipeline. Model classes can
  be
   modified by renderer if needed as the pipeline
  proceeds from
   start of rendering till end.
  
   The state data doesn't need to be stored in the model
  objects - it's only stored there now because the developer
  who put it there didn't know any better. It can be stored
  just as easily in the renderer. There is no need to clone
  model objects.
  
   - Dynamic proxies are small. Mostly standard
  conversion
   (apply FlexibleStringExpander::expand) but it
  could be the
   spot to add any additional behavior.
  
   thoughts ?
   Harmeet

Re: help system

2010-05-24 Thread Marc Morin

Sitting back, drinking a nice cool beer and reading the mailing list... It 
seems like there is a lot of re-work/extra-work done in the open source 
community (including ofbiz) because of a lack of cohesive licenses. I am NOT an 
expert on the open source community or the various camps (free software and all 
source code, vs commercial variants), but it is a little sad and discouraging 
when it appears like the only course for our ofbiz project is to 
do-more-proprietary technology yet another piece of technology to add to 
the ofbiz pile

Just a curious note about EPL, isn't BIRT covered by this license and it has 
found it's way into ofbiz

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- BJ Freeman bjf...@free-man.net wrote:

 http://www.eclipse.org/legal/eplfaq.php
 #14 is it a show stopper
 
 =
 BJ Freeman
 http://bjfreeman.elance.com
 Strategic Power Office with Supplier Automation
 http://www.businessesnetwork.com/automation/viewforum.php?f=93
 Specialtymarket.com http://www.specialtymarket.com/
 
 Systems Integrator-- Glad to Assist
 
 Chat  Y! messenger: bjfr33man
 Linkedin
 http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro
 
 
 chris snow sent the following on 5/24/2010 12:43 PM:
  Hi Erwan, why build a help system when the eclipse help system has
 more
  features and is very mature - see it in action here:
  http://help.eclipse.org/galileo/index.jsp?
  
  On Mon, May 24, 2010 at 7:41 PM, Erwan de FERRIERES 
  erwan.de-ferrie...@nereide.fr wrote:
  
  Le 24/05/2010 20:14, chris snow a écrit :
 
   I haven't had chance to do a deep investigation of the help system
 yet,
  but
  I have a few futher questions:
 
  1) is the main purpose of the content management records to link
 the
  current
  screen to the appropriate help content?
  2) could the help system be replaced with the eclipse help system?
  the
  eclipse help system has some nice additional functionality such as
 search?
 
  Many thanks,
 
  Chris
 
   Hi Chris,
  --
 
 http://localhost:8080/cmssite/cms/APACHE_OFBIZ_HTML#helpInternationalization
 
  for searching in the help system, we could use what is built-in
 OFBiz at
  the moment. Lucene is broken, but we should upgrade it and make it
 work
  again. Scott was telling me he had something waiting to be
 committed. Then,
  a simple search interface would have to be added so we could search
 into the
  help system.
 
  HTH,
 
  --
  Erwan de FERRIERES
  www.nereide.biz

[jira] Commented: (OFBIZ-3774) Add The Visitor Pattern To Screen Widget Model Classes

2010-05-17 Thread Marc Morin (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-3774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12868470#action_12868470
]

Marc Morin commented on OFBIZ-3774:
---

We did a similar visitor pattern to the entire presentment (Screen, Form, Menu)
space and the controller. This path, mainly separation of concern, is very
powerful, and allows easy extension to the system.

The typical implementation path that has been taken, is to develop a series of
abstract visitors that have a few base behaviors, navigation of the components,
and throwing exceptions for each component. This enables a specific visitors
to extend the base navigation class, to get full model navigation and add any
specific behavior with a surprisingly small amount of code.

We've done Presentment visitors for walking, validation (examining
location/name references looking for dangling screen/from/controller
references, etc.. used in junit test cases - fail build if broken links),
security auto-notation (propagates service security declarations, to screens
model objects, and will automatically remove buttons, links to areas in the
application that the user doesn't have rights to access.) We have a partial
dump (pretty-print) for the PresentmentModel as well.

Externalizing the creation of the model objects, is crucial to getting the full
power of this type of change. The model objects should have nothing but their
attributes with their getter/setter methods (and the accept).

Add The Visitor Pattern To Screen Widget Model Classes
--

Key: OFBIZ-3774
URL: https://issues.apache.org/jira/browse/OFBIZ-3774
Project: OFBiz
Issue Type: Improvement
Components: framework
Reporter: Adrian Crum
Priority: Minor
Attachments: OFBIZ-3774.patch

From time to time there has been interest expressed in introducing the
visitor pattern to the screen widget model classes. This issue is intended to
provide a forum on the subject and a means to vote on it. Details are in the
comments.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Screen Widget Ideas

2010-05-15 Thread Marc Morin

Pure model objects with no behavior in them, and a visitor pattern to 
externalize the behavior man, that's music to my ears!

We've added a visitor pattern to all the model objects, screens, forms, 
menus, entity,

It has proven invaluable to enable walking and manipulating the model, without 
increasing the complexity of the underlying model objects.

Also, as your specific example indicates, the renderers are a perfect use 
case for visitors, as the rendered is technically and interpreter of the model 
objects.

Marc
- Adrian Crum adrian.c...@yahoo.com wrote:

 --- On Fri, 5/14/10, Scott Gray scott.g...@hotwaxmedia.com wrote:
  On 15/05/2010, at 3:43 PM, Adrian
  Crum wrote:
 
   I've been thinking about some improvements to the
  screen widgets, and I thought I would offer some ideas and
  see if there is any interest. I'm kind of thinking out loud
  here, so the ideas are not fully developed. Please comment
  or add your suggestions.
  
   1. Use the factory pattern to create model widgets.
  Right now model widget construction is handled internally
  with a pre-defined set of classes. The idea is to move the
  model widget creation to a factory method that accepts a
  candidate XML element. If a matching model widget is found,
  return it, otherwise throw an exception. The factory
  supports user-created model widgets, so the screen widgets
  are extensible. In other words, you can create your own
  model widgets, register them with the factory, and the
  screen renderer will use them just like any other widget.
  You could even create your own replacement implentations of
  existing OFBiz screen widgets. User-created widgets can use
  namespaces on the XML side to avoid XML parsing errors.
 
  That's crazy, I've been looking into this today.  I
  had figured on using an include-widget tag.
  I was also thinking about the PITA way that we pass widget
  renderers around and wondering if we couldn't just have a
  render method on the model that takes a writer, the context
  and a content type.  The model then has an internal
  factory that gets the configured renderer based on the
  content type.
 
 At least we're basically on the same page. My perspective all along is
 that the screen widgets should be nothing more than data structures in
 memory that support the visitor pattern. Renderers implement the
 visitor interface. Implementations of the visitor interface could be
 anything: HTML renderers, Swing renderers, artifact gatherers, layout
 managers (an intermediate form of renderer), pretty printers, etc.
 
 There is so much room for improvement, but experience has shown that
 the screen widgets have become a sort of sacred cow, so changes like
 that will be met with a lot of resistance.
 
   2. Add Groovy support to the include-screen
  widget. If the location attribute ends with .groovy pass
  control to the specified Groovy script. The script would
  behave like a screen widget and it will have access to all
  model widgets - so existing widget code can still be used.
  This could help in certain cases where screen widgets can't
  fulfill a particular need. It has been suggested that CDATA
  elements be allowed in screen widgets so that free-form code
  can be inserted in widget XML - this is an alternative
  solution to that. The benefit is you can leverage the power
  of Groovy in controlling screen output. The drawback is any
  such script will break the structure of screen widgets and
  it will start to look like JSP - where data preparation code
  is mixed with presentation code.
 
  This sounds more like a custom renderer rather than
  something that should go into the model.
 
 It's not a custom renderer - the output is still the same as the
 original view. It's just a different way of looking at screen
 rendering. Instead of screen widgets calling scripts, a script calls
 screen widgets. In other words, instead of XML-generated-widgets being
 in charge of Groovy, Groovy is in charge of the XML-generated-widgets.
 Think about it.
 
 -Adrian

Re: Making the dev process work...

2010-05-15 Thread Marc Morin

For non committers, like ourselves.  You must create your own svn repository, 
with a vendor branch to the ofbiz repository.

Then create your own branch of the raw trunk, to do your own local changes.  
Package up these changes into patches, and post them back to the ofbiz 
project they may or may not be accepted.

But at least you can use your private modified version of ofbiz and it won't 
hold you up.

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Chris Snow sno...@snowconsulting.co.uk wrote:

 If there is one patch per entity, only one or two patches waiting to
 be
 committed at any one time, one month to commit each patch, that's alot
 of
 patience (100+ months)!
 
 It sounds like my options are:
 
 A) not bother doing anything
 B) setup my own local svn that is a mirror of the apache svn server
 
  Yeah, be patient. I had patches sitting in Jira for years before
 they were
  committed.
 
  -Adrian
 
 
  --- On Sat, 5/15/10, Scott Gray scott.g...@hotwaxmedia.com wrote:
 
  From: Scott Gray scott.g...@hotwaxmedia.com
  Subject: Re: Making the dev process work...
  To: dev@ofbiz.apache.org
  Date: Saturday, May 15, 2010, 1:42 AM
  No it's not possible (well
  technically it is but it's very unlikely to happen).
 
  Just be patient and they'll get committed.
 
  Regards
  Scott
 
  HotWax Media
  http://www.hotwaxmedia.com
 
  On 15/05/2010, at 6:56 PM, Chris Snow wrote:
 
   A while back, I had a small improvement committed to
  provide field tooltip
   help.
  
   I now have the time consuming process of extracting
  the tooltip help text
   from the manager references and putting it into the
  xml property files.
  
   The problem is that I have to rely on commiters to
  take my patches, review
   and commit them.  Erwan is kindly reviewing my
  patch for the ProductStore
   and will hopefully commit it at some stage. 
  However, committers have
   other priorities and getting the huge amount of
  patches that I will be
   providing to be committed is going to be very
  timeconsuming!  Contributing
   to the problem is that I don't want to spend more that
  half a day on a
   single patch - I can't aford to lose time on writing
  patches that may not
   get committed.
  
   Is it possible to give fine grained svn access, I.e.
  just to the property
   files that contain the field descriptions?
  
   Any other ideas?
  
   Many thanks,
  
  
   Chris
  
 
 
 
 
 
 
 
 
 -- 
 Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP
 
 Tel: 01453 890660
 Mob: 07944 880950
 Www: www.snowconsulting.co.uk

Re: Making the dev process work...

2010-05-15 Thread Marc Morin

As ofbiz developers, we should all be aligned in providing upstream patches 
that fix bugs, etc.. to the ofbiz project. 

It's in your interest to minimize the differences between your copy of ofbiz 
and the official one. You'll need to be clear about what is specific to 
your application vs core changes.  Core changes should be submitted.

This strategy just makes it easier for you to deal with the patch latency 
inherent in the ofbiz review-then-commit practise for non-committers.

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- chris snow chsnow...@googlemail.com wrote:

 Thanks for the tip Marc.  If I have my own svn repository, there
 doesn't
 seem to be any value to me in providing upstream patches that may not
 get
 committed?
 
 On 15 May 2010 12:16, Marc Morin m...@emforium.com wrote:
 
 For non committers, like ourselves.  You must create your own svn
 repository, with a vendor branch to the ofbiz repository.
 
 Then create your own branch of the raw trunk, to do your own local
 changes.
  Package up these changes into patches, and post them back to the
 ofbiz
 project they may or may not be accepted.
 
 But at least you can use your private modified version of ofbiz and
 it
 won't hold you up.
 
 Marc Morin
 Emforium Group Inc.
 ALL-IN Software
 519-772-6824 ext 201
 mmo...@emforium.com
 
 
 - Chris Snow sno...@snowconsulting.co.uk wrote:
 
  If there is one patch per entity, only o...

Re: Screen Widget Ideas

2010-05-15 Thread Marc Morin

Factory for creating model objects is a good idea.  Allows opportunity to 
subclass them.

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Adrian Crum adrian.c...@yahoo.com wrote:

 Marc,
 
 Do you have any thoughts on the first two ideas I proposed?
 
 -Adrian
 
 --- On Sat, 5/15/10, Marc Morin m...@emforium.com wrote:
 
  From: Marc Morin m...@emforium.com
  Subject: Re: Screen Widget Ideas
  To: dev@ofbiz.apache.org
  Date: Saturday, May 15, 2010, 4:11 AM
  Pure model objects with no behavior
  in them, and a visitor pattern to externalize the
  behavior man, that's music to my ears!
 
  We've added a visitor pattern to all the model objects,
  screens, forms, menus, entity,
 
  It has proven invaluable to enable walking and manipulating
  the model, without increasing the complexity of the
  underlying model objects.
 
  Also, as your specific example indicates, the renderers
  are a perfect use case for visitors, as the rendered is
  technically and interpreter of the model objects.
 
  Marc
  - Adrian Crum adrian.c...@yahoo.com
  wrote:
 
   --- On Fri, 5/14/10, Scott Gray scott.g...@hotwaxmedia.com
  wrote:
On 15/05/2010, at 3:43 PM, Adrian
Crum wrote:
   
 I've been thinking about some improvements
  to the
screen widgets, and I thought I would offer some
  ideas and
see if there is any interest. I'm kind of
  thinking out loud
here, so the ideas are not fully developed.
  Please comment
or add your suggestions.

 1. Use the factory pattern to create model
  widgets.
Right now model widget construction is handled
  internally
with a pre-defined set of classes. The idea is to
  move the
model widget creation to a factory method that
  accepts a
candidate XML element. If a matching model widget
  is found,
return it, otherwise throw an exception. The
  factory
supports user-created model widgets, so the
  screen widgets
are extensible. In other words, you can create
  your own
model widgets, register them with the factory,
  and the
screen renderer will use them just like any other
  widget.
You could even create your own replacement
  implentations of
existing OFBiz screen widgets. User-created
  widgets can use
namespaces on the XML side to avoid XML parsing
  errors.
   
That's crazy, I've been looking into this
  today.  I
had figured on using an include-widget tag.
I was also thinking about the PITA way that we
  pass widget
renderers around and wondering if we couldn't
  just have a
render method on the model that takes a writer,
  the context
and a content type.  The model then has an
  internal
factory that gets the configured renderer based
  on the
content type.
  
   At least we're basically on the same page. My
  perspective all along is
   that the screen widgets should be nothing more than
  data structures in
   memory that support the visitor pattern. Renderers
  implement the
   visitor interface. Implementations of the visitor
  interface could be
   anything: HTML renderers, Swing renderers, artifact
  gatherers, layout
   managers (an intermediate form of renderer), pretty
  printers, etc.
  
   There is so much room for improvement, but experience
  has shown that
   the screen widgets have become a sort of sacred cow,
  so changes like
   that will be met with a lot of resistance.
  
 2. Add Groovy support to the
  include-screen
widget. If the location attribute ends with
  .groovy pass
control to the specified Groovy script. The
  script would
behave like a screen widget and it will have
  access to all
model widgets - so existing widget code can still
  be used.
This could help in certain cases where screen
  widgets can't
fulfill a particular need. It has been suggested
  that CDATA
elements be allowed in screen widgets so that
  free-form code
can be inserted in widget XML - this is an
  alternative
solution to that. The benefit is you can leverage
  the power
of Groovy in controlling screen output. The
  drawback is any
such script will break the structure of screen
  widgets and
it will start to look like JSP - where data
  preparation code
is mixed with presentation code.
   
This sounds more like a custom renderer rather
  than
something that should go into the model.
  
   It's not a custom renderer - the output is still the
  same as the
   original view. It's just a different way of looking at
  screen
   rendering. Instead of screen widgets calling scripts,
  a script calls
   screen widgets. In other words, instead of
  XML-generated-widgets being
   in charge of Groovy, Groovy is in charge of the
  XML-generated-widgets.
   Think about it.
  
   -Adrian

Re: Screen Widget Ideas

2010-05-15 Thread Marc Morin

Google Guice seems really interesting approach to handling factories.  Anyone 
had any experience with it?

Marc
- Adrian Crum adrian.c...@yahoo.com wrote:

 Marc,
 
 Do you have any thoughts on the first two ideas I proposed?
 
 -Adrian
 
 --- On Sat, 5/15/10, Marc Morin m...@emforium.com wrote:
 
  From: Marc Morin m...@emforium.com
  Subject: Re: Screen Widget Ideas
  To: dev@ofbiz.apache.org
  Date: Saturday, May 15, 2010, 4:11 AM
  Pure model objects with no behavior
  in them, and a visitor pattern to externalize the
  behavior man, that's music to my ears!
 
  We've added a visitor pattern to all the model objects,
  screens, forms, menus, entity,
 
  It has proven invaluable to enable walking and manipulating
  the model, without increasing the complexity of the
  underlying model objects.
 
  Also, as your specific example indicates, the renderers
  are a perfect use case for visitors, as the rendered is
  technically and interpreter of the model objects.
 
  Marc
  - Adrian Crum adrian.c...@yahoo.com
  wrote:
 
   --- On Fri, 5/14/10, Scott Gray scott.g...@hotwaxmedia.com
  wrote:
On 15/05/2010, at 3:43 PM, Adrian
Crum wrote:
   
 I've been thinking about some improvements
  to the
screen widgets, and I thought I would offer some
  ideas and
see if there is any interest. I'm kind of
  thinking out loud
here, so the ideas are not fully developed.
  Please comment
or add your suggestions.

 1. Use the factory pattern to create model
  widgets.
Right now model widget construction is handled
  internally
with a pre-defined set of classes. The idea is to
  move the
model widget creation to a factory method that
  accepts a
candidate XML element. If a matching model widget
  is found,
return it, otherwise throw an exception. The
  factory
supports user-created model widgets, so the
  screen widgets
are extensible. In other words, you can create
  your own
model widgets, register them with the factory,
  and the
screen renderer will use them just like any other
  widget.
You could even create your own replacement
  implentations of
existing OFBiz screen widgets. User-created
  widgets can use
namespaces on the XML side to avoid XML parsing
  errors.
   
That's crazy, I've been looking into this
  today.  I
had figured on using an include-widget tag.
I was also thinking about the PITA way that we
  pass widget
renderers around and wondering if we couldn't
  just have a
render method on the model that takes a writer,
  the context
and a content type.  The model then has an
  internal
factory that gets the configured renderer based
  on the
content type.
  
   At least we're basically on the same page. My
  perspective all along is
   that the screen widgets should be nothing more than
  data structures in
   memory that support the visitor pattern. Renderers
  implement the
   visitor interface. Implementations of the visitor
  interface could be
   anything: HTML renderers, Swing renderers, artifact
  gatherers, layout
   managers (an intermediate form of renderer), pretty
  printers, etc.
  
   There is so much room for improvement, but experience
  has shown that
   the screen widgets have become a sort of sacred cow,
  so changes like
   that will be met with a lot of resistance.
  
 2. Add Groovy support to the
  include-screen
widget. If the location attribute ends with
  .groovy pass
control to the specified Groovy script. The
  script would
behave like a screen widget and it will have
  access to all
model widgets - so existing widget code can still
  be used.
This could help in certain cases where screen
  widgets can't
fulfill a particular need. It has been suggested
  that CDATA
elements be allowed in screen widgets so that
  free-form code
can be inserted in widget XML - this is an
  alternative
solution to that. The benefit is you can leverage
  the power
of Groovy in controlling screen output. The
  drawback is any
such script will break the structure of screen
  widgets and
it will start to look like JSP - where data
  preparation code
is mixed with presentation code.
   
This sounds more like a custom renderer rather
  than
something that should go into the model.
  
   It's not a custom renderer - the output is still the
  same as the
   original view. It's just a different way of looking at
  screen
   rendering. Instead of screen widgets calling scripts,
  a script calls
   screen widgets. In other words, instead of
  XML-generated-widgets being
   in charge of Groovy, Groovy is in charge of the
  XML-generated-widgets.
   Think about it.
  
   -Adrian

Re: Proper modeling of parameters and impact to page refresh ... (SVN 13393)

2010-04-26 Thread Marc Morin

Not sure you wanted to post this to d...@ofbiz mailing list

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Robert Morley rmor...@emforium.com wrote:

 We ran into a problem where we have now properly modeled all  
 parameters to controller requests with the parameter element; for  
 example here is a properly modeled link ...
 
  menu-item name=Items title=${uiLabelMap.Items}
  link target=ViewSalesOrder
   parameter param-name=orderId from- 
 field=parameters.orderId/
  /link
  /menu-item
 
 What ofbiz does when it attempts to render this link, is determine if 
 
 it should render it as an anchor or with a hidden form.  The  
 determining factor here is if the controller request ViewSalesOrder 
 
 has an event defined.  If it has an event, it must render as a hidden 
 
 form for security reasons.  In this case, ViewSalesOrder will call an 
 
 event to properly create and save the ShoppingCart object into the  
 session.  As a result, we now render this as a POST instead of a GET 
 
 (when the parameters were defined as query string arguments).
 
 After this happens, there may be a number of things that happen to the
  
 page that require us to do a page refresh.  This is typically done as 
 
 part of a modal box operation.  What we had done in the past was use 
 
 the document.location.href to refresh the page.  Now that these  
 navigation links are rendered as POSTs this no longer works, and a  
 number of bugs had been created around missing orderId and similar 
 
 problems as part of that refresh.
 
 Our solution right now was to fix how we do a refresh page.  I have  
 created a reloadPage javascript snippet that gets rendered on all  
 Emforium themed pages in the footer.  This uses the request to build a
  
 proper request to reload the page with the url, parameters, and  
 request method.  The modal box inclusion now uses this function  
 instead of its own location.href refreshing mechanism.  A number of  
 parameters that were setting this success function directly have been 
 
 removed in favor of this new method.
 
 This was checked in as part of revision 13393 and has resolved a few 
 
 tickets such as EMF-3403.
 
 There should be no direct developer impact.  After an svn refresh you 
 
 may be assigned tickets that were related to this problem and have now
  
 been fixed.  Please let me know if you have any questions or
 concerns.
 
 
 Robert Morley
 Senior Software Developer
 Emforium Group Inc.
 ALL-IN Software™
 519-772-6824 ext 220
 rmor...@emforium.com

Re: Use of internal direct variable access, or using accessor methods

2010-03-31 Thread Marc Morin

I generally like to use the gettor/settor exclusively,  even from within the 
class hierarchy.  Makes it consistent.
- Adrian Crum adri...@hlmksw.com wrote:

 Adam Heath wrote:
  ComparableRange has inconsistent access to the instance variables
 of
  other ComparableRanges.  There are several methods that do some
 kind
  of comparison with another range.  Sometimes, those methods call
 the
  accessor methods.  Other times, direct variable access is used.
  
  Here's my take on this issue, based on the Concurrency in Practice
  book.  If ComparableRange is final, and not meant to be extended,
 then
  always do direct access, period.  If ComparableRange is supposed to
 be
  extended by other classes, then make the instance variables
 final(to
  force extended classes to use the accessors), then the base class
  always must use the accessors.
 
 Consistency would be nice. My personal preference is to avoid making 
 classes final because a user might want to extend a class's behavior.

Re: UtilCache bugs and coverage

2010-03-22 Thread Marc Morin

We have also notice that the cache can get polluted with contents from a 
rolledback transaction!!  Also, the visibility of the objects doesn't respect 
the transaction boundaries

This has caused some problems, we haven't fixed it yet so no patch to 
contribute... sorry.

- Adam Heath doo...@brainfood.com wrote:

 David E Jones wrote:
  On Mar 22, 2010, at 11:07 AM, Adam Heath wrote:
  
  Michael Xu (xudong) wrote:
  hi Adam,
 
  Thanks for your work. Cache layer is critical for ofbiz as ERP
 system.
 
  Just one quick question: There are a lot of cache frameworks
 (Personally I
  like Apache JCS very much) out there. Why ofbiz has to have its
 own
  implement?
 
  In my opinion, we have two ways to reduce bugs. Write more test
 codes, or
  write less product codes. Maybe we can replace ofbiz components
 with some
  existing components (say cache) or separate ofbiz components as
 sub projects
  or just totally new project to attract more projects to use (say,
 entity
  engine).
  I've looked at ehcache, and have plans to convert to that
 eventually.
  First, however, is to get our code functionting correctly, with no
  bugs, and with good test cases on the existing
 interface(UtilCache),
  then the implementation underneath can be switch, while keeping
 the
  same set of test cases.
  
  I looked around a bit recently to see if there was a cache project
 that could replace the UtilCache stuff.
  
  OSCache and Ehcache both look pretty good, and Jakarta JCS looks
 okay, and of the various I read about Ehcache looks like the most
 feature-rich (especially for distributed caches and such). Ehcache
 also tracks statistics much like the OFBiz UtilCache stuff does.
  
  None of these appear to support soft-reference cache entries, but
 maybe that's not a big deal and it would be better to do size/entries
 limiting instead anyway (they all have good eviction algorithms).
  
  Are there any other cache projects that other people like?
  
  Should we deprecate the soft-reference support in order to more
 easily plugin a separate cache library?
 
 ehcache has soft-ref support.  Do a google search for 'ehcache
 softreference'
 
 Replacing UtilCache is not a good plan.  It's best to keep that
 api(with maybe a small change, if needed).  Then swap out what
 UtilCache does under the scenes, based on what we decide.  But, as I
 said, before we can do that, we need to test the current design, so
 that when/if we do change, we can know that we haven't broken
 anything
 that's already being tested.

Re: UtilCache bugs and coverage

2010-03-22 Thread Marc Morin


Or make the caching system easier to use copy on write, and 
transactional   
- Adam Heath doo...@brainfood.com wrote:

 David E Jones wrote:
  On Mar 22, 2010, at 3:03 PM, Adam Heath wrote:
  
  Marc Morin wrote:
  We have also notice that the cache can get polluted with contents
 from a rolledback transaction!!  Also, the visibility of the objects
 doesn't respect the transaction boundaries
 
  This has caused some problems, we haven't fixed it yet so no
 patch to contribute... sorry.
  Code that modifies entities should not be calling caching variants
 of
  the delegator.
  
  It shouldn't even be able to... entities from the cache should be
 set to read-only (they used to be anyway).
 
 It's not that said code is trying to modify entities that are already
 in the cache.
 
 It's that some entity is modified, then this supposed code calls a
 caching variant, so the newly created value gets stored in the cache.
 
 To make it more succinct, code that modifies database values can not
 *ever* call a delegator caching variant.
 
 Actually, how about if we modify the delegator to see if a
 transaction
 is active for the current thread, and throw an exception if a cache
 store is attempted?

Re: entity primary key change - BAD: Re: svn commit: r895250 - in /ofbiz/trunk/applications: order/entitydef/ product/entitydef/ product/script/org/ofbiz/shipment/issuance/ product/script/org/ofbiz/s

2010-03-18 Thread Marc Morin

I loath to enter into this discussion, but feel that I need to put in a bit of 
experience that I have observed when dealing with databases and migration 
issues.

There are a couple of truisms that I have come to accept, grudgingly:

1) Database schemas will change over time.
2) Database schema changes are a pain to deal with.  Migration issue are 
difficult.
3) Unlike changes in code, that have no history to them (other than an 
interface specification to external api), database changes, have a long time 
horizon.  Decisions that were rational that lead to a schema design at the 
time, but new use cases, etc.. result in re-factoring or enhancing cause you to 
continually deal with the implications of this old design.
4) It's impossible to satisfy all schema API revision constraints at the same 
time.
5) You need to have a formal way to manage migration of data in your framework.
6) Only support the newest schema, don't leave legacy artifacts around in 
schema, tends to increase duplication, increased confusion, and increased code 
entropy.
7) Avoid schema as an API point in your system if at all possible... can really 
tie your hands from a development point of view.  Means other systems will need 
to be updated when merging...

So, Ofbiz doesn't really have any formal migration process. checkdb() adds 
missing stuff, but is incomplete in some changes (column type changes, index 
changes, pkey changes, drops, null/not null changes), but more importantly, the 
data migration framework is meant to be outside, and manual... leading to 
problems, inconstancies, and more importantly, difficulties.

The rename the old entity, create a migration service, then manually run it, 
is a weak migration framework.

I have had success when trying to keep a tighter lid on things:

1- automatically create .sql migration files representing the differences in 
schemas. (revn - revn-1 differences).
2- automatically add insert/update/delete commands representing the differences 
in seed into these files.
3- manually edit these files, or generate new ones to represent migration of 
data, where the simple cases are not handled, such as moving data from one 
entity, to another, etc...
4- these sql migration commands become formally part of the codebase.  
Migration scripts automatically run on older schema versions (trick is the 
detect what version the schema actually is can't rely on version number, 
etc... too easy to be inaccurate, and run all needed migration commands).
5- Only supporting the current schema in the code base.  This means that as 
the schema evolves, code that isn't in the project will need to be upgraded 
when merging in these changes.

Obviously the above series of steps are meant to move all legacy databases 
through an upgrade process to the current revision, such that they should be 
indistinguishable from being created from a newly minted schema.

I have done this type of support in my past life, with another project, other 
than ofbiz and it helped tame the affects of schema changes.  We also have 
developed this approach at Emforium to manage the upgrade of our customer's 
ofbiz instances.  It has been VERY DIFFICULT to keep these instances consistent 
with one another, as the schema has changed over time I won't say that this 
is 100% nailed down, but we are on our way.

So, I'd be interested in discussing how we can add a more formal migration 
declaration into ofbiz, with forward and backward migrations formally put into 
place (like ruby on rails, etc...). 

We can talk about using our developed framework for this, but there are 
limitations; such as .sql files are not likely portable, and certainly can't be 
easily split up between datasources.

We've also generated a number of self tests, to test that a db at revn-1 can 
be upgraded to revn with the seed to be identical, this is CRUCIAL to ensure, 
that the migration chain is unbroken...


Marc

Re: Valid party Ids

2010-03-17 Thread Marc Morin

We use a prefix for each instance, so our id's are of the format \\d+-\d+.

So, looks like this kind of check, is a function of how your entityengine.xml 
file is configured.

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Adam Heath doo...@brainfood.com wrote:

 Scott Gray wrote:
  +1
  Commons StringUtils has a method for this check if we don't have one
 of our own.
 
 Do we really need a full on method call instead of just
 string.matches(\\d+)?
 
  Regards
  Scott
  
  HotWax Media
  http://www.hotwaxmedia.com
  
  On 17/03/2010, at 4:21 AM, Bilgin Ibryam wrote:
  
  createPerson and createPartyGroup services don't accept party Ids
 starting with a number. I wonder what is the reason for this
 restriction?
 
  I suppose it is done to prevent users from entering numbers as
 partyId which may interfere with auto generated Ids. If this is the
 case I propose to change the logic, so instead of checking only the
 first character, it checks all the characters from the Id and refuse
 it ONLY IF all the characters are numbers. WDYT?
 
  I faced this problem while trying to import data in ofbiz, where
 the Ids start with number but contains also some letters. In this case
 it is not possible to interfere with auto generated Ids but still they
 are not accepted as valid Ids.
 
  Bilgin

Re: Valid party Ids

2010-03-17 Thread Marc Morin

We configure the entityengine.xml to have sequenced-id-prefix=${instance}- 
defined on the delegator configuration section.  This causes the sequence id's 
that are generated for that delegator to have a prefix created, in our case, 
${instance} is replaced with the unique id for the tenant.  This means that 
tenant 10342 will have all it's generated keys have the form 10342-10023...

This makes it easier to take data from one tenant or db instance and move it to 
another.  We're essentially generating unique id's.

In our case, the entityengine.xml file has been extended to have templates, but 
you can easily configure a delegator in stock ofbiz to have a constant prefix 
for each delegator.

Marc Morin
Emforium Group Inc. 
ALL-IN Software
519-772-6824 ext 201 
mmo...@emforium.com 

- Bilgin Ibryam bibr...@gmail.com wrote:

 Marc Morin wrote:
  We use a prefix for each instance, so our id's are of the format
 \\d+-\d+.
 
  So, looks like this kind of check, is a function of how your
 entityengine.xml file is configured.
 
   
 Scott, I can't find the method in StringUtil, but the regex proposed
 by 
 Adam is enough.
 
 Marc, could you elaborate more on how these IDs are related to
 entityengine?
 
 Bilgin

[jira] Commented: (OFBIZ-3540) Multi-Tenant Support (Login Based)

2010-03-08 Thread Marc Morin (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842745#action_12842745
]

Marc Morin commented on OFBIZ-3540:
---

From the experience of our multi-tenant implementation, we've noticed

- multi-tenant was easy to add for the base case, as this patch indicates, the
delegator pretty much abstracted much of it away.
- we more formally, expanded the entity-engine.xml definition to define ftl
templates for the tenant databases configuration. When looking up a tenant's
db configuration, we set the hostname, username, password, tenantId, etc in a
context that is applied to generate the tenant's specific configuration. This
allows for changing the sequenced-id-prefix for each tenant, allowing easier
merging of data between tenants. We chose to use entirely different
delegatorNames, such as 1, 10001, etc directly from the
SequenceValueItem.
- The EntityCache is per delegator, and not per unique datasource, we haven't
changed this, but it essentially, prevents sharing the same datasource amongst
tenants
- Selecting the delegator/tenant is needed in different areas of the
application, via different techniques. via explicity selection, as the login
demo application here, but we've also need to associate the hostname of the
HTTP request, to enable multiple entire instances, both authenticated and not,
to be distinguishable.
- The dispatcher will create a seperate job manager for each tenant. This is
fine for a small number of tenants, but with a larger number, a single
JobPoller/Manager is required. We've added these enhancements and additional
tenantId field on the JobSandbox. We interpret, null in tenantId, here to
mean, replicate this job to run all all tenant instances. Think of all the
cleanup jobs, etc...
- Singleton JobManager also handles scheduling of jobs for tenants that haven't
been loaded... The current mechanism will not load the tenant, until someone
logs in that instance.
- The life cycle, create, upgrade, decommission of the tenants is a non trivial
amount of work. We've spent a large amount of effort here, to keep the support
cost down for 1000's of tenants in a system. Creating a new tenant from a
blank template, applying upgrade sql files, etc...
- Since our service is a subscription, we modeled the tenant instance as a
Product in our master instance. We use the Subscription product behavior to
help control the expiration, etc.. of the tenant.

Many of these changes are in our forked version of the code. We can try to
extract components that people feel would be beneficial if there is interest.

Multi-Tenant Support (Login Based)
--

Key: OFBIZ-3540
URL: https://issues.apache.org/jira/browse/OFBIZ-3540
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: David E. Jones
Assignee: David E. Jones
Priority: Minor
Fix For: SVN trunk

Attachments: MultiTenant20100305.patch, MultiTenant20100305.patch,
MultiTenant20100305.patch

Support multiple tenants in a single instance of OFBiz. Each tenant will have
its own databases (one for each entity group). Database settings will
override the settings on the delegator with parameters from an entity record
so that new tenants can be added on the fly without restarting the server
(new tenants will still need to have data loaded in their databases just like
any other).
If valid Tenant ID is specified when user logs in then webapp context will be
setup with tools for that tenant as a variation of the base delegator
(including delegator, dispatcher, security, authz, visit, server hit, etc
handled for it).
Demo data includes a couple of sample tenants. After loading demo data (ant
run-install) try logging in to webtools or any other admin app with the
Tenant ID of DEMO1.
NOTE: this patch also addresses some stability issues with the LoginWorker,
ControlServlet, Visit, and ServerHit functionality that was exposed while
developing this. For example, after a logout functionality that runs in the
ControlServlet may fail because things that were in the session before are
not there any more. In this patch there is code to rebuild the request and
session after logout (necessary for changing tenants, helpful for these other
issues).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-2974) JobManager.reloadCrashedJobs fails to reload crashed jobs

2010-01-11 Thread Marc Morin (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12798650#action_12798650
 ] 

Marc Morin commented on OFBIZ-2974:
---

Has anyone else run into this?  Seems like this is a core problem in the 
framework.

 JobManager.reloadCrashedJobs fails to reload crashed jobs
 -

 Key: OFBIZ-2974
 URL: https://issues.apache.org/jira/browse/OFBIZ-2974
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Priority: Critical

 The JobManager.reloadCrashedJobs() method fails to reload most crashed jobs 
 each time it is run, this occurs for two reasons:
 1.  The method only supports reloading jobs that have a related 
 RecurrenceInfo, if it has no recurrence information or if it uses the newer 
 temporal expressions then the job is passed over and not reloaded
 2.  If the job does have a related RecurrenceInfo then the method checks to 
 see if the next recurrence from now is less than the runTime of the crashed 
 job, this is almost never the case so once again the job isn't reloaded.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Delegator rollback per test case?

2009-12-24 Thread Marc Morin

W make extensive use of the rollback pre test case paradigm for our proprietary 
application. It is invaluable.  The test cases may run a little slower than if 
the setup/rollback was performed per suite, but the inter-testcase dependancies 
would be a nightmare for us to manage.

- Original Message -
From: Scott Gray scott.g...@hotwaxmedia.com
To: dev@ofbiz.apache.org
Sent: Thursday, December 24, 2009 3:14:26 AM GMT -05:00 US/Canada Eastern
Subject: Re: Delegator rollback per test case?

I'd really rather not have this idea die with a single response, I've  
done my best to describe the perceived benefits and it would be good  
to get some additional feedback from anyone who is interested.

Thanks
Scott

On 13/12/2009, at 8:20 PM, Scott Gray wrote:

 My intention was generally to have one test suite per sub-package  
 e.g. one for org.ofbiz.accounting.finaccount, one for  
 org.ofbiz.accounting.fixedasset, etc.

 Lets say I want to run 50 different order processing tests,  
 cancellations, edits, authorizations, packing, etc.  To do this I  
 have to either create 50 different demo orders which is time  
 consuming or I have to split them up into different test suites  
 which will quickly leave us with a huge number of test suites all  
 doing very similar things.

 Aside from the above there are a few other things I don't like about  
 having only one rollback per test suite:
 - When adding a new test case to a suite you have no idea what state  
 the database will be in unless you inspect all of the other test  
 cases in the suite and understand what they are doing.
 - It makes test cases more difficult to maintain because you have no  
 idea where the dependencies are within a suite.  With the change I'm  
 suggesting you would need to be explicit about dependancies by  
 putting the cases in a test group.
 - If you make some application code or demo data changes and 10 test  
 cases in a suite start failing you have no idea if it's because a  
 single case is failing and the others depend on it or because your  
 changes are causing wide spread problems.  Knowing the dependancies  
 helps the developer to understand how big the problem is before they  
 go through and examine every failed case.

 Ultimately my only goal here is to make writing tests easier, I'm  
 not approaching it with any idealistic this is how tests should be  
 conducted mentality.  The easier we can make it, the more likely it  
 is that people will actually write them.

 I'm unclear about something in your message though: are you saying  
 you are doing it below and it's not meeting your needs, or that you  
 would like to be able to do it as below?

 I'm not sure what you mean, what I'm suggesting below isn't  
 currently possible.  The test-group tag actually does nothing at the  
 moment (other than add the child test cases to the suite, which is  
 the same as not having it at all).

 Regards
 Scott

 On 13/12/2009, at 3:44 PM, David E Jones wrote:

 My preference would still be to have one roll-back per test-suite,  
 which basically means one transaction per XML file. If you want the  
 tests to use the same data then put them in the same file. If you  
 want them to use different data, then they go in their own files.

 I'm unclear about something in your message though: are you saying  
 you are doing it below and it's not meeting your needs, or that you  
 would like to be able to do it as below?

 -David

 On Dec 11, 2009, at 3:54 AM, Scott Gray wrote:

 We've had this discussion before, here is last one I could find: 
 http://markmail.org/message/ftvs45vnzlobo7hb

 The solution I would like to propose for the problem David  
 described is for us to make more use of the test-group child  
 element of test-suite and have tests within those groups rollback  
 as a group, for all other test cases we'd roll them back as soon  
 as they complete.  Here's an example of what I'm talking about  
 since that description probably did nothing for you:

 test-suite

 test-case/
 !-- Rollback here --
 test-case/
 !-- Rollback here --
 test-case/
 !-- Rollback here --

 !-- No rollbacks inside the test group --
 test-group
  test-case/
  test-case/
 /test-group
 !-- Rollback here --

 /test-suite

 A common problem I'm seeing is that we want to run multiple tests  
 on the same piece of demo data but can't because the previous test  
 has already altered it.  An example might be where you want to try  
 shipping a single order in various different splits but you can't  
 do that at the moment without having a separate demo order for  
 each test.

 Thoughts?

 Thanks
 Scott

 HotWax Media
 http://www.hotwaxmedia.com

[jira] Commented: (OFBIZ-3157) application - accounting

2009-12-17 Thread Marc Morin (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791957#action_12791957
 ] 

Marc Morin commented on OFBIZ-3157:
---

jacques,

I have been overwhelmed with other work will eventually get to it, not sure 
when though :-(

Marc Morin
Emforium Group Inc. 
ALL-IN Software™ 
519-772-6824 ext 201 
mmo...@emforium.com 





 application - accounting
 

 Key: OFBIZ-3157
 URL: https://issues.apache.org/jira/browse/OFBIZ-3157
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
Assignee: Jacques Le Roux
 Fix For: SVN trunk

 Attachments: OFBIZ-3157.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-3157) application - accounting

2009-11-19 Thread Marc Morin (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12780190#action_12780190
 ] 

Marc Morin commented on OFBIZ-3157:
---

I've tried the application/content a couple of times.   There appears to be 
bugs in there, where what is put into the maps/lists isn't what is 
extracted.  I'll file a jira to fix the bug first, before the code cleanup.

Marc Morin
Emforium Group Inc. 
ALL-IN Software™ 
519-772-6824 ext 201 
mmo...@emforium.com 





 application - accounting
 

 Key: OFBIZ-3157
 URL: https://issues.apache.org/jira/browse/OFBIZ-3157
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
Assignee: Jacques Le Roux
 Fix For: SVN trunk

 Attachments: OFBIZ-3157.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3107) framework - entity

2009-11-17 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3107:
--

Attachment: OFBIZ-3107-take2.patch

redone to adjust for changes since last created

 framework - entity
 --

 Key: OFBIZ-3107
 URL: https://issues.apache.org/jira/browse/OFBIZ-3107
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3107-take2.patch, OFBIZ-3107.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-3105) framework - common

2009-11-15 Thread Marc Morin (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778090#action_12778090
 ] 

Marc Morin commented on OFBIZ-3105:
---

there are no warnings in this area

 framework - common
 --

 Key: OFBIZ-3105
 URL: https://issues.apache.org/jira/browse/OFBIZ-3105
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OFBIZ-3110) framework - exampleext

2009-11-15 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin closed OFBIZ-3110.
-

Resolution: Invalid

There were no warnings in this area

 framework - exampleext
 --

 Key: OFBIZ-3110
 URL: https://issues.apache.org/jira/browse/OFBIZ-3110
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OFBIZ-3113) framework - images

2009-11-15 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin closed OFBIZ-3113.
-

Resolution: Invalid

no warnings in this area

 framework - images
 --

 Key: OFBIZ-3113
 URL: https://issues.apache.org/jira/browse/OFBIZ-3113
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3157) application - accounting

2009-11-04 Thread Marc Morin (JIRA)

application - accounting


 Key: OFBIZ-3157
 URL: https://issues.apache.org/jira/browse/OFBIZ-3157
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3157) application - accounting

2009-11-04 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3157:
--

Attachment: OFBIZ-3157.patch

patch for generic's warnings for accounting application

 application - accounting
 

 Key: OFBIZ-3157
 URL: https://issues.apache.org/jira/browse/OFBIZ-3157
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3157.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3120) framework - webapp

2009-11-03 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3120:
--

Attachment: OFBIZ-3120.patch

 framework - webapp
 --

 Key: OFBIZ-3120
 URL: https://issues.apache.org/jira/browse/OFBIZ-3120
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3120.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3107) framework - entity

2009-11-03 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3107:
--

Attachment: OFBIZ-3107.patch

entity patch.  This was a more difficult one because of the partially 
parameterized generics in the condition evaluation.  

 framework - entity
 --

 Key: OFBIZ-3107
 URL: https://issues.apache.org/jira/browse/OFBIZ-3107
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3107.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3121) framework - webslinger

2009-11-03 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3121:
--

Attachment: OFBIZ-3121.patch

 framework - webslinger
 --

 Key: OFBIZ-3121
 URL: https://issues.apache.org/jira/browse/OFBIZ-3121
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3121.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-3100) Resolve java warnings exposed in Eclipse

2009-11-03 Thread Marc Morin (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773335#action_12773335
 ] 

Marc Morin commented on OFBIZ-3100:
---

Once we apply the patch for framework/entity.  Likely a number of warnings 
using EntityCondition.makeCondition() will go away... or we'll likely need to 
do a second pass.

Once we get the framework area patched, I will be happy to proceed into the 
other areas.

 Resolve java warnings exposed in Eclipse
 

 Key: OFBIZ-3100
 URL: https://issues.apache.org/jira/browse/OFBIZ-3100
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: SVN trunk
Reporter: Bob Morley

 There are over 9000 warnings reported when you do a build in Eclipse.  Let's 
 clean them up!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3117) framework - service

2009-10-29 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3117:
--

Attachment: OFBIZ-3117.patch

 framework - service
 ---

 Key: OFBIZ-3117
 URL: https://issues.apache.org/jira/browse/OFBIZ-3117
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3117.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3118) framework - start

2009-10-29 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3118:
--

Attachment: OFBIZ-3118.patch

 framework - start
 -

 Key: OFBIZ-3118
 URL: https://issues.apache.org/jira/browse/OFBIZ-3118
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3118.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3119) framework - testtools

2009-10-29 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3119:
--

Attachment: OFBIZ-3119.patch

 framework - testtools
 -

 Key: OFBIZ-3119
 URL: https://issues.apache.org/jira/browse/OFBIZ-3119
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3119.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Apache OFBiz EZBiz

2009-10-29 Thread Marc Morin

As many of you know, we at Emforium have been busy building out a full set of 
business software application to provide an ALL-IN comprehensive solution for 
the small business market.  When we started the evaluation over a year ago, 
Ofbiz was the selected platform of choice.  Other components are Zimbra for 
email and concrete5 for web.

Over this time, we've spent our efforts providing an entirely new UI front end 
for the backend applications: sales order, inventory, CRM, admin, reports, 
multi tenancy, published datasets (makes solution targeted for any market or 
geography), etc...

We have expressed privately that Ofbiz needs to have a new mission in order to 
really drive it's importance and relevance as an open source project.  As it 
stands, it's scope is very wide, and not targeted a providing and out-of-the 
box solution to any problem, save ecommerce (even then, lot's of styling work 
usually needed).

We would be 100% behind this direction for Ofbiz.  We'd want to contribute back 
components now that are Emforium proprietary and would work to reduce the 
amount of deviation between our proprietary solution and this newly stated 
direction.

Marc

[jira] Commented: (OFBIZ-3100) Resolve java warnings exposed in Eclipse

2009-10-29 Thread Marc Morin (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771477#action_12771477
 ] 

Marc Morin commented on OFBIZ-3100:
---

I just formatted using the built in Eclipse feature, haven't set it up any 
differently.  This likely points to needing to have a common Eclipse code style 
 error/warning profile as well.  

 Resolve java warnings exposed in Eclipse
 

 Key: OFBIZ-3100
 URL: https://issues.apache.org/jira/browse/OFBIZ-3100
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: SVN trunk
Reporter: Bob Morley

 There are over 9000 warnings reported when you do a build in Eclipse.  Let's 
 clean them up!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-3102) framework - base

2009-10-29 Thread Marc Morin (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771529#action_12771529
 ] 

Marc Morin commented on OFBIZ-3102:
---

Generally, we should strive to have no @SuppressWarnings(unchecked) in the 
code at all.  Ideally, only in 1 or two spots in UtilGenerics where you just 
can't get around Java generics issues like the following:

ListMyClass mymethod(ListInput list) {

return (ListMyClass) list;
}

The compiler cannot check the generic type at compile time and will not check 
at run-time. It will generate a compiler warning.  To now have it show up, you 
can @SuppressWarnings(unchecked) on the method.

For the normal case in the code, we want to encourage the proper use of 
generics. An example, which is the bulk of the type of code we're modifying is 
a hold over of pre-Java 1.5 (I think that's when Generics were introduced).

Map myMethod(Map values) {

Map newMap = new FastMap(values);
   newMap.put(this, that);
   return newMap;
}

This will result in warnings related to the generics.  You can make them go 
away with a big old @SuppressWarnings(unchecked)  on the method, but that 
isn't as desirable as

MapString, String myMethod(MapString, String values) {
MapString, String newMap = new FastMapString, String)(values);
   newMap.put(this, that);
   return newMap;
}

 framework - base
 

 Key: OFBIZ-3102
 URL: https://issues.apache.org/jira/browse/OFBIZ-3102
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3102 base warning.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-3102) framework - base

2009-10-29 Thread Marc Morin (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771530#action_12771530
 ] 

Marc Morin commented on OFBIZ-3102:
---

Agree that the choice of the generic placeholder (X, E, T, ) should be 
closest to what the user of the class/function would expect.

In java.util, you see a lot of E, since Collections, Lists, etc work on 
elements.  E being a good choice for that.

I was sloppy and just picked X, which I have historically used for I don't 
know what this is placeholder.

I'll improve the choice going forward on a case by case basis.

 framework - base
 

 Key: OFBIZ-3102
 URL: https://issues.apache.org/jira/browse/OFBIZ-3102
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3102 base warning.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OFBIZ-3102) framework - base

2009-10-28 Thread Marc Morin (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771212#action_12771212
 ] 

Marc Morin commented on OFBIZ-3102:
---

I'll tackle this an put the patch up

 framework - base
 

 Key: OFBIZ-3102
 URL: https://issues.apache.org/jira/browse/OFBIZ-3102
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3102) framework - base

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3102:
--

Attachment: OFBIZ-3102 base warning.patch

Patch to remove warnings in framework/base

 framework - base
 

 Key: OFBIZ-3102
 URL: https://issues.apache.org/jira/browse/OFBIZ-3102
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3102 base warning.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3101) framework - appserver

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3101:
--

Attachment: OFBIZ-3101.patch

patches to removed warnings

 framework - appserver
 -

 Key: OFBIZ-3101
 URL: https://issues.apache.org/jira/browse/OFBIZ-3101
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3101.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3103) framework - bi

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3103:
--

Attachment: OFBIZ-3103.patch

 framework - bi
 --

 Key: OFBIZ-3103
 URL: https://issues.apache.org/jira/browse/OFBIZ-3103
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3103.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3104) framework - catalina

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3104:
--

Attachment: OFBIZ-3104.patch

 framework - catalina
 

 Key: OFBIZ-3104
 URL: https://issues.apache.org/jira/browse/OFBIZ-3104
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3104.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3110) framework - entityext

2009-10-28 Thread Marc Morin (JIRA)

framework - entityext
-

 Key: OFBIZ-3110
 URL: https://issues.apache.org/jira/browse/OFBIZ-3110
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3110) framework - exampleext

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3110:
--

Summary: framework - exampleext  (was: framework - entityext)

 framework - exampleext
 --

 Key: OFBIZ-3110
 URL: https://issues.apache.org/jira/browse/OFBIZ-3110
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3109) framwork - example

2009-10-28 Thread Marc Morin (JIRA)

framwork - example
--

 Key: OFBIZ-3109
 URL: https://issues.apache.org/jira/browse/OFBIZ-3109
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3111) framework - geronimo

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3111:
--

Summary: framework - geronimo  (was: geronimo)

 framework - geronimo
 

 Key: OFBIZ-3111
 URL: https://issues.apache.org/jira/browse/OFBIZ-3111
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3113) framework - images

2009-10-28 Thread Marc Morin (JIRA)

framework - images
--

 Key: OFBIZ-3113
 URL: https://issues.apache.org/jira/browse/OFBIZ-3113
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3114) framework - jetty

2009-10-28 Thread Marc Morin (JIRA)

framework - jetty
-

 Key: OFBIZ-3114
 URL: https://issues.apache.org/jira/browse/OFBIZ-3114
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3111) geronimo

2009-10-28 Thread Marc Morin (JIRA)

geronimo


 Key: OFBIZ-3111
 URL: https://issues.apache.org/jira/browse/OFBIZ-3111
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3118) framework - start

2009-10-28 Thread Marc Morin (JIRA)

framework - start
-

 Key: OFBIZ-3118
 URL: https://issues.apache.org/jira/browse/OFBIZ-3118
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3116) framework - security

2009-10-28 Thread Marc Morin (JIRA)

framework - security


 Key: OFBIZ-3116
 URL: https://issues.apache.org/jira/browse/OFBIZ-3116
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3115) framework - minilang

2009-10-28 Thread Marc Morin (JIRA)

framework - minilang


 Key: OFBIZ-3115
 URL: https://issues.apache.org/jira/browse/OFBIZ-3115
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3117) framework - service

2009-10-28 Thread Marc Morin (JIRA)

framework - service
---

 Key: OFBIZ-3117
 URL: https://issues.apache.org/jira/browse/OFBIZ-3117
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3120) framework - webapp

2009-10-28 Thread Marc Morin (JIRA)

framework - webapp
--

 Key: OFBIZ-3120
 URL: https://issues.apache.org/jira/browse/OFBIZ-3120
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3119) framework - testtools

2009-10-28 Thread Marc Morin (JIRA)

framework - testtools
-

 Key: OFBIZ-3119
 URL: https://issues.apache.org/jira/browse/OFBIZ-3119
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3123) framework -widget

2009-10-28 Thread Marc Morin (JIRA)

framework -widget
-

 Key: OFBIZ-3123
 URL: https://issues.apache.org/jira/browse/OFBIZ-3123
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-3122) framework - webtools

2009-10-28 Thread Marc Morin (JIRA)

framework - webtools


 Key: OFBIZ-3122
 URL: https://issues.apache.org/jira/browse/OFBIZ-3122
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3123) framework -widget

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3123:
--

Attachment: OFBIZ-3123.patch

 framework -widget
 -

 Key: OFBIZ-3123
 URL: https://issues.apache.org/jira/browse/OFBIZ-3123
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3123.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3106) framework - datafile

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3106:
--

Attachment: OFBIZ-3106.patch

 framework - datafile
 

 Key: OFBIZ-3106
 URL: https://issues.apache.org/jira/browse/OFBIZ-3106
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3106.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3109) framework - exampleext

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3109:
--

Summary: framework - exampleext  (was: framwork - example)

 framework - exampleext
 --

 Key: OFBIZ-3109
 URL: https://issues.apache.org/jira/browse/OFBIZ-3109
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3108) framework - entityext

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3108:
--

Attachment: OFBIZ-3108.patch

 framework - entityext
 -

 Key: OFBIZ-3108
 URL: https://issues.apache.org/jira/browse/OFBIZ-3108
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: SVN trunk
Reporter: Bob Morley
 Attachments: OFBIZ-3108.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3109) framework - example

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3109:
--

Summary: framework - example  (was: framework - exampleext)

 framework - example
 ---

 Key: OFBIZ-3109
 URL: https://issues.apache.org/jira/browse/OFBIZ-3109
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3109) framework - example

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3109:
--

Attachment: OFBIZ-3109.patch

 framework - example
 ---

 Key: OFBIZ-3109
 URL: https://issues.apache.org/jira/browse/OFBIZ-3109
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3109.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3111) framework - geronimo

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3111:
--

Attachment: OFBIZ-3111.patch

 framework - geronimo
 

 Key: OFBIZ-3111
 URL: https://issues.apache.org/jira/browse/OFBIZ-3111
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3111.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OFBIZ-3114) framework - jetty

2009-10-28 Thread Marc Morin (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Morin updated OFBIZ-3114:
--

Attachment: OFBIZ-3114.patch

 framework - jetty
 -

 Key: OFBIZ-3114
 URL: https://issues.apache.org/jira/browse/OFBIZ-3114
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Marc Morin
 Attachments: OFBIZ-3114.patch




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OFBIZ-2766) Multi-tenant support

2009-07-28 Thread Marc Morin (JIRA)

Multi-tenant support


 Key: OFBIZ-2766
 URL: https://issues.apache.org/jira/browse/OFBIZ-2766
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Reporter: Marc Morin


Ability to run multiple instances of an ofbiz deployment within the same VM to 
enable increased resource utilization.

There are a number of cases, depending upon how independent the tenants are 
from one another.  In our particular case, we need to deploy a large number of 
tenants, all running the same application suite built on top of ofbiz.  This 
means that they share all .properties, .xml, .ftl files and their only private 
data is maintained by private databases.

Requirements are separate database for each tenant, but possible some shared 
entities.  (want to maintain ability to have tenants have direct jdbc/odbc 
access to their database).  UserLogin space is seperate for each tenant.

Tenant selection is via hostname and/or url and maintained in session.

An application needs to be developed to manage the life cycle of the tenants.  

We have an implementation of this type of deployment.  It would take some work 
to extract it from our application in order to develop a generic feature set.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

89 matches

Mail list logo