[Remoting] - Bisocket transport sample code?
by ron.sigalï¼ jboss.com
anonymous wrote :
| Hi,
|
| Is there any example I can run to experience Bisocket in jboss-remoting?
|
| Regards,
|
| Erez Harari
|
| Axcepia Technologies
|
Hi Erez,
That's a good question, and I've created JBREM-773 "Create bisocket sample code" in response. For now, you could look at the unit tests in org.jboss.test.remoting.transport.bisocket.BisocketTestCase, e.g., testAlternatingInvocationsAndCallbacks(). Superficially, though, the code using bisocket doesn't look much different than it would if it used the socket transport, other than some configuration parameters. The real difference is behind the API, in the handling of callback connections.
Of course, one of the goals of Remoting is to present a unifed API that hides transport details.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063286#4063286
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063286
18Â years, 11Â months
[JBoss Seam] - Re: two basic questions for EntityHome
by wschwendt
For testing purposes I've defined an EntityHome component using components.xml
| <framework:entity-home name="customerHome"
| entity-class="Customer"
| entity-manager="#{entityManager}"/>
|
If a page accesses #{customerHome} via EL, then in the conversation context a context variable named customerHome gets set. Possibly because org.jboss.seam.framework.Home is annotated with @Scope(ScopeType.CONVERSATION)
If a page page accesses #{customerHome.instance} via EL, then in the conversation context not only the context variable named customerHome gets set (as expected), but in addition to it also a context variable named "customerHome.instance" (NOT expected).
This raises the question why "customerHome.instance" gets set. I've searched for any outjection code, but so far without success. Probably I have tomatoes on my eyes.
azalea, does a context variable named "EntityHomeName.instance" gets set in your case, too?
Perhaps this could be the reason for the caching behavior.
Where in the seam code happens the outjection to the "customerHome.instance" context variable?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063285#4063285
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063285
18Â years, 11Â months
[JBoss Seam] - fileUpload component - Strange behavior
by jtsimikas
I am experiencing some strange behavior with s:fileUpload.
The upload itself works fine, however I am noticing some unusual
behavior which happens "sporadically."
<h:form id="insertForm" enctype="multipart/form-data">
....
<s:fileUpload id="attachment"
data="#{plasticsInsertForm.insertDocument}"
fileName="#{plasticsInsertForm.insertDocumentName}"/>
....
<h:commandButton value=" Apply Changes " id="submitButton"
styleClass='submitButton' action="#{plasticsInsert.validateForm}"/>
......
The method validateForm() which should always be executed on every button click "sometimes" does not get executed when the fileUpload component is utilized. Once the fileUpload component is removed, the action method is called on every click as normal.
Is this a bug.. a timing issue of some kind... any ideas?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063280#4063280
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063280
18Â years, 11Â months
[JBoss Seam] - Re: Nested conversations - potential bug in Manager.beginNes
by wschwendt
"gavin.king(a)jboss.com" wrote : You can't end two conversations in a single request. That's not how the model works. @End simply says "at the end of the request, end the current conversation".
For error handling a typical idiom in pages.xml is:
| <exception class="javax.persistence.OptimisticLockException">
| <end-conversation/>
| <redirect view-id="/error.xhtml">
| <message>Another user changed the same data, please try again</message>
| </redirect>
| </exception>
Now imagine that the exeption was thrown when a nested conversation was in progress: Then above idiom would only end the nested conversation (???)
But wouldn't it make sense to end also the all parent conversations up to (inclusive) the top-level long-running conversation?
Assuming that nested conversations share the persistence context (EntityManager) with their parent conversation (is my understanding right or wrong here?), wouldn't an exception, thrown while the nested conversation is in progress, lead to the situation that also the persistence context of the parent conversation gets cleared?
I could be totally wrong here, but if also the persistence context of the parent conversation gets cleared, I think it would make sense to end also that parent conversation before redirecting to error.xhtml.
So something as follows would be nice (with a more meaningful attribute name than "transitive" however).
| <exception class="javax.persistence.OptimisticLockException">
| <end-conversation transitive="true"/> // end all conversations up to top-level long-running conversation (inclusive)
| <redirect view-id="/error.xhtml">
| <message>Another user changed the same data, please try again</message>
| </redirect>
| </exception>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063272#4063272
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063272
18Â years, 11Â months