[JBoss Tools] - How we use jface databinding in Deltacloud Tools
by Andre Dietisheim
Andre Dietisheim [http://community.jboss.org/people/adietish] modified the document:
"How we use jface databinding in Deltacloud Tools"
To view the document, visit: http://community.jboss.org/docs/DOC-15964
--------------------------------------------------------------
h1. Less code
If you use jface databinding to code your swt views in Eclipse you'll get spared from writing listeners and updating code by hand. JFace databinding offers very nice abstractions and automatisms that offer funcitonalities for the vast majority of the tasks where you have to listen for user input and update the view accordingly.
h1. *Premise*
If you implement a complex and highly dynamic UI in Eclipse you'll have to code many many many listener that wait for user actions. Those listeners mostly do nothing spectacular but update widgets and models in reaction to the user inputs. You end up with a lot of repetitive boilerplate code. UI frameworks in the non-java land (ex. http://qt.nokia.com/products/ Trolltechs QT) already have approaches that are far more elegant and slick than what we knew for Swing and SWT.
By luck Eclipse has progressed in this area (since 2005!) and offers neat abstractions that help a lot in this area and lead to far more concise and a less verbose implementations: Jface Databinding!
h2. Usecase
We had to implement a wizard page that allows a user to create a connection to a deltacloud server. The user has to supply a name, an url and the credentials for it.
http://community.jboss.org/servlet/JiveServlet/showImage/10530/cloud-conn... http://community.jboss.org/servlet/JiveServlet/downloadImage/10530/cloud-...
Sounds pretty simple at first sight. Looking closer at it you'll discover few buttons that shall be disabled if you enter inacurrate values. To inform the user in a intuitive way, the inaccurate values shall be marked by decorations. Furthermore a wizard page shows a global error message that reflects whether the user may finish the steps he's up to.
http://community.jboss.org/servlet/JiveServlet/showImage/10531/invalid-ur... http://community.jboss.org/servlet/JiveServlet/downloadImage/10531/invali...
h1. Solution
h2. No duplicate names
Our GUI holds multiple connections to various deltacloud servers. The wizard we discuss here allows you to edit existing connections or create new ones. You may of course not use a name that's already used for another connection. The wizard shall inform you that the name you chose is already used.
http://community.jboss.org/servlet/JiveServlet/showImage/10533/duplicate-... http://community.jboss.org/servlet/JiveServlet/downloadImage/10533/duplic...
To be intuitive the wizard shall decorate the field that's invalid. The wizard shall also show you what's wrong in cleartext and disallow you may to finish the wizard.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15964-11-105... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15964-11...
You may have a look at the code we have in our svn to see the source code we discuss here: http://anonsvn.jboss.org/repos/jbosstools/trunk/deltacloud/plugins/org.jb... CloudConnectionPage.java
*Enable and disable Finish button*
http://community.jboss.org/servlet/JiveServlet/showImage/102-15964-11-105... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15964-11...
In non-technical pure logical terms there's a single trigger to all these markers: You entered a bad value to a field.
The wizard reacts by decorating the text field that holds a the duplicate name, it displays the error in the header and it disabled the Finish button.
Jface databinding offers a context that holds a global validity state for a form. If a form gets invalid, the golbal state gets invalid, too. A jface wizards is built upon several pages. Such a page is a form that may be globally valid or invalid.
> DataBindingContext dbc = new DataBindingContext();
To enable/disable the Finish button you now need to connect the wizard page to the DataBindingContext. Jface databinding will then enable/disable the Finish (or the Next Page button for instance) automatically for you. To bind the validity of the databinding context to the page validity, you only need 1 line of code:
> WizardPageSupport.create(this, dbc);
Jface databinding will now enable the finish button (or the next-page button) for you as soon as the form aka the databinding context is valid.
h2. Let's decorate the name text field
We have no settings that are tracked by jface databinding yet. Our databinding context's always valid for now. We will now add the name to our binding context, track its validity and propagate its state to the context.
h3. Observables
Jface databinding is a framework that is built upon the principle of *model-view-controller (MVC)*. It connects a view to a model and stips down the code that's needed to implement the controller.
It basically synchronizes the value that's in a view (a SWT widget in our case) to the value held in a model (a bean with a property name in our case). You may enter a new name in the widget and jface databinding makes sure that the model gets that new value. It of course does that the other way round, too: As soon as you set a new value to the model, jface databinding will set this value to the widget that's visible in the wizard.
In order to do that it must be aware of changes on both ends of this binding. It needs to be able to observe values and get notified of changes. Jface databinding implements its own observable pattern, it offers a standardized interface on both ends: *Observable*.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15964-11-105... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15964-11...
SWT already offers Listeners that allow you to listen to changes in widgets and react to them. JFace databinding offers observable adapters that wrap these listeners and let them participate to the framework.
> IObservableValue textObservable = WidgetProperties.text(SWT.Modify).observe(nameText)
The jdk knows *PropertyChangeSupport* to observe changes in bean properties. Jface databinding also offers adapters to this observable pattern.
> IObservableValue beanPropertyObservable = BeanProperties.value(CloudConnectionModel.class, "name")
>
>
> IObservableValue beanPropertyObservable = BeanProperties.value(CloudConnectionModel.class, "name")
h1. Conclusione
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15964]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 2 months
[Performance Tuning] - Duplicate request threads are received at JBoss during Load Testing only for some value of maxThreads
by Rupesh Bhadeshiya
Rupesh Bhadeshiya [http://community.jboss.org/people/rupesh.bhadeshiya] created the discussion
"Duplicate request threads are received at JBoss during Load Testing only for some value of maxThreads"
To view the discussion, visit: http://community.jboss.org/message/568481#568481
--------------------------------------------------------------
Hi.
(1) We are getting Duplicate http requests / threads in JBoss when carrying out Load Testing for below configuration/details:
Concurrent Load Test Requests Sent:
- 100 (i.e. 100 concurrent users/threads)
- Software Used is: Grinder tool
App Server: JBoss:
- version: 5.1.0.GA AS, Non clustered
- maxThreads: default (which is 200)
- Xmx = Xmx = 1024m (Total System RAM is 2GB)
- Database Connection Pool: Min=50, Max=100
Database: MySQL:
- version: 5.0.40 Enterprise Server (GPL)
Our Application Consists of:
- an ear comprising:
- a web application having an MVC framework (webwork)
- several EJB applications as needed by web application
Exception we are getting:
17:33:20,224 ERROR [JDBCExceptionReporter] Duplicate entry '1011287747835421-DEFAULT_USER' for key 2
17:33:20,249 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:249)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:101)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:269)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:89)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1423)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:137)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:162)
at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1028)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:732)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:701)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:116)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:635)
at com.csam.wsc.projects.jvl.wallet.lifecycle.WalletLifecycleServicesImpl$$EnhancerByCGLIB$$7dd95c8c.enrollWallet(<generated>)
at com.csam.wsc.projects.jvl.enabling.action.WalletActivationAction.enroll(WalletActivationAction.java:159)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:300)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:166)
at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164)
at com.csam.wsc.enabling.interceptor.UpgradeWalletInterceptor.intercept(UpgradeWalletInterceptor.java:100)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164)
at com.csam.wsc.enabling.comms.interceptor.CommsBaseInterceptor.intercept(CommsBaseInterceptor.java:203)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164)
at com.csam.wsc.services.messagebus.interceptor.CommsMessageBusProductionInterceptor.intercept(CommsMessageBusProductionInterceptor.java:38)
at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164)
at com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActionProxy.java:116)
at com.opensymphony.webwork.dispatcher.ServletDispatcher.serviceAction(ServletDispatcher.java:272)
at com.opensymphony.webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:237)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.sql.BatchUpdateException: Duplicate entry '1011287747835421-DEFAULT_USER' for key 2
at com.mysql.jdbc.PreparedStatement.executeBatchSerially(PreparedStatement.java:2007)
at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1443)
at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:774)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
... 62 more
We have found that we have a user record created in database on server side with the said id (1011287747835421). Hence it is clear that there was another thread trying to create user record with same id and hence failing. We also found that in this case, there is one request from Load Testing client that was not served by server. We matched both the requests we sent from Load Testing client and those for which server processed them and found that in each such (Duplicate entry exception) case, our web application could receive one request less than total request sent by Load Testing client.
(2) We also found that when we are incresing the maxThreads count to more value such as 500 or 700, we no more get the Duplicate request issue.
Can you please guide us what can be the issue?
Thanks in advance for any help on this matter.
Thanks & Best Regards,
Rupesh
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/568481#568481]
Start a new discussion in Performance Tuning at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 2 months
[JBoss Tools] - How to figure out where a Jira were committed
by Max Andersen
Max Andersen [http://community.jboss.org/people/max.andersen%40jboss.com] modified the document:
"How to figure out where a Jira were committed"
To view the document, visit: http://community.jboss.org/docs/DOC-16014
--------------------------------------------------------------
Noone should ever forget to set the proper fix version on a jira when you resolve or close it but sometimes we forget.
Below i'm outlining how you can figure out when/where things are actually committed.
h1. Find the matching commit
First find the commit that matches the issue. For that the simplest way is to go to the Subversion Commit tab of the issue.
h2. http://community.jboss.org/servlet/JiveServlet/showImage/10525/jira_commi... http://community.jboss.org/servlet/JiveServlet/downloadImage/10525/450-14...
This of course assumes you reference the jira in the commit message. If the jira is not referenced go hunt down the developer
and make him find it - if that is yourself, well - good hunting. svn log or http://fisheye.jboss.org http://fisheye.jboss.org might be of help to you.
h1. Figure out what version the commit is for
When you got the commit you know the date and if it were committed in trunk or a branch.
Now if that is not enough to figure out what specific release it was in you need to start using svn log to be sure of when a commit actually happend - using the release date of JBoss Tools is not good since the release date might be a few days after the tag actually happend.
Thus svn log it is. You can use it to find when specific tags or branches happened.
To find the branch date of 3.2.x you do the following on a command line:
svn log https://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.1.x -v --stop-on-copy
This command goes back on the branch (or tag) and spits out the full log until it were created (i.e. when it were "copied")
This should give a long output which ends with something like this:
------------------------------------------------------------------------
r20399 | nickboldt | 2010-02-20 01:39:20 +0100 (Sat, 20 Feb 2010) | 1 line
Changed paths:
D /branches/jbosstools-3.1.0.RC2
A /branches/jbosstools-3.1.x (from /branches/jbosstools-3.1.0.RC2:20398)
rename branch from RC2 to .x
------------------------------------------------------------------------
This means that 3.1.x were done at "2010-02-20 01:39:20 +0100" and copied from the 3.1.0.RC2 branch, thus if your commit were done to this 3.1.0.RC2 branch before that date it is in 3.1.x. Of course if your commit were done in trunk you will then need to check if the RC2 branch were done before or after your trunk commit.
To know if your fix made it into a specific version (which you will need to know to set the proper fix version months after it actually happend) then you just use svn log on the specific tag. i.e. here it is for 3.2.0:
svn log https://svn.jboss.org/repos/jbosstools/tags/jbosstools-3.1.0.GA -v --stop-on-copy
------------------------------------------------------------------------
r20694 | nickboldt | 2010-03-06 00:46:43 +0100 (Sat, 06 Mar 2010) | 1 line
Changed paths:
A /tags/jbosstools-3.1.0.GA (from /branches/jbosstools-3.1.x:20693)
tag 3.1.0.GA
------------------------------------------------------------------------
Which reveals the actual 3.1.0.GA were done on "2010-03-06 00:46:43 +0100" about 3 weeks after the branch were created.
If you don't know the exact name of the tags/branches simply browse https://svn.jboss.org/repos/jbosstools/tags https://svn.jboss.org/repos/jbosstools/tags or https://svn.jboss.org/repos/jbosstools/tags https://svn.jboss.org/repos/jbosstools/branches
h1. What if my code does not live in JBoss Tools repo ?
This is the case for a few components such as Drools, Savara, Teiid and others. They cab do the similar tricks outlined above, but in that repo and match up what version in JBoss Tools it works with. If if in doubt on what version of Drools, Savara,etc. made it into a specific release, the simplest way is currently to ask on jbosstools-dev.
TBD: Link/page/resource where this can be found out.
h1. Update the Jira
If an issue is already resolved or closed you need to reopen the issue, put a comment on why (i.e. "reopen to set fix version"), set the fix version and then resolve or close it (i.e. whatever it was before) and then leave additional comments for what were found. i.e. if you had to track down the specific svn commit because the jira weren't referenced then putting in a rev id or even better the fisheye link to the related commit would be good. That avoids you or others to have to do the same hunting once more.
h1. Other resources
https://jira.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin... JBoss Tools jira changelog have trunk/branches listed + release dates (but note that is not the same day the tag where made, its TAG day + Day for QE and Release)
https://jira.jboss.org/browse/JBDS#selectedTab=com.atlassian.jira.plugin.... JBoss Developer Studio roadmap with rough maps to what JBoss Tools version it is based on
...and remember, all this could be avoided if you just always set the fix version properly when resolving/closing the issue ;)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16014]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 2 months
