Re: Doubt about GL Account classes for long term assets
Thank you Adrian, your comment has really helped me. I have implemented a slightly different solution in rev. 898710 Kind regards, Jacopo On Jan 12, 2010, at 6:52 PM, Adrian Crum wrote: > Jacopo, > > According to our accountant you would want to do this (inline): > > > Jacopo Cappellato wrote: >> I have a question about the GL account classes loaded with OFBiz seed data: >>DEBIT >>|___> NON_POSTING >>| >>|___> DISTRIBUTION >>| |___> RETURN_OF_CAPITAL >>| | >>| |___> DIVIDEND >>| >>|___> ASSET >>| |_> LONGTERM_ASSET >>| | |> ACCUM_DEPRECIATION >>| | | >>| | |> ACCUM_AMORTIZATION >>| | >>| |_> CURRENT_ASSET >>| |> CASH_EQUIVALENT >>| | >>| |> INVENTORY_ASSET >>| >>|___> EXPENSE >> |_> CASH_EXPENSE >> | |> INTEREST_EXPENSE >> | | >> | |> COGS_EXPENSE >> | | >> | |> SGA_EXPENSE >> | >> |_> NON_CASH_EXPENSE >> |> DEPRECIATION >> | >> |> AMORTIZATION >> | >> |> INVENTORY_ADJUST >>CREDIT >>|___> REVENUE >>| >>|___> INCOME >>| |___> CASH_INCOME >>| | >>| |___> NON_CASH_INCOME >>| >>|___> EQUITY >>| |_> OWNERS_EQUITY >>| | >>| |_> RETAINED_EARNINGS >>| >>|___> LIABILITY >> |_> CURRENT_LIABILITY >> | >> |_> LONGTERM_LIABILITY >>|___> CONTRA-ASSET >> |_> CURRENT_ASSET >> | >> |_> LONGTERM_ASSET >>RESOURCE > > Depreciation should go in the contra-asset accounts. So, you take a bean out > of the asset bowl and put it in the contra-asset bowl. > > -Adrian
[jira] Assigned: (OFBIZ-3408) Party component has dependancy with webPos
[ https://issues.apache.org/jira/browse/OFBIZ-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwan de FERRIERES reassigned OFBIZ-3408: - Assignee: Erwan de FERRIERES > Party component has dependancy with webPos > -- > > Key: OFBIZ-3408 > URL: https://issues.apache.org/jira/browse/OFBIZ-3408 > Project: OFBiz > Issue Type: Bug > Components: party >Affects Versions: SVN trunk >Reporter: nicolas malin >Assignee: Erwan de FERRIERES > Fix For: SVN trunk > > Attachments: OFBIZ-3408_CommonScreens.patch > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > CommonPartyDecorator calls in its uiLabelMap WebPos and ProjectMgr. If you > disabled one, party's screens are broken. > WebPos and ProjectMgr are specialpurpose compenents and an application can't > have dependancies with secondary components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3408) Party component has dependancy with webPos
[ https://issues.apache.org/jira/browse/OFBIZ-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwan de FERRIERES closed OFBIZ-3408. - Resolution: Fixed Commited at rev. 898725 Thanks Nicolas. > Party component has dependancy with webPos > -- > > Key: OFBIZ-3408 > URL: https://issues.apache.org/jira/browse/OFBIZ-3408 > Project: OFBiz > Issue Type: Bug > Components: party >Affects Versions: SVN trunk >Reporter: nicolas malin >Assignee: Erwan de FERRIERES > Fix For: SVN trunk > > Attachments: OFBIZ-3408_CommonScreens.patch > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > CommonPartyDecorator calls in its uiLabelMap WebPos and ProjectMgr. If you > disabled one, party's screens are broken. > WebPos and ProjectMgr are specialpurpose compenents and an application can't > have dependancies with secondary components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Screen Widget screenlet and the hard coded br class="clear"
I think that is kind of the point Adrian. Many screens are fragile because they have been hacked together with tags, inline styles, etc, not in spite of that fact. We should remove these everywhere they are found and replace them with proper markup that is more stable and more flexible. You can just as easily clear the floated element with the element underneath or use any number CSS solutions that will make the element clear itself without any additional empty tags. In the Bizznesstime Theme, this is already built in. If you want an element to clear itself, just give it a clear name of "clearfix". At the very least, we should replace the tag with a tag. At least then we are using better markup. Line breaks should be used in text, as they are intended, not for layout. Sorry for the soapbox, but as the lone wolf front-end developer on this list sometimes, I feel like I need to speak up when there is something I feel strongly about. Ryan Foster HotWax Media 801.671.0769 ryan.fos...@hotwaxmedia.com On Jan 12, 2010, at 11:28 PM, Adrian Crum wrote: > I disagree. The stuff we have doesn't work just fine. Try removing the > clearing element and see what happens. The multi-column layout you're working > on looks great, but now everything else is broken. > > Our existing multi-column layout is extremely fragile and easily broken. > That's why I suggested the column widgets. It's a bigger issue than dragging > columns or changing sizes. > > -Adrian > > --- On Tue, 1/12/10, David E Jones wrote: > >> From: David E Jones >> Subject: Re: Screen Widget screenlet and the hard coded br class="clear" >> To: dev@ofbiz.apache.org >> Date: Tuesday, January 12, 2010, 10:20 PM >> >> The point isn't to accommodate multi-column layouts, we >> already have basic stuff for that which works just fine. I'm >> not talking about anything like dragging columns or >> configuring sizes or anything like that. It's an interesting >> idea, but a different one. >> >> The question I have is do we really want this > class="clear"/> tag always inserted when you use the >> screen widget screenlet element? >> >> Right now there is a bit of a "hack" in place to cause this >> tag to do nothing, and that is by wrapping the screenlet in >> a container with a style of "no-clear". >> >> So, the point is that is seems like in most cases this >> clear isn't needed and we can avoid the no-clear hack by >> having something explicit when it is needed. >> >> -David >> >> >> On Jan 13, 2010, at 12:13 AM, Adrian Crum wrote: >> >>> We had a discussion about accommodating multi-column >> layouts. Search the dev list for Subject = "Discussion: >> Column Widgets (was: How to add a splitter to adjust the >> left column width by dragging it?" >>> >>> -Adrian >>> >>> --- On Tue, 1/12/10, David E Jones >> wrote: >>> From: David E Jones Subject: Screen Widget screenlet and the hard >> coded br class="clear" To: dev@ofbiz.apache.org Date: Tuesday, January 12, 2010, 10:07 PM I am looking into an issue with formatting using >> a CSS-based multiple column layout and with >> screenlets in each column. The problem is that in the >> htmlScreenMacroLibrary.ftl file there is a hard-coded clear on line 148: With most browsers these clears are no >> context-sensitive, they clear ALL floats. This means that it messes >> up the multi-column formatting. Would anyone be too disappointed if we removed >> this, and if you need a clear below your screenlet then just >> use a container element after the screenlet element in >> your screen definition? Also, does anyone know the reason this was put >> there in the first place? Can anyone think of any issues removing this might >> cause? -David >>> >>> >>> >> >> > > >
Re: Screen Widget screenlet and the hard coded br class="clear"
Please don't apologize for chiming in - we need everyone to participate in the discussion. Maybe you could create a list of suggestions and the rest of the community can work on implementing them. -Adrian Ryan Foster wrote: I think that is kind of the point Adrian. Many screens are fragile because they have been hacked together with tags, inline styles, etc, not in spite of that fact. We should remove these everywhere they are found and replace them with proper markup that is more stable and more flexible. You can just as easily clear the floated element with the element underneath or use any number CSS solutions that will make the element clear itself without any additional empty tags. In the Bizznesstime Theme, this is already built in. If you want an element to clear itself, just give it a clear name of "clearfix". At the very least, we should replace the tag with a tag. At least then we are using better markup. Line breaks should be used in text, as they are intended, not for layout. Sorry for the soapbox, but as the lone wolf front-end developer on this list sometimes, I feel like I need to speak up when there is something I feel strongly about. Ryan Foster HotWax Media 801.671.0769 ryan.fos...@hotwaxmedia.com On Jan 12, 2010, at 11:28 PM, Adrian Crum wrote: I disagree. The stuff we have doesn't work just fine. Try removing the clearing element and see what happens. The multi-column layout you're working on looks great, but now everything else is broken. Our existing multi-column layout is extremely fragile and easily broken. That's why I suggested the column widgets. It's a bigger issue than dragging columns or changing sizes. -Adrian --- On Tue, 1/12/10, David E Jones wrote: From: David E Jones Subject: Re: Screen Widget screenlet and the hard coded br class="clear" To: dev@ofbiz.apache.org Date: Tuesday, January 12, 2010, 10:20 PM The point isn't to accommodate multi-column layouts, we already have basic stuff for that which works just fine. I'm not talking about anything like dragging columns or configuring sizes or anything like that. It's an interesting idea, but a different one. The question I have is do we really want this tag always inserted when you use the screen widget screenlet element? Right now there is a bit of a "hack" in place to cause this tag to do nothing, and that is by wrapping the screenlet in a container with a style of "no-clear". So, the point is that is seems like in most cases this clear isn't needed and we can avoid the no-clear hack by having something explicit when it is needed. -David On Jan 13, 2010, at 12:13 AM, Adrian Crum wrote: We had a discussion about accommodating multi-column layouts. Search the dev list for Subject = "Discussion: Column Widgets (was: How to add a splitter to adjust the left column width by dragging it?" -Adrian --- On Tue, 1/12/10, David E Jones wrote: From: David E Jones Subject: Screen Widget screenlet and the hard coded br class="clear" To: dev@ofbiz.apache.org Date: Tuesday, January 12, 2010, 10:07 PM I am looking into an issue with formatting using a CSS-based multiple column layout and with screenlets in each column. The problem is that in the htmlScreenMacroLibrary.ftl file there is a hard-coded clear on line 148: With most browsers these clears are no context-sensitive, they clear ALL floats. This means that it messes up the multi-column formatting. Would anyone be too disappointed if we removed this, and if you need a clear below your screenlet then just use a container element after the screenlet element in your screen definition? Also, does anyone know the reason this was put there in the first place? Can anyone think of any issues removing this might cause? -David
Re: svn commit: r898965 - in /ofbiz/branches/executioncontext20091231: ./ framework/api/src/org/ofbiz/api/context/ framework/context/src/org/ofbiz/context/ framework/example/data/ themes/bizznesstime/
adri...@apache.org wrote:
> Author: adrianc
> Date: Wed Jan 13 22:06:46 2010
> New Revision: 898965
>
> URL: http://svn.apache.org/viewvc?rev=898965&view=rev
> Log:
> Implemented permission filters. Added a user group to the Example component.
> Main navigation is controlled by the new security design.
>
> Added:
>
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
>(with props)
> Modified:
> ofbiz/branches/executioncontext20091231/BranchReadMe.txt
>
> ofbiz/branches/executioncontext20091231/framework/api/src/org/ofbiz/api/context/ThreadContext.java
>
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/AccessControllerImpl.java
>
> ofbiz/branches/executioncontext20091231/framework/example/data/ExampleSecurityData.xml
>
> ofbiz/branches/executioncontext20091231/themes/bizznesstime/includes/appbar.ftl
>
> ofbiz/branches/executioncontext20091231/themes/bizznesstime/includes/secondary-appbar.ftl
>
> ofbiz/branches/executioncontext20091231/themes/bluelight/includes/appbarOpen.ftl
>
> ofbiz/branches/executioncontext20091231/themes/droppingcrumbs/includes/appbarOpen.ftl
>
> ofbiz/branches/executioncontext20091231/themes/flatgrey/includes/appbar.ftl
>
> ofbiz/branches/executioncontext20091231/themes/flatgrey/includes/footer.ftl
> Added:
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> URL:
> http://svn.apache.org/viewvc/ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java?rev=898965&view=auto
> ==
> ---
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> (added)
> +++
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> Wed Jan 13 22:06:46 2010
> @@ -0,0 +1,57 @@
> +
> ***/
> +package org.ofbiz.context;
> +
> +import static org.ofbiz.api.authorization.BasicPermissions.Access;
> +
> +import java.util.List;
> +
> +import javolution.util.FastList;
> +
> +import org.ofbiz.api.authorization.AccessController;
> +import org.ofbiz.api.context.ArtifactPath;
> +import org.ofbiz.api.context.ThreadContext;
> +import org.ofbiz.base.component.ComponentConfig;
> +import org.ofbiz.base.component.ComponentConfig.WebappInfo;
> +
> +/**
> + * ExecutionContext utility methods.
> + *
> + */
> +public class ContextUtil {
> +
> +public static List getAppBarWebInfos(String serverName,
> String menuName) {
> +List webInfos =
> ComponentConfig.getAppBarWebInfos(serverName, menuName);
> +String [] pathArray = {ArtifactPath.PATH_ROOT_NODE_NAME, null};
> +ArtifactPath artifactPath = new ArtifactPath(pathArray);
> +AccessController accessController =
> ThreadContext.getAccessController();
> +List resultList = FastList.newInstance();
> +for (WebappInfo webAppInfo : webInfos) {
> +pathArray[1] = webAppInfo.getContextRoot().replace("/", "");
> +artifactPath.saveState();
> +try {
> +accessController.checkPermission(Access, artifactPath);
> +resultList.add(webAppInfo);
> +} catch (Exception e) {}
> +artifactPath.restoreState();
> +}
> +return resultList;
> +}
> +
> +}
restoreState should be in finally. You don't handle runtime
exception. If it was in finally, you wouldn't need the catch. It's
also bad that you don't log the exception, or rethrow it.
Re: svn commit: r898965 - in /ofbiz/branches/executioncontext20091231: ./ framework/api/src/org/ofbiz/api/context/ framework/context/src/org/ofbiz/context/ framework/example/data/ themes/bizznesstime/
--- On Wed, 1/13/10, Adam Heath wrote:
> From: Adam Heath
> Subject: Re: svn commit: r898965 - in
> /ofbiz/branches/executioncontext20091231: ./
> framework/api/src/org/ofbiz/api/context/
> framework/context/src/org/ofbiz/context/ framework/example/data/
> themes/bizznesstime/includes/ themes/bluelight/includes/
> themes/droppingcrum...
> To: dev@ofbiz.apache.org
> Date: Wednesday, January 13, 2010, 6:31 PM
> adri...@apache.org
> wrote:
> > Author: adrianc
> > Date: Wed Jan 13 22:06:46 2010
> > New Revision: 898965
> >
> > URL: http://svn.apache.org/viewvc?rev=898965&view=rev
> > Log:
> > Implemented permission filters. Added a user group to
> the Example component. Main navigation is controlled by the
> new security design.
> >
> > Added:
> >
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java (with
> props)
> > Modified:
> >
> ofbiz/branches/executioncontext20091231/BranchReadMe.txt
> >
> ofbiz/branches/executioncontext20091231/framework/api/src/org/ofbiz/api/context/ThreadContext.java
> >
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/AccessControllerImpl.java
> >
> ofbiz/branches/executioncontext20091231/framework/example/data/ExampleSecurityData.xml
> >
> ofbiz/branches/executioncontext20091231/themes/bizznesstime/includes/appbar.ftl
> >
> ofbiz/branches/executioncontext20091231/themes/bizznesstime/includes/secondary-appbar.ftl
> >
> ofbiz/branches/executioncontext20091231/themes/bluelight/includes/appbarOpen.ftl
> >
> ofbiz/branches/executioncontext20091231/themes/droppingcrumbs/includes/appbarOpen.ftl
> >
> ofbiz/branches/executioncontext20091231/themes/flatgrey/includes/appbar.ftl
> >
> ofbiz/branches/executioncontext20091231/themes/flatgrey/includes/footer.ftl
>
> > Added:
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> > URL:
> > http://svn.apache.org/viewvc/ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java?rev=898965&view=auto
> >
> ==
> > ---
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> (added)
> > +++
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> Wed Jan 13 22:06:46 2010
> > @@ -0,0 +1,57 @@
> > +
> ***/
> > +package org.ofbiz.context;
> > +
> > +import static
> org.ofbiz.api.authorization.BasicPermissions.Access;
> > +
> > +import java.util.List;
> > +
> > +import javolution.util.FastList;
> > +
> > +import org.ofbiz.api.authorization.AccessController;
> > +import org.ofbiz.api.context.ArtifactPath;
> > +import org.ofbiz.api.context.ThreadContext;
> > +import org.ofbiz.base.component.ComponentConfig;
> > +import
> org.ofbiz.base.component.ComponentConfig.WebappInfo;
> > +
> > +/**
> > + * ExecutionContext utility methods.
> > + *
> > + */
> > +public class ContextUtil {
> > +
> > + public static List
> getAppBarWebInfos(String serverName, String menuName) {
> > + List
> webInfos = ComponentConfig.getAppBarWebInfos(serverName,
> menuName);
> > + String [] pathArray =
> {ArtifactPath.PATH_ROOT_NODE_NAME, null};
> > + ArtifactPath artifactPath
> = new ArtifactPath(pathArray);
> > + AccessController
> accessController = ThreadContext.getAccessController();
> > + List
> resultList = FastList.newInstance();
> > + for (WebappInfo
> webAppInfo : webInfos) {
> > +
> pathArray[1] = webAppInfo.getContextRoot().replace("/",
> "");
> > +
> artifactPath.saveState();
> > + try {
> > +
> accessController.checkPermission(Access,
> artifactPath);
> > +
> resultList.add(webAppInfo);
> > + } catch
> (Exception e) {}
> > +
> artifactPath.restoreState();
> > + }
> > + return resultList;
> > + }
> > +
> > +}
>
>
> restoreState should be in finally. You don't handle
> runtime
> exception. If it was in finally, you wouldn't need
> the catch. It's
> also bad that you don't log the exception, or rethrow it.
I think you're not understanding the application. This might help:
http://java.sun.com/javase/6/docs/api/java/security/AccessController.html#checkPermission%28java.security.Permission%29
-Adrian
Re: svn commit: r898965 - in /ofbiz/branches/executioncontext20091231: ./ framework/api/src/org/ofbiz/api/context/ framework/context/src/org/ofbiz/context/ framework/example/data/ themes/bizznesstime/
Adrian Crum wrote:
> --- On Wed, 1/13/10, Adam Heath wrote:
>
>> From: Adam Heath
>> Subject: Re: svn commit: r898965 - in
>> /ofbiz/branches/executioncontext20091231: ./
>> framework/api/src/org/ofbiz/api/context/
>> framework/context/src/org/ofbiz/context/ framework/example/data/
>> themes/bizznesstime/includes/ themes/bluelight/includes/
>> themes/droppingcrum...
>> To: dev@ofbiz.apache.org
>> Date: Wednesday, January 13, 2010, 6:31 PM
>> adri...@apache.org
>> wrote:
>>> Author: adrianc
>>> Date: Wed Jan 13 22:06:46 2010
>>> New Revision: 898965
>>>
>>> URL: http://svn.apache.org/viewvc?rev=898965&view=rev
>>> Log:
>>> Implemented permission filters. Added a user group to
>> the Example component. Main navigation is controlled by the
>> new security design.
>>> Added:
>>>
>>
>> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
>>(with
>> props)
>>> Modified:
>>>
>>ofbiz/branches/executioncontext20091231/BranchReadMe.txt
>>>
>>
>> ofbiz/branches/executioncontext20091231/framework/api/src/org/ofbiz/api/context/ThreadContext.java
>>>
>>
>> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/AccessControllerImpl.java
>>>
>>
>> ofbiz/branches/executioncontext20091231/framework/example/data/ExampleSecurityData.xml
>>>
>>
>> ofbiz/branches/executioncontext20091231/themes/bizznesstime/includes/appbar.ftl
>>>
>>
>> ofbiz/branches/executioncontext20091231/themes/bizznesstime/includes/secondary-appbar.ftl
>>>
>>
>> ofbiz/branches/executioncontext20091231/themes/bluelight/includes/appbarOpen.ftl
>>>
>>
>> ofbiz/branches/executioncontext20091231/themes/droppingcrumbs/includes/appbarOpen.ftl
>>>
>>
>> ofbiz/branches/executioncontext20091231/themes/flatgrey/includes/appbar.ftl
>>>
>>
>> ofbiz/branches/executioncontext20091231/themes/flatgrey/includes/footer.ftl
>>
>>> Added:
>> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java?rev=898965&view=auto
>>>
>> ==
>>> ---
>> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
>> (added)
>>> +++
>> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
>> Wed Jan 13 22:06:46 2010
>>> @@ -0,0 +1,57 @@
>>> +
>> ***/
>>> +package org.ofbiz.context;
>>> +
>>> +import static
>> org.ofbiz.api.authorization.BasicPermissions.Access;
>>> +
>>> +import java.util.List;
>>> +
>>> +import javolution.util.FastList;
>>> +
>>> +import org.ofbiz.api.authorization.AccessController;
>>> +import org.ofbiz.api.context.ArtifactPath;
>>> +import org.ofbiz.api.context.ThreadContext;
>>> +import org.ofbiz.base.component.ComponentConfig;
>>> +import
>> org.ofbiz.base.component.ComponentConfig.WebappInfo;
>>> +
>>> +/**
>>> + * ExecutionContext utility methods.
>>> + *
>>> + */
>>> +public class ContextUtil {
>>> +
>>> +public static List
>> getAppBarWebInfos(String serverName, String menuName) {
>>> +List
>> webInfos = ComponentConfig.getAppBarWebInfos(serverName,
>> menuName);
>>> +String [] pathArray =
>> {ArtifactPath.PATH_ROOT_NODE_NAME, null};
>>> +ArtifactPath artifactPath
>> = new ArtifactPath(pathArray);
>>> +AccessController
>> accessController = ThreadContext.getAccessController();
>>> +List
>> resultList = FastList.newInstance();
>>> +for (WebappInfo
>> webAppInfo : webInfos) {
>>> +
>> pathArray[1] = webAppInfo.getContextRoot().replace("/",
>> "");
>>> +
>> artifactPath.saveState();
>>> +try {
>>> +
>> accessController.checkPermission(Access,
>> artifactPath);
>>> +
>> resultList.add(webAppInfo);
>>> +} catch
>> (Exception e) {}
>>> +
>> artifactPath.restoreState();
>>> +}
>>> +return resultList;
>>> +}
>>> +
>>> +}
>>
>> restoreState should be in finally. You don't handle
>> runtime
>> exception. If it was in finally, you wouldn't need
>> the catch. It's
>> also bad that you don't log the exception, or rethrow it.
>
> I think you're not understanding the application. This might help:
>
> http://java.sun.com/javase/6/docs/api/java/security/AccessController.html#checkPermission%28java.security.Permission%29
That has no bearing whatsoever. RuntimeException and Error can happen
at any point.
Re: svn commit: r899053 - /ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
adri...@apache.org wrote:
> Author: adrianc
> Date: Thu Jan 14 03:54:23 2010
> New Revision: 899053
>
> URL: http://svn.apache.org/viewvc?rev=899053&view=rev
> Log:
> Better exception handling - suggested by Adam Heath.
>
> Modified:
>
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
>
> Modified:
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> URL:
> http://svn.apache.org/viewvc/ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java?rev=899053&r1=899052&r2=899053&view=diff
> ==
> ---
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> (original)
> +++
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> Thu Jan 14 03:54:23 2010
> @@ -20,6 +20,7 @@
>
> import static org.ofbiz.api.authorization.BasicPermissions.Access;
>
> +import java.security.AccessControlException;
> import java.util.List;
>
> import javolution.util.FastList;
> @@ -48,7 +49,9 @@
> try {
> accessController.checkPermission(Access, artifactPath);
> resultList.add(webAppInfo);
> -} catch (Exception e) {}
> +} catch (AccessControlException e) {
> +// This exception is expected - do nothing
> +}
> artifactPath.restoreState();
And what about the OutOfMemoryException that could be thrown by
resultList.add()?
Anytime you have a push/pop kind of pattern, you must use push before
a try, and pop inside the finally.
foo.push();
try {
code();
} finally {
foo.pop();
}
Re: svn commit: r899053 - /ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
--- On Wed, 1/13/10, Adam Heath wrote:
> From: Adam Heath
> Subject: Re: svn commit: r899053 -
> /ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> To: dev@ofbiz.apache.org
> Cc: comm...@ofbiz.apache.org
> Date: Wednesday, January 13, 2010, 8:17 PM
> adri...@apache.org
> wrote:
> > Author: adrianc
> > Date: Thu Jan 14 03:54:23 2010
> > New Revision: 899053
> >
> > URL: http://svn.apache.org/viewvc?rev=899053&view=rev
> > Log:
> > Better exception handling - suggested by Adam Heath.
> >
> > Modified:
> >
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> >
> > Modified:
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> > URL:
> > http://svn.apache.org/viewvc/ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java?rev=899053&r1=899052&r2=899053&view=diff
> >
> ==
> > ---
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> (original)
> > +++
> ofbiz/branches/executioncontext20091231/framework/context/src/org/ofbiz/context/ContextUtil.java
> Thu Jan 14 03:54:23 2010
> > @@ -20,6 +20,7 @@
> >
> > import static
> org.ofbiz.api.authorization.BasicPermissions.Access;
> >
> > +import java.security.AccessControlException;
> > import java.util.List;
> >
> > import javolution.util.FastList;
> > @@ -48,7 +49,9 @@
> > try {
> >
> accessController.checkPermission(Access,
> artifactPath);
> >
> resultList.add(webAppInfo);
> > - } catch
> (Exception e) {}
> > + } catch
> (AccessControlException e) {
> > +
> // This exception is expected - do nothing
> > + }
> >
> artifactPath.restoreState();
>
> And what about the OutOfMemoryException that could be
> thrown by
> resultList.add()?
>
> Anytime you have a push/pop kind of pattern, you must use
> push before
> a try, and pop inside the finally.
>
> foo.push();
> try {
> code();
> } finally {
> foo.pop();
> }
I really appreciate you taking the time to review my code. In this case, I
think you're making much ado about nothing. The object you are concerned about
is on the stack, so if any exception is thrown it will be discarded.
[jira] Created: (OFBIZ-3409) Add support for "PRODUCT_ACCESSORY" type association in product detail groovy
Add support for "PRODUCT_ACCESSORY" type association in product detail groovy -- Key: OFBIZ-3409 URL: https://issues.apache.org/jira/browse/OFBIZ-3409 Project: OFBiz Issue Type: Improvement Components: order Reporter: Vivek Mishra Fix For: Release Branch 9.04, SVN trunk Add support for "PRODUCT_ACCESSORY" type association in ProductDetail.groovy. It will help in association of accessories with a product. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3409) Add support for "PRODUCT_ACCESSORY" type association in product detail groovy
[ https://issues.apache.org/jira/browse/OFBIZ-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya reassigned OFBIZ-3409: -- Assignee: Ashish Vijaywargiya > Add support for "PRODUCT_ACCESSORY" type association in product detail groovy > -- > > Key: OFBIZ-3409 > URL: https://issues.apache.org/jira/browse/OFBIZ-3409 > Project: OFBiz > Issue Type: Improvement > Components: order >Reporter: Vivek Mishra >Assignee: Ashish Vijaywargiya > Fix For: Release Branch 9.04, SVN trunk > > > Add support for "PRODUCT_ACCESSORY" type association in > ProductDetail.groovy. It will help in association of accessories with a > product. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3409) Add support for "PRODUCT_ACCESSORY" type association in product detail groovy
[ https://issues.apache.org/jira/browse/OFBIZ-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Sharma updated OFBIZ-3409: --- Attachment: OFBIZ-3409.patch Here is the patch for support "PRODUCT_ACCESSORY" type association in productdetail.groovy Thanks Vivek !! Regards, -- Amit Sharma > Add support for "PRODUCT_ACCESSORY" type association in product detail groovy > -- > > Key: OFBIZ-3409 > URL: https://issues.apache.org/jira/browse/OFBIZ-3409 > Project: OFBiz > Issue Type: Improvement > Components: order >Reporter: Vivek Mishra >Assignee: Ashish Vijaywargiya > Fix For: Release Branch 9.04, SVN trunk > > Attachments: OFBIZ-3409.patch > > > Add support for "PRODUCT_ACCESSORY" type association in > ProductDetail.groovy. It will help in association of accessories with a > product. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
