Error: missing ; before statement
Line: 1206
Source Code:
netui_names.4="4" I get this error using this code. Why is netui generating code that gives
errors in ie8 and firefox? <netuidata:dataGrid dataSource="xxxxx" name="xxxxx" ><netuidata:header
><netuidata:headerCell><bean:message key='bcAdmin.quesHeaderDesc' /></netuidata:headerCell><netuidata:headerCell
value=" " /></netuidata:header><netuidata:rows ><netuidata:row ><netuidata:spanCell
value="adam" cellAlign="left" cellTagId="13/><netuidata:spanCell value="Edit" style="cursor:pointer;color:blue;font-weight:bold"onClick="javascript:
showRowData('13',this);" /></netuidata:row></netuidata:rows></netuidata:dataGrid>
_________________________________________________________________
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1
Can someone point me / tell me what the process is for submitting or notifying someone about fixing minor nits in the tutorial docs? While it looks like code development is rather quiet, there are substantive bugs in the documentation code snippets which makes digesting them more difficult, and it seems a shame not to correct them. Thanks, Gary
Under the blue header "Action Methods":
"Now it is time to re-implement the three action methods: login, ...
*****
"login" should be "myPage"
[ https://issues.apache.org/jira/browse/BEEHIVE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sowmyanarayanan updated BEEHIVE-1227:
-------------------------------------
Fix Version/s: (was: 1.0.1)
Affects Version/s: 1.0.1
> Disabled attribute in NetUI fileupload tag doesn't have any effect.
> -------------------------------------------------------------------
>
> Key: BEEHIVE-1227
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1227
> Project: Beehive
> Issue Type: Bug
> Components: NetUI
> Affects Versions: 1.0.1
> Reporter: Sowmyanarayanan
>
> Disabled attribute in NetUI fileupload doesn't have any effect. The file INPUT HTML element
generated is always enabled.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Disabled attribute in NetUI fileupload tag doesn't have any effect.
-------------------------------------------------------------------
Key: BEEHIVE-1227
URL: https://issues.apache.org/jira/browse/BEEHIVE-1227
Project: Beehive
Issue Type: Bug
Components: NetUI
Reporter: Sowmyanarayanan
Fix For: 1.0.1
Disabled attribute in NetUI fileupload doesn't have any effect. The file INPUT HTML element
generated is always enabled.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlin Rogers resolved BEEHIVE-1226.
------------------------------------
Resolution: Fixed
Fixed with svn revision 692920, a contribution from Poorna Ramasamy.
> Potential cross-site-scripting vulnerability in select and checkbox tags
> ------------------------------------------------------------------------
>
> Key: BEEHIVE-1226
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1226
> Project: Beehive
> Issue Type: Bug
> Components: NetUI
> Affects Versions: 1.0, 1.0.1, 1.0.2
> Reporter: Carlin Rogers
> Fix For: V.Next
>
>
> There is a potential cross-site-scripting issue with the netui select and checkbox tags.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Potential cross-site-scripting vulnerability in select and checkbox tags
------------------------------------------------------------------------
Key: BEEHIVE-1226
URL: https://issues.apache.org/jira/browse/BEEHIVE-1226
Project: Beehive
Issue Type: Bug
Components: NetUI
Affects Versions: 1.0.2, 1.0.1, 1.0
Reporter: Carlin Rogers
Fix For: V.Next
There is a potential cross-site-scripting issue with the netui select and checkbox tags.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Missing EJB Control Container
-----------------------------
Key: BEEHIVE-1224
URL: https://issues.apache.org/jira/browse/BEEHIVE-1224
Project: Beehive
Issue Type: Bug
Components: Controls
Affects Versions: 1.0.2
Environment: Operating System independent; WebLogic Server 9.2
Reporter: vijay
>From the docs (http://beehive.apache.org/docs/1.0.2/controls/containment.html): "Examples
of existing external containers for controls are the Servlet container, the EJB container,
the Spring bean container, ... "
However, there are no implementations of EJB or Spring Control Containers provided with the
beehive distribution. Either the doc is incorrect (there is in fact no EJB Control Container),
or this class has been omitted from the distro.
Please fix the doc or include the class in the distro. Please provide an example EJB control
container implementation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Eliseo--
The questions you're asking are relevant; to answer them, I'm
pulling them into the dev@ list so the discussion isn't buried in
notes on a Jira issue.
Beehive is not an archived ASF project and is as such "active", but
it's clear from the commit activity:
http://mail-archives.apache.org/mod_mbox/beehive-commits/
and traffic on the various mailing lists that the project is pretty
quiet and lacks forward momentum toward new releases or new features.
If you're interested in a new release, please say so directly. At
present, SVN contains a few minor bug fixes and no new features /
enhancements.
Cheers,
Eddie
---------- Forwarded message ----------
From: Eliseo Soto (JIRA) <jira@apache.org>
Date: Tue, Jun 17, 2008 at 1:51 PM
Subject: [jira] Created: (BEEHIVE-1222) Is this project still active?
To: dev@beehive.apache.org
Is this project still active?
-----------------------------
Key: BEEHIVE-1222
URL: https://issues.apache.org/jira/browse/BEEHIVE-1222
Project: Beehive
Issue Type: Wish
Components: Build
Reporter: Eliseo Soto
Priority: Trivial
Just curious about this project since the website hasn't been updated
in a while and the latest release is from 2006-12-04.
However I see that the SVN repo still has activity.
Is there a new release coming soon?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
There is an in depth description of how to enable beehive in an Eclipse WTP Web App, in a blog posted by Greg Mally. Ther versions referenced in the blog may be a old but I think it still works in eclipse 3.3.x with Beehive 1.0.2. Follow the steps outlined in the article. http://dev2dev.bea.com/blog/gmally/archive/2005/11/beehive_enable_1.html Kind regards, Carlin On Thu, Jul 10, 2008 at 6:27 AM, Aliaksei Yaustratsyeu <Aliaksei_Yaustratsyeu@epam.com> wrote: > Hello. > Please, can you help me to build the simple project using NetUi > technology under the Eclipse? > You can show how do it? > >
A good starting point for NetUI is the Tutorial here: http://beehive.apache.org/docs/1.0.2/netui/tutorial.html with the examples included in the distribution being a broader second step. Cheers, Eddie On Thu, Jul 10, 2008 at 6:27 AM, Aliaksei Yaustratsyeu <Aliaksei_Yaustratsyeu@epam.com> wrote: > Hello. > Please, can you help me to build the simple project using NetUi > technology under the Eclipse? > You can show how do it? > >
Aliaksei--
There's a blog entry here that might help you get started with a
Beehive-enabled Eclipse project:
http://dev2dev.bea.com/cs/user/blog%3ffile=/blog/gmally/archive/2005/11/beehive_enable.html
The steps are a little dated and apply to Eclipse 3.1, but they
should still help get you started.
Cheers,
Eddie
On Thu, Jul 10, 2008 at 6:23 AM, Aliaksei Yaustratsyeu
<Aliaksei_Yaustratsyeu@epam.com> wrote:
> Hello.
> Please, can you help me to build the simple project using Beehive
> technology under the Eclipse?
> You can show how do it?
>
Hello. Please, can you help me to build the simple project using NetUi technology under the Eclipse? You can show how do it?
Hello. Please, can you help me to build the simple project using Beehive technology under the Eclipse? You can show how do it?
"Could not find shared flow with name X" even when it's specified correctly in the code
---------------------------------------------------------------------------------------
Key: BEEHIVE-1223
URL: https://issues.apache.org/jira/browse/BEEHIVE-1223
Project: Beehive
Issue Type: Bug
Components: NetUI
Affects Versions: 1.0.2
Environment: BEA Portal 10
Reporter: Eliseo Soto
Hi,
Please take a look at the following code snippet:
[code]
@Jpf.Controller(
sharedFlowRefs = {
@Jpf.SharedFlowRef(name = "rootSharedFlow", type= com.company.portlets.BigGatewayAgentSharedFlow.class)
}
)
public final class MasterPinPopulateController extends BigGatewayAgentController {
private static final long serialVersionUID = -3177980439461585579L;
@Jpf.SharedFlowField(name = "rootSharedFlow")
private BigGatewayAgentSharedFlow sharedFlow;
.
.
.
}
public class BigGatewayAgentController extends PageFlowController {
private static final long serialVersionUID = 6528555130532846044L;
private transient Logger log = Logger.getLogger(this.getClass());
@Jpf.Action(
forwards = {
@Jpf.Forward(name = "success", path = "index.jsp")
}
)
public Forward begin() throws Exception {
return new Forward("success");
}
public Logger getLog() {
return log;
}
}
[/code]
When running the code I get this error in the logs:
ERROR org.apache.beehive.netui.pageflow.PageFlowController - Could not find shared flow with
name "rootSharedFlow" to initialize field sharedFlow in com.company.portlets.extensivesearch.MasterPinPopulateController
I think the error has something to do with the fact that I'm declaring a shared flow in a
class that doesn't extend PageFlowController directly.
The same happens with other classes that declare their page flows in a similar fashion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Is this project still active?
-----------------------------
Key: BEEHIVE-1222
URL: https://issues.apache.org/jira/browse/BEEHIVE-1222
Project: Beehive
Issue Type: Wish
Components: Build
Reporter: Eliseo Soto
Priority: Trivial
Just curious about this project since the website hasn't been updated in a while and the latest
release is from 2006-12-04.
However I see that the SVN repo still has activity.
Is there a new release coming soon?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlin Rogers resolved BEEHIVE-1221.
------------------------------------
Resolution: Fixed
Fix Version/s: V.Next
Assignee: Carlin Rogers
This is fixed with SVN revision 666879. Thanks for the contribution Scott.
> Forrest version conflict since post 0.7 release
> -----------------------------------------------
>
> Key: BEEHIVE-1221
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1221
> Project: Beehive
> Issue Type: Bug
> Components: Documentation
> Affects Versions: V1Alpha, V1Beta, v1m1, 1.0, 1.0.1, 1.0.2, V.Next
> Environment: All OS, not specific to platform.
> Reporter: Scott L'Hommedieu
> Assignee: Carlin Rogers
> Fix For: V.Next
>
> Attachments: forrest.properties.diff
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When building docs forrest uses the org.apache.forrest.plugin.output.pdf plugin. The
plugin reference in forrest.properties is version agnostic however version 0.7 (0.1 of the
plugin) is needed. Since the release of the latest version 0.8 of Forrest, this creates an
incompatibility. This will occur on all configurations unless you previously required this
plugin (built beehive) in a Forrest build before the release of 0.8 of Forrest.
> See http://forrest.apache.org/docs_0_80/faq.html#older-plugins for details on this issue
from a Forrest perspective.
> The change is simple to forrest.properties. I will attach a diff shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott L'Hommedieu updated BEEHIVE-1221:
---------------------------------------
Attachment: forrest.properties.diff
Diff of forrest.properties
> Forrest version conflict since post 0.7 release
> -----------------------------------------------
>
> Key: BEEHIVE-1221
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1221
> Project: Beehive
> Issue Type: Bug
> Components: Documentation
> Affects Versions: V1Alpha, V1Beta, v1m1, 1.0, 1.0.1, 1.0.2, V.Next
> Environment: All OS, not specific to platform.
> Reporter: Scott L'Hommedieu
> Attachments: forrest.properties.diff
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When building docs forrest uses the org.apache.forrest.plugin.output.pdf plugin. The
plugin reference in forrest.properties is version agnostic however version 0.7 (0.1 of the
plugin) is needed. Since the release of the latest version 0.8 of Forrest, this creates an
incompatibility. This will occur on all configurations unless you previously required this
plugin (built beehive) in a Forrest build before the release of 0.8 of Forrest.
> See http://forrest.apache.org/docs_0_80/faq.html#older-plugins for details on this issue
from a Forrest perspective.
> The change is simple to forrest.properties. I will attach a diff shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Forrest version conflict since post 0.7 release
-----------------------------------------------
Key: BEEHIVE-1221
URL: https://issues.apache.org/jira/browse/BEEHIVE-1221
Project: Beehive
Issue Type: Bug
Components: Documentation
Affects Versions: 1.0.2, 1.0.1, 1.0, v1m1, V1Beta, V1Alpha, V.Next
Environment: All OS, not specific to platform.
Reporter: Scott L'Hommedieu
When building docs forrest uses the org.apache.forrest.plugin.output.pdf plugin. The plugin
reference in forrest.properties is version agnostic however version 0.7 (0.1 of the plugin)
is needed. Since the release of the latest version 0.8 of Forrest, this creates an incompatibility.
This will occur on all configurations unless you previously required this plugin (built beehive)
in a Forrest build before the release of 0.8 of Forrest.
See http://forrest.apache.org/docs_0_80/faq.html#older-plugins for details on this issue from
a Forrest perspective.
The change is simple to forrest.properties. I will attach a diff shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Wysocki updated BEEHIVE-1215:
------------------------------------
Attachment: Controls.java
I have prepared a version which should deal with different classloaders that ControlFactory
can be loaded from. Eliminates the problem of heavy classpath scanning.
> ControlBean.lookupControlBeanContextFactory can be optimized
> ------------------------------------------------------------
>
> Key: BEEHIVE-1215
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1215
> Project: Beehive
> Issue Type: Improvement
> Components: Controls
> Affects Versions: 1.0.2
> Reporter: Anand Sridharan
> Attachments: ControlBean.java, Controls.java
>
>
> In ControlBean.lookupControlBeanContextFactory, everytime ControlBeanContext == null
or context.getService(ControlBeanContextFactory.class, null) returns null, discoverer.find(ControlBeanContextFactory.class,
DefaultControlBeanContextFactory.class.getName()) is called.
> discoverer.find is pretty costly & takes toll on performance when multiple control
instantiation happens at the same time under the given scenario.
> Moving discoverer.find to static block will make it run only once & hence improve
performance significantly.
> --------------------------->8-------------------------
> abstract public class ControlBean
> implements org.apache.beehive.controls.api.bean.ControlBean
> {
> static Class factoryClass;
> static DiscoverClass discoverer;
> static {
> discoverer = new DiscoverClass();
> factoryClass = discoverer.find(ControlBeanContextFactory.class, DefaultControlBeanContextFactory.class.getName());
> }
> .................
> .................
> private ControlBeanContextFactory lookupControlBeanContextFactory
> (org.apache.beehive.controls.api.context.ControlBeanContext context) {
> // first, try to find the CBCFactory from the container
> if(context != null) {
> ControlBeanContextFactory cbcFactory = context.getService(ControlBeanContextFactory.class,
null);
> if(cbcFactory != null) {
> return cbcFactory;
> }
> }
> // Create the context that acts as the BeanContextProxy for this bean (the context
that this bean _defines_).
> try
> {
> return (ControlBeanContextFactory)factoryClass.newInstance();
> }
> catch (Exception e) {
> throw new ControlException("Exception creating ControlBeanContext", e);
> }
> }
> ..................
> ....................
> ...................
> }
> ---------------------------8<----------------------------
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlin Rogers resolved BEEHIVE-1220.
------------------------------------
Resolution: Fixed
This is resolved with the change made in SVN revision 665719.
> The BaseHandler.reinit() method does not call the reinit() method on the _previousHandler
member
> -------------------------------------------------------------------------------------------------
>
> Key: BEEHIVE-1220
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1220
> Project: Beehive
> Issue Type: Bug
> Components: NetUI
> Affects Versions: 1.0, 1.0.1, 1.0.2
> Reporter: Carlin Rogers
> Assignee: Carlin Rogers
> Fix For: V.Next
>
>
> The BaseHandler.reinit() method does not call the reinit() method on the _previousHandler
member. In the case where the handlers are reinitialized, any previous handlers will not have
a correct servlet context. For example if the Handlers are serialized and de-serialized, The
transient servlet context member will be null. A reinit() will not reset the servlet context
member of the previous handler member... resulting in an NPE in some calls call to the previous
handler.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Anthony - Not necessarily. Beehive has several parts; and yes, PageFlow is the web framework of Beehive, and it is built on top of Struts. You forgot to mention another part of Beehive, namely, the Controls framework. This framework provides good encapsulation to complex JavaEE technologies, such as JDBC, JMS, and web services, as a component model. For example, the Web Service Control provides a java proxy class to a web service based on its WSDL. If you are on the Weblogic platform, it provides additional benefit since it integrates well with WLS, and it gives you feature coverage in areas such as conversational web service, transactions, EJB Timer, management console, etc. There are good support from the IDE as an eclipse plug-in. I was involved in implementing some of the technologies at one time and could give you more detail if you are interested. Regards, Xibin Zeng On Thu, Jun 5, 2008 at 4:45 PM, Antony Stubbs <antony.stubbs@gmail.com> wrote: > > Seriously - forget about Beehive - it's built on Struts and struts is crap. > > Use Wicket. > > > Eirik Rude-3 wrote: > > > > We are in the process of choosing a new framework to move all of our > > development to. One of the frameworks being considered is Beehive since > > we are on Weblogic servers. Can you tell us if this framework is still > > active, and if this is something we should be considering. > > > > Thank you, > > Eirik Rude > > Senior Internationalization Architect > > Vurv Technology > > > > > > > ----- > ___________________________ > > http://stubbisms.wordpress.com http://stubbisms.wordpress.com > -- > View this message in context: > http://www.nabble.com/Is-Beehive-still-an-active-project--tp16907363p17681890.html > Sent from the Beehive - Dev mailing list archive at Nabble.com. > >
Seriously - forget about Beehive - it's built on Struts and struts is crap. Use Wicket. Eirik Rude-3 wrote: > > We are in the process of choosing a new framework to move all of our > development to. One of the frameworks being considered is Beehive since > we are on Weblogic servers. Can you tell us if this framework is still > active, and if this is something we should be considering. > > Thank you, > Eirik Rude > Senior Internationalization Architect > Vurv Technology > > ----- ___________________________ http://stubbisms.wordpress.com http://stubbisms.wordpress.com -- View this message in context: http://www.nabble.com/Is-Beehive-still-an-active-project--tp16907363p17681890.html Sent from the Beehive - Dev mailing list archive at Nabble.com.
The BaseHandler.reinit() method does not call the reinit() method on the _previousHandler
member
-------------------------------------------------------------------------------------------------
Key: BEEHIVE-1220
URL: https://issues.apache.org/jira/browse/BEEHIVE-1220
Project: Beehive
Issue Type: Bug
Components: NetUI
Affects Versions: 1.0.2, 1.0.1, 1.0
Reporter: Carlin Rogers
Assignee: Carlin Rogers
Fix For: V.Next
The BaseHandler.reinit() method does not call the reinit() method on the _previousHandler
member. In the case where the handlers are reinitialized, any previous handlers will not have
a correct servlet context. For example if the Handlers are serialized and de-serialized, The
transient servlet context member will be null. A reinit() will not reset the servlet context
member of the previous handler member... resulting in an NPE in some calls call to the previous
handler.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlin Rogers resolved BEEHIVE-1219.
------------------------------------
Resolution: Fixed
Fix Version/s: V.Next
Assignee: Carlin Rogers
This is resolved with SVN revision 661404. Thanks for the contribution Poorna.
> Null check required at URLRewriterService.getURLRewriters method
> ----------------------------------------------------------------
>
> Key: BEEHIVE-1219
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1219
> Project: Beehive
> Issue Type: Bug
> Components: NetUI
> Affects Versions: 1.0
> Reporter: Poornachandran
> Assignee: Carlin Rogers
> Priority: Critical
> Fix For: V.Next
>
>
> Null check required at URLRewriterService.getURLRewriters method. If no rewriters, null
is passed on to Collections.unmodifiableList method and throws NullPointerException
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Poornachandran updated BEEHIVE-1219:
------------------------------------
Suggested fix:
public static List/*< URLRewriter >*/ getURLRewriters( ServletRequest request ) {
List rewriters = getRewriters( request );
if ( rewriters != null )
{
rewriters = Collections.unmodifiableList( rewriters );
}
return rewriters;
}
> Null check required at URLRewriterService.getURLRewriters method
> ----------------------------------------------------------------
>
> Key: BEEHIVE-1219
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1219
> Project: Beehive
> Issue Type: Bug
> Components: NetUI
> Affects Versions: 1.0
> Reporter: Poornachandran
> Priority: Critical
>
> Null check required at URLRewriterService.getURLRewriters method. If no rewriters, null
is passed on to Collections.unmodifiableList method and throws NullPointerException
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Null check required at URLRewriterService.getURLRewriters method
----------------------------------------------------------------
Key: BEEHIVE-1219
URL: https://issues.apache.org/jira/browse/BEEHIVE-1219
Project: Beehive
Issue Type: Bug
Components: NetUI
Affects Versions: 1.0
Reporter: Poornachandran
Priority: Critical
Null check required at URLRewriterService.getURLRewriters method. If no rewriters, null is
passed on to Collections.unmodifiableList method and throws NullPointerException
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hi all, This is the code i used in my JSP to create Beehive Tree Structure: <netui:tree tagId="tree" dataSource="positionTree" selectionAction="treeState" imageRoot="../../resources/images" selectedStyleClass="blueTree" treeStyle="tree" /> Its working properly, but expanding and collapsing functionality is not working. could any one help me out, what need to be added extra to my code, to make this work. in this link : http://beehive.apache.org/docs/1.0/netui/tagsTree.html, it has given that we have to add an extra attribute runAtClient="true", to make expand/collapse functionality work, when i try to add it, it was giving error saying "ITreeRootElement has to be defined". Could any one help me out in this regard. I am running out my ideas and options. Regards, Kumar -- View this message in context: http://www.nabble.com/netui%3Atree-problem-tp17037363p17037363.html Sent from the Beehive - Dev mailing list archive at Nabble.com.
Hi Eirik, The user community is active but I feel that the development activity has been limited. Contributions since the last release have consisted of bug fixes, minor feature improvements/enhancements, and documentation improvements. These types of changes would be appropriate for a new point release (1.0.3) but it has not been proposed yet. I really haven't seen activity or plans in the Beehive dev community about future work such as Struts 2 support, etc. As an open source project, contributions are always welcomed. Kind regards, Carlin On Fri, Apr 25, 2008 at 4:57 PM, Eirik Rude <erude@vurv.com> wrote: > We are in the process of choosing a new framework to move all of our development to. One of the frameworks being considered is Beehive since we are on Weblogic servers. Can you tell us if this framework is still active, and if this is something we should be considering. > > Thank you, > Eirik Rude > Senior Internationalization Architect > Vurv Technology >
We are in the process of choosing a new framework to move all of our development to. One of the frameworks being considered is Beehive since we are on Weblogic servers. Can you tell us if this framework is still active, and if this is something we should be considering. Thank you, Eirik Rude Senior Internationalization Architect Vurv Technology
The exact situation is as follows-
1. The jsp has two user actions-
i Continue with validations
ii Continue without validations
Both the above Continue user actions map to the same action method.
2. The action method is decorated with appropriate validation annotations.
3. Now the problem is to apply the validation annotations on one user action
and not apply them on another user action. We can have a boolean in the form
bean to be set from the jsp to decide if the validations have to be applied
or not.
There are other simple solutions for this problem but I thought the obvious
one using beehive was the one I have mentioned in my first post....
Has anybody encountered this situation before? Has anybody used the enabled
property of the Jpf validation annotations?
djkuul wrote:
>
> I am using the following annotation for validation on an Action method-
>
> validatableProperties={
> @Jpf.ValidatableProperty(
> displayName = "User Name ",
> propertyName = "username",
> validateRequired= @ValidateRequired(enabled=false))
> }
>
> If enabled is set to false, then the validate required rule should not be
> applied but in this case the validate required rule IS Applied... WHY??
>
> I want to do conditional validation, and hence am using the enabled =
> false. Going ahead I want to substitute the value of enabled with a
> runtime expression depending upon whether the validation has to be done or
> not(decided on the jsp). Any ideas?
>
> Appreciate any help, Thanks!
>
--
View this message in context: http://www.nabble.com/What-should-happen--%40ValidateRequired%28enabled%3Dfalse%29----tp16533317p16809863.html
Sent from the Beehive - Dev mailing list archive at Nabble.com.
[ https://issues.apache.org/jira/browse/BEEHIVE-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Gryszko updated BEEHIVE-1218:
------------------------------------
Priority: Minor (was: Major)
> Add doubleRange Commons Validator to Jpf.ValidateRange
> ------------------------------------------------------
>
> Key: BEEHIVE-1218
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1218
> Project: Beehive
> Issue Type: Improvement
> Components: NetUI
> Affects Versions: V.Next
> Reporter: Marcin Gryszko
> Priority: Minor
>
> Jpf.ValidateRange with minFloat and maxFloat generate a double,floatRange validator rule.
It will be nice to have a double,doubleRange validate rule generate. My suggestion is to add
minDouble and maxDouble annotation attributes to Jpf.ValidateRange in order to generate the
desired rule.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Add doubleRange Commons Validator to Jpf.ValidateRange
------------------------------------------------------
Key: BEEHIVE-1218
URL: https://issues.apache.org/jira/browse/BEEHIVE-1218
Project: Beehive
Issue Type: Improvement
Components: NetUI
Affects Versions: V.Next
Reporter: Marcin Gryszko
Jpf.ValidateRange with minFloat and maxFloat generate a double,floatRange validator rule.
It will be nice to have a double,doubleRange validate rule generate. My suggestion is to add
minDouble and maxDouble annotation attributes to Jpf.ValidateRange in order to generate the
desired rule.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589998#action_12589998
]
Dominique Gallot commented on BEEHIVE-1100:
-------------------------------------------
I ran into this issue as well.
It is a common issue, if you have page that take some time to load before sending the data
to the client.
Example
we have Two controller Upload and List
We go to Upload
Then go to List Page ( this distroy the current Upload controller, but does not change the
current ), this take time, page Upload is still show.
So the user, which does not like to wait, click on a button page page upload, the PageFlowRequestProcessor.getFlowController
is called, a current Upload Flow controller is already set, so it is reused.
But since it is destroyed all beehive control are null -> NPE.
The solution ( or workaround ? ) is to replace the lines ( PageFlowRequestProcessor:598 in
the method getFlowController( RequestContext requestContext, String fcClassName ) )
PageFlowController current = PageFlowUtils.getCurrentPageFlow( request, getServletContext()
);
if ( current != null && current.getClass().equals( fcClass ))
{
by
PageFlowController current = PageFlowUtils.getCurrentPageFlow( request, getServletContext()
);
if ( current != null && current.getClass().equals( fcClass ) &&
(!current.isDestroyed()))
{
which does not reuse a current flow controller if it has already be destroyed.
Hope this can be usefull.
Dominique
> page flow shared by two threads can be destroyed by one but isn't reinitialized by the
other
> --------------------------------------------------------------------------------------------
>
> Key: BEEHIVE-1100
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1100
> Project: Beehive
> Issue Type: Bug
> Components: NetUI
> Affects Versions: 1.0, 1.0.1, 1.0.2
> Reporter: Eddie O'Neil
>
> This is a JPF threading issue where two threads can start off sharing the same Page Flow.
When one thread destroys that JPF, the second thread continues to reuse the destroyed instance.
This can cause problems when re-running the destroyed JPF because any Controls or other fields
cleared in the "onDestroy" lifecycle handler can cause unexpected exceptions / behavior.
For example:
> Thread 1: current page flow is /a/A.jpf
> 1: reference /a/A.jpf
> 2: execute action "step 2"
> 5: attempt to execute action "step 3" -- strange behavior because
> internal state has been whacked by "destroy".
> Thread 2: current page flow is /a/A.jpf
> 3: reference /a/A.jpf
> 4: forward to /b/B.jpf -- causes onDestroy to be called on A.jpf
> I believe that the fix is to have the Thread1 re-create the JPF mid-request. This means
that Thread1 will lose the state /a/A.jpf, but in the current architecture, that makes sense
because the JPF was destroyed. When the JPF is re-created, it will attempt to run action
"step2" which could work but might also fail with an error or redirect to the beginning of
a wizard (for example). Fortunately, this scenario is the same as the case where the user
types this into their browser window:
> http://localhost:8080/fooWeb/somewizard/step2.do
> and the action either works or fails. It's just like starting a JPF over again in the
middle of the request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
I am using the following annotation for validation on an Action method-
validatableProperties={
@Jpf.ValidatableProperty(
displayName = "User Name ",
propertyName = "username",
validateRequired= @ValidateRequired(enabled=false))
}
If enabled is set to false, then the validate required rule should not be
applied but in this case the validate required rule IS Applied... WHY??
I want to do conditional validation, and hence am using the enabled = false.
Going ahead I want to substitute the value of enabled with a runtime
expression depending upon whether the validation has to be done or
not(decided on the jsp). Any ideas?
Appreciate any help, Thanks!
--
View this message in context: http://www.nabble.com/What-should-happen--%40ValidateRequired%28enabled%3Dfalse%29----tp16533317p16533317.html
Sent from the Beehive - Dev mailing list archive at Nabble.com.
[ https://issues.apache.org/jira/browse/BEEHIVE-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Poornachandran updated BEEHIVE-1217:
------------------------------------
Attachment: testcase.zip
test case that shows pageflow stack corruption
> PageFlow stack gets corrupted when a request to nested pageflow ends prematurely
> --------------------------------------------------------------------------------
>
> Key: BEEHIVE-1217
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1217
> Project: Beehive
> Issue Type: Bug
> Reporter: Poornachandran
> Attachments: testcase.zip
>
>
> Scenario:
> 1. Please compile the attached pageflows (unzip these files into the pageflow enabled
webapp and compile).
> 2. Run Controller.java pageflow and invoke "Go to Nested" action. "Go to Nested" on NestedPageFlowController
simulates delay (using loop) and it takes sometime to complete the action.
> 3. In the meantime, invoke "Done" action, this action belongs to the outer pageflow and
displays a jsp page.
> Now, the PageFlowStack has the outer pageflow instance pushed, but the flow has actually
come out of the nested pageflow. By repeating this process, page flow stack gets lot of invalid
pageflow instances and after sometime, NullPointerException is thrown.
> By adding a validation code in FlowControllerFactory before creating the pageflow instance
and before pushing the pageflow instance to the pageflow stack, I am able to overcome this
issue. Please update, if this is correct approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
PageFlow stack gets corrupted when a request to nested pageflow ends prematurely
--------------------------------------------------------------------------------
Key: BEEHIVE-1217
URL: https://issues.apache.org/jira/browse/BEEHIVE-1217
Project: Beehive
Issue Type: Bug
Reporter: Poornachandran
Scenario:
1. Please compile the attached pageflows (unzip these files into the pageflow enabled webapp
and compile).
2. Run Controller.java pageflow and invoke "Go to Nested" action. "Go to Nested" on NestedPageFlowController
simulates delay (using loop) and it takes sometime to complete the action.
3. In the meantime, invoke "Done" action, this action belongs to the outer pageflow and displays
a jsp page.
Now, the PageFlowStack has the outer pageflow instance pushed, but the flow has actually come
out of the nested pageflow. By repeating this process, page flow stack gets lot of invalid
pageflow instances and after sometime, NullPointerException is thrown.
By adding a validation code in FlowControllerFactory before creating the pageflow instance
and before pushing the pageflow instance to the pageflow stack, I am able to overcome this
issue. Please update, if this is correct approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlin Rogers updated BEEHIVE-1216:
-----------------------------------
Affects Version/s: 1.0.1
1.0.2
> issue in netui formatNumber tag
> -------------------------------
>
> Key: BEEHIVE-1216
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1216
> Project: Beehive
> Issue Type: Bug
> Components: NetUI
> Affects Versions: 1.0, 1.0.1, 1.0.2
> Reporter: Poornachandran
> Assignee: Julie Zhuo
> Priority: Minor
> Fix For: V.Next
>
> Attachments: patch.txt
>
>
> The following is the code snippet
> <netui:span value="999999999999999999.97">
> <netui:formatNumber pattern="#,###.##" type="currency" />
> </netui:span>
> produces the result 1,000,000,000,000,000,000
> The issue is identified in FormatNumber tag class, instead of using double, usage of
BigDecimal resolves the issue. I shall attach the patch file. Please submit this if it is
okay.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlin Rogers resolved BEEHIVE-1216.
------------------------------------
Resolution: Fixed
Fix Version/s: V.Next
Assignee: Julie Zhuo
Thanks for the patch Poorna. Looks good. I made some minor changes to handle the case when
a NumberFormatException is thrown with a null message from the BigDecimal constructor when
parsing the input data. I also updated the FormatTags test case to include the the rounding
error scenario noted in this bug.
This bug is fixed with SVN revision 619708.
> issue in netui formatNumber tag
> -------------------------------
>
> Key: BEEHIVE-1216
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1216
> Project: Beehive
> Issue Type: Bug
> Components: NetUI
> Affects Versions: 1.0
> Reporter: Poornachandran
> Assignee: Julie Zhuo
> Priority: Minor
> Fix For: V.Next
>
> Attachments: patch.txt
>
>
> The following is the code snippet
> <netui:span value="999999999999999999.97">
> <netui:formatNumber pattern="#,###.##" type="currency" />
> </netui:span>
> produces the result 1,000,000,000,000,000,000
> The issue is identified in FormatNumber tag class, instead of using double, usage of
BigDecimal resolves the issue. I shall attach the patch file. Please submit this if it is
okay.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/BEEHIVE-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Poornachandran updated BEEHIVE-1216:
------------------------------------
Attachment: patch.txt
svn diff of the change that fixes the issue
> issue in netui formatNumber tag
> -------------------------------
>
> Key: BEEHIVE-1216
> URL: https://issues.apache.org/jira/browse/BEEHIVE-1216
> Project: Beehive
> Issue Type: Bug
> Components: NetUI
> Affects Versions: 1.0
> Reporter: Poornachandran
> Priority: Minor
> Attachments: patch.txt
>
>
> The following is the code snippet
> <netui:span value="999999999999999999.97">
> <netui:formatNumber pattern="#,###.##" type="currency" />
> </netui:span>
> produces the result 1,000,000,000,000,000,000
> The issue is identified in FormatNumber tag class, instead of using double, usage of
BigDecimal resolves the issue. I shall attach the patch file. Please submit this if it is
okay.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.