Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ad...@jb...> - 2005-05-18 16:34:34
|
The plan down the road is to provide an aspectized deployer. You can find discussions in this forum, including: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=62231 On your specific issues: 1) I don't understand how you expect the HAR deployer to magically know which configuration files to use. You will have to explain the process or point me to some documentation. If all you want is to configure a HibernateSession, I don't see why can't specialize (or reuse) the HARDeployer code. 2) Your deployer is global (part of the server). All deployments can see global classes. The issue is with application classes in scoped deployments. In this case, the deployer must use the classloader(s) defined in the DeploymentInfo to get access to the scoped application classes. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878245#3878245 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878245 |
|
From: <kab...@jb...> - 2005-05-18 16:33:31
|
The class should contain both a method called "berechneFakten" as well as a method called
"wilken$informationssystem$berechtigung$BerichtBearbeitenBerechtigungImpl$getId$aop". The one with the long name will contain the original method, while the method with the short name wil contain the hooks for AOP.
For the class I pasted in above, following instrumentation, this should look something like:
| package wilken.informationssystem.berechtigung;
|
| public class BerichtBearbeitenBerechtigungImpl implements Advised
| {
| //Advisor fields get added
| Advisor _advisor = ...;
| InstanceAdvisor _instanceAdvisor = ...;
| public Advisor _getAdvisor(){return _advisor;}
| public InstanceAdvisor _getAdvisor(){return _instanceAdvisor;}
|
| //Introduced method contains the contents of original method
| public int wilken$informationssystem$berechtigung$BerichtBearbeitenBerechtigungImpl$getId$aop()
| {
| return 2938;
| }
|
| //The original method with your name with the hooks for AOP to happen
| public int getId()
| {
| if (aop$MethodInfo_getId_N_6040770469254561000.interceptors != (Object[])null || (_instanceAdvisor != null && _instanceAdvisor.hasInstanceAspects))
| {
| //Create invocation and invoke on it
| ...
| return invocation.invokeNext();
| }
| else
| {
| return wilken$informationssystem$berechtigung$BerichtBearbeitenBerechtigungImpl$getId$aop
| ();
| }
|
| }
|
If you look at
org.jboss.aop.instrument.MethodExecutionTransformer.optimized()
you should see that the extra method is created first?
Can you please post some more information about what exactly you are doing? It sounds like it works for you "most of the time", what is different when it goes wrong?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878244#3878244
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878244
|
|
From: hengels <nu...@jb...> - 2005-05-18 15:56:12
|
The MemberResolver is comparing a full qualified method name with a short method name. I'm at the root of problem with a debugger. The MemberResolver compares "<init>" | "berechneFakten" | "leseElemente" | ... with: "wilken$informationssystem$dimension$DerivativeFaktenBerechner$berechneFakten$aop" in a loop in line 96 of class MemberResolver (javaassist 3.0). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878233#3878233 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878233 |
|
From: dajevtic <nu...@jb...> - 2005-05-18 15:44:14
|
Count me in. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878230#3878230 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878230 |
|
From: <tom...@jb...> - 2005-05-18 15:31:44
|
I'm looking for the best way to get the JbpmSessionFactory in JNDI via the JBoss deployment stuff. ('stuff' indicates not-yet-crystal-clear :-)
I thought that the easiest way was to reuse the HAR deployer. But that seems to have 2 problems for me ...
1) the HAR deployer always scans for the mapping files by calling Configuration.addJar(). And this is *not* what we want because the jBPM .jar contains *all* possible .hbm.xml mapping files. Users will *not* want to use all of the mapping files.
The HibernateService in the hibernate codebase seems to have a manged property to specify the list of mappings... Could that be usefull ? How does that MBean relate to the jboss deployer ?
Ideally, i would like to configure the SessionFactory with the traditional hibernate.cfg.xml somewhere in the deployed archive.
2) The next i'm not certain about. How will user code in webapps and ejb's see my classes ? The classes loaded by an MBean are only visible in that MBean, right ? Are the persistent classes visible to the user code because of the unified class loader ? If yes, will users see those persistent classes if they start isolating their classloading ?
I prefer not to depend on the unified class loader since that can be switched off. So the jbpm.jar (containing the jbpm persistent classes) can be put in the lib folder ?
creating our own JbpmDeployer from scratch seems like the easiest solution. E.g. we could just create a hibernate configuration from a hibernate.cfg.xml file, then create a JbpmSessionFactory from that and then publish that in JNDI.
am i making any sense ?
This is what i found so far... any pointers to what i should read first are appreciated.
http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch2.chapter.html#ch2.scopedapp.ex
http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases
regards, tom.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878226#3878226
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878226
|
|
From: <ad...@jb...> - 2005-05-18 15:19:07
|
"timfox" wrote : | I.e. perhaps we should ask the quesion: Would a user really care about discriminating those messages that have never been delivered and those that have been NACKed by the channel's receivers? | | I'm sure there probably is a use case where this distinction is important - but I can't think of one right now. | Besides genman's comment there is the spec defined: javax.jms.Message.getJMSRedelivered() View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878219#3878219 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878219 |
|
From: hengels <nu...@jb...> - 2005-05-18 15:10:13
|
I'm using jboss aop and am trying to aspectize a method with a german umlaut in its name (that was not my idea). The Parser throws a CompileError("; is missing") in line 593 (version 3.0).
Regards,
Holger
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878216#3878216
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878216
|
|
From: hengels <nu...@jb...> - 2005-05-18 14:41:10
|
Hm, my getId method is marked final. But that's not the problem. It hasn't todo anything with the method. If I narrow the include patternset, I get the same problem with another method. Holger View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878209#3878209 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878209 |
|
From: <sco...@jb...> - 2005-05-18 13:24:36
|
The "materialize" target is what I want to try initially with errors/warnings about detected version differences being a byproduct of that target until we have a solid dependency mechanism with versioning that we trust to not get in the way of development. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878190#3878190 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878190 |
|
From: <kab...@jb...> - 2005-05-18 13:10:52
|
Weird,
The instrumentor first creates a copy of your original method with a new name (wilken$informationssystem$berechtigung$BerichtBearbeitenBerechtigungImpl$getId$aop) and then modifies the method with the original name to call the introduced method.
I was wondering if it could be to do with the length of the name of the method, so I tried your example and it worked fine. Here's my version of the original class.
| package wilken.informationssystem.berechtigung;
|
| public class BerichtBearbeitenBerechtigungImpl
| {
| public int getId()
| {
| return 2938;
| }
|
| }
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878188#3878188
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878188
|
|
From: genman <nu...@jb...> - 2005-05-18 12:58:26
|
There's a number of JBoss specific properties to the 3.2/4.0, one of which includes the number of delivery attempts. (This is used primarily by the MDB code, so that when the number of attempts reaches 10 the message goes to the DLQ.) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878187#3878187 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878187 |
|
From: umeshs79 <nu...@jb...> - 2005-05-18 12:16:59
|
Hi, I have around 10 projects in eclipse. 1 is the main project and it depends on all other projects. So to debug my application with JBoss: I created the sar/war file for my main project, which contains classes only from this project. I Created the JBoss Debug Configuration using Right Click -> Debug... And I added my all projects on Classpath tab under "User Entries" Now when I try to debug from eclipse it throws following exceptions For MBean: Caused by: java.lang.ClassNotFoundException: Unexpected error during load of: com.mypackage..mbean.MyService, msg=org/jboss/system/ServiceMBeanSupport For Application it throws: Caused by: java.lang.NoClassDefFoundError: javax/servlet/GenericServlet Please help me how do I set classpath so my other projects classes are access in JBoss. If I add all jar files from jboss-4.0.2\lib and jboss-4.0.2\server\default\lib all work fine. Please help me, I am new to JBoss, earlier I was using Resin and debuging Resin with Eclipse is very easy. Thanks Umesh View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878180#3878180 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878180 |
|
From: garu <nu...@jb...> - 2005-05-18 10:52:48
|
Opened Bug http://jira.jboss.com/jira/browse/JBCLUSTER-42. I tested the proposed solution and it looks to be working. As for my first question, now i see the need for that date check within the pullNewDeployments() method: stop/start the service from jmx console! Sorry i didn't thought of that. One more thing, i'm writing for my own usage a FarmMemberSingletonService that's modeled on FarmMemberService, ie it farms the applications in all the cluster nodes like it, but deployes them only in the singleton master so that if it goes down the new master is sure to have the correct apps version to deploy. Right now it works, but for the logic to control the service start/stop from jmx console that i have still to implement. I wished to extend FarmMemberService, but it is not easily extendable for such task unless some refactoring is done in URLDeploymentScanner and FarmMemberService so i had to duplicate the code adding some more logic. I'm wondering if you might be interested in including that service in Jboss once it is finished. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878173#3878173 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878173 |
|
From: hengels <nu...@jb...> - 2005-05-18 10:05:00
|
I've inserted an e,printStatckTrace in javaassist 3.0 and reproduced the error in order to get more information. It can't find a method. How come?
[aopc] compile error: Method wilken$informationssystem$berechtigung$BerichtBearbeitenBerechtigungImpl$getId$aop not found in wilken.informationssystem.berechtigung.BerichtBearbeitenBerechtigungImpl
| [aopc] at javassist.compiler.TypeChecker.atMethodCallCore(TypeChecker.java:648)
| [aopc] at javassist.compiler.TypeChecker.atCallExpr(TypeChecker.java:614)
| [aopc] at javassist.compiler.JvstTypeChecker.atCallExpr(JvstTypeChecker.java:156)
| [aopc] at javassist.compiler.ast.CallExpr.accept(CallExpr.java:45)
| [aopc] at javassist.compiler.CodeGen.doTypeCheck(CodeGen.java:235)
| [aopc] at javassist.compiler.CodeGen.compileExpr(CodeGen.java:222)
| [aopc] at javassist.compiler.CodeGen.atReturnStmnt2(CodeGen.java:591)
| [aopc] at javassist.compiler.JvstCodeGen.atReturnStmnt(JvstCodeGen.java:424)
| [aopc] at javassist.compiler.CodeGen.atStmnt(CodeGen.java:356)
| [aopc] at javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
| [aopc] at javassist.compiler.CodeGen.atStmnt(CodeGen.java:344)
| [aopc] at javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
| [aopc] at javassist.compiler.CodeGen.atIfStmnt(CodeGen.java:398)
| [aopc] at javassist.compiler.CodeGen.atStmnt(CodeGen.java:348)
| [aopc] at javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
| [aopc] at javassist.compiler.CodeGen.atStmnt(CodeGen.java:344)
| [aopc] at javassist.compiler.ast.Stmnt.accept(Stmnt.java:49)
| [aopc] at javassist.compiler.CodeGen.atMethodBody(CodeGen.java:285)
| [aopc] at javassist.compiler.Javac.compileBody(Javac.java:208)
| [aopc] at javassist.CtBehavior.setBody(CtBehavior.java:188)
| [aopc] at javassist.CtBehavior.setBody(CtBehavior.java:163)
| [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.optimized(MethodExecutionTransformer.java:365)
| [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.instrument(MethodExecutionTransformer.java:199)
| [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Instrumentor.java:573)
| [aopc] at org.jboss.aop.AspectManager.translate(AspectManager.java:572)
| [aopc] at org.jboss.aop.AspectManager.transform(AspectManager.java:490)
| [aopc] at org.jboss.aop.standalone.Compiler.compileFile(Compiler.java:258)
| [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.java:191)
| [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java:68)
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878165#3878165
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878165
|
|
From: hengels <nu...@jb...> - 2005-05-18 08:14:20
|
Hi,
I'm seeing another execption during method instrumentation. This time, the =
reason is not so obvious to me. Maybe someone could have a look at this:
[aopc] [debug] is advisable method: kopiereMitBeziehungen
| [aopc] [debug] does kopiereMitBeziehungen match execution(* wilken=
.basismodul.*->*(..)): false
| [aopc] [debug] does kopiereMitBeziehungen match execution(* wilken=
.informationssystem.*->*(..)): true
| [aopc] javassist.CannotCompileException: [source error] Method wil=
ken$informationssystem$berechtigung$BerichtBearbeitenBerechtigungImpl$getId=
$aop not found in wilken.informationssystem.berechtigung.BerichtBearbeitenB=
erechtigungImpl
| [aopc] at javassist.CtBehavior.setBody(CtBehavior.java:194)
| [aopc] at javassist.CtBehavior.setBody(CtBehavior.java:163)
| [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.=
optimized(MethodExecutionTransformer.java:365)
| [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.=
instrument(MethodExecutionTransformer.java:199)
| [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Inst=
rumentor.java:573)
| [aopc] at org.jboss.aop.AspectManager.translate(AspectManager.=
java:572)
| [aopc] at org.jboss.aop.AspectManager.transform(AspectManager.=
java:490)
| [aopc] at org.jboss.aop.standalone.Compiler.compileFile(Compil=
er.java:258)
| [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.j=
ava:191)
| [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java=
:68)
| [aopc] java.lang.RuntimeException: failed to transform: wilken.inf=
ormationssystem.berechtigung.BerichtBearbeitenBerechtigungImpl
| [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Inst=
rumentor.java:625)
| [aopc] at org.jboss.aop.AspectManager.translate(AspectManager.=
java:572)
| [aopc] at org.jboss.aop.AspectManager.transform(AspectManager.=
java:490)
| [aopc] at org.jboss.aop.standalone.Compiler.compileFile(Compil=
er.java:258)
| [aopc] at org.jboss.aop.standalone.Compiler.compile(Compiler.j=
ava:191)
| [aopc] at org.jboss.aop.standalone.Compiler.main(Compiler.java=
:68)
| [aopc] Caused by: java.lang.RuntimeException: code was: { if (=
aop$MethodInfo_getId_N_6040770469254561000.interceptors !=3D (Object[])null=
|| (_instanceAdvisor !=3D null && _instanceAdvisor.hasInstanceAspects)) =
{ org.jboss.aop.advice.Interceptor[] interceptors =3D aop$MethodIn=
fo_getId_N_6040770469254561000.interceptors; if (_instanceAdvisor !=
=3D null) { interceptors =3D _instanceAdvisor.getIntercept=
ors(interceptors); } wilken.informationssystem.berechtigung.B=
erichtBearbeitenBerechtigungImpl_getId_N6040770469254561000_OptimizedMethod=
Invocation invocation =3D new wilken.informationssystem.berechtigung.Berich=
tBearbeitenBerechtigungImpl_getId_N6040770469254561000_OptimizedMethodInvoc=
ation(aop$MethodInfo_getId_N_6040770469254561000, interceptors); inv=
ocation.setTargetObject(this); invocation.typedTargetObject =3D this=
; invocation.setAdvisor(aop$classAdvisor$aop); return ($r)inv=
ocation.invokeNext(); } else { return wilken$information=
ssystem$berechtigung$BerichtBearbeitenBerechtigungImpl$getId$aop($$); }=
} for method getId
| [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.=
optimized(MethodExecutionTransformer.java:370)
| [aopc] at org.jboss.aop.instrument.MethodExecutionTransformer.=
instrument(MethodExecutionTransformer.java:199)
| [aopc] at org.jboss.aop.instrument.Instrumentor.transform(Inst=
rumentor.java:573)
| [aopc] ... 5 more
|=20
This is the generated (reformatted) code:
if (aop$MethodInfo_getId_N_6040770469254561000.interceptors !=3D (Obj=
ect[])null
| || (_instanceAdvisor !=3D null && _instanceAdvisor.hasInstanc=
eAspects))
| {
| org.jboss.aop.advice.Interceptor[] interceptors =3D aop$Metho=
dInfo_getId_N_6040770469254561000.interceptors; =20
| if (_instanceAdvisor !=3D null) {
| interceptors =3D _instanceAdvisor.getInterceptors(interce=
ptors);
| } =20
| wilken.informationssystem.berechtigung.BerichtBearbeitenBerec=
htigungImpl_getId_N6040770469254561000_OptimizedMethodInvocation invocation=
=3D new wilken.informationssystem.berechtigung.BerichtBearbeitenBerechtigu=
ngImpl_getId_N6040770469254561000_OptimizedMethodInvocation(aop$MethodInfo_=
getId_N_6040770469254561000, interceptors);
| invocation.setTargetObject(this);
| invocation.typedTargetObject =3D this; =20
| invocation.setAdvisor(aop$classAdvisor$aop); =20
| return ($r)invocation.invokeNext(); =20
| } =20
| else { =20
| return wilken$informationssystem$berechtigung$BerichtBearbei=
tenBerechtigungImpl$getId$aop($$); =20
| }
|=20
<aop>
| <prepare expr=3D"execution(* wilken.basismodul.*->*(..))"/>
| <prepare expr=3D"execution(* wilken.informationssystem.*->*(..))"/>
| </aop>
|=20
View the original post : http://www.jboss.org/index.html?module=3Dbb&op=3Dv=
iewtopic&p=3D3878149#3878149
Reply to the post : http://www.jboss.org/index.html?module=3Dbb&op=3Dpostin=
g&mode=3Dreply&p=3D3878149
|
|
From: timfox <nu...@jb...> - 2005-05-18 07:19:17
|
We _could_ do this either way and make it configurable by the user. However, discriminating the two types of NACKs adds significant complexity to the implementation (it prompted this whole discussion) including changes to the core interfaces. My gut feeling is to keep it simple unless we really think the new feature would add value for the user. I.e. perhaps we should ask the quesion: Would a user really care about discriminating those messages that have never been delivered and those that have been NACKed by the channel's receivers? I'm sure there probably is a use case where this distinction is important - but I can't think of one right now. My feeling is that in most cases JMS users just want to have a rough idea of what's on the queue and hence what's going to be (re)delivered when the consumer/durables subcriber attaches. (I add durable subscriber here - since even though it's not part of JMS spec, browsing durable subscribers is something we could add, that does add value IMO... but that's a different discussion). Moreover, as Adrian has pointed out, the JMS spec makes no guarantees as to the consistency/"staticness" so anyone building a JMS application that relies on some extra knowledge of what's in the queue other than what's guaranteed by the spec. would be non-portable between JMS implementations. If it really is important for JMS Users to distinguish messages that have been never delivered/messages that have been delivered once etc., then another approach could be to use a jmsx message property, e.g. delivery_count which gets incremented every-time a delivery is attempted. The JMS user could then just filter on this value via a message selector when they do the browse. This should allow them to discriminate between these messages, and would require no changes to the core class interfaces. I think this approach is used by several jms implementations (i'm not sure about this but I just googled) including websphere and activemq. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878145#3878145 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878145 |
|
From: <cle...@jb...> - 2005-05-18 04:18:08
|
Why you guys are still using Specj2002? Why you don't upgrade to Specj2004 as specj2002 is already discontinued by Spec.org? Anyway, if you guys need any help: http://wiki.jboss.org/wiki/Wiki.jsp?page=SPECjAppServer2004 Clebert Suconic View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878133#3878133 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878133 |
|
From: <ovi...@jb...> - 2005-05-18 00:05:51
|
Right. And that's why JBossMQ's browsers do not show messages currently in queue but being in process of being acknowledged, while Reference Implementation's browsers do. Tim, what about a Channel.browse() method? Your QueueBrowser will rely on Channel's behavior. Later we can even make this behavior configurable in the Queue's deployment descriptor. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878123#3878123 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878123 |
|
From: <ad...@jb...> - 2005-05-17 22:46:38
|
All that is saying is that the jms implementation is NOT required to give a synchronized snapshot and that it is not transactional. In other words, unless you have no concurrent producers/consumers (and no message expiration/scheduled delivery) the messages returned by the browser are entirely unpredictable. e.g. | Enumeration e = browser.getEnumeration(); | Message m1 = receiver.receive(); | print(e); | Will it show m1 in the enumeration? Who knows? It is implementation defined. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878119#3878119 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878119 |
|
From: <ovi...@jb...> - 2005-05-17 22:24:17
|
anonymous wrote : | That assumption is NOT correct. If the message has been NACKed it is in the queue again and can be browsed just like any other message in the queue. | JMS Specification is very vague about this: anonymous wrote : | Section 5.9 | | A client uses a QueueBrowser to look at messages on a queue without removing them. A QueueBrowser can be created from a Session or a QueueSession. | | The browse methods return a java.util.Enumeration that is used to scan the queue?s messages. It may be an enumeration of the entire content of a queue, or it may contain only the messages matching a message selector. | | Messages may be arriving and expiring while the scan is done. JMS does not require the content of an enumeration to be a static snapshot of queue content. Whether these changes are visible or not depends on the JMS provider. Nowhere in this section is explicitely specified whether the "entire content of the queue" consists in messages that have not been delivered AND messages that have been delivered and NACKed, or only messages that haven't been delivered. JBossMQ's QueueBrowsers do not return NACKed messages, only undelivered messages. At this point, it is not very clear to me what a browser should return, actually. We could have this as a configuration option, I believe. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878117#3878117 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878117 |
|
From: <ad...@jb...> - 2005-05-17 21:57:44
|
I haven't got to the "release" part yet. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878114#3878114 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878114 |
|
From: <rya...@jb...> - 2005-05-17 21:46:13
|
What about defining the release structure - a responsibility previously held by the toplevel build. Is this no longer the case? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878113#3878113 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878113 |
|
From: timfox <nu...@jb...> - 2005-05-17 21:43:20
|
anonymous wrote : | That assumption is NOT correct. If the message has been NACKed it is in the queue | again and can be browsed just like any other message in the queue. | That's good... So we just browse any NACK. That should make thngs considerably simpler. We've come full circle back to the original design approach I posted but along the way I've learnt quite a lot about core, so that's good :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878112#3878112 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878112 |
|
From: <ad...@jb...> - 2005-05-17 21:25:06
|
Tim wrote: anonymous wrote : | | Further to the discussion regarding asynchronous ACKs, here are some thoughts on how we can implement QueueBrowsing on the core classes and how it all works together. | | The assumption here is that we want to be able to browse any messages in a queue where delivery has not been attempted. We don't want to browse those messages where the message has been delivered but the JMS client has NACKed it. | That assumption is NOT correct. If the message has been NACKed it is in the queue again and can be browsed just like any other message in the queue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878108#3878108 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878108 |
|
From: <ovi...@jb...> - 2005-05-17 21:21:21
|
The problem described by Tim is indirectly related to the way a Router handles acknowlegments. Actually, there are two distinct problems that need to be solved
1. A channel cannot distinguish between messages that have been delivered and NACKed and messages that haven't been delivered at all. We need this distinction to implement channel browsers.
2. Because a Router is currently a Receiver, its handle() method can only return a binary result (ACK/NACK) which is certainly not sufficient to express combinations of ACKs/NACKs from multiple receivers, in the case of a PointToMultipointRouter, for example.
Tim proposed to solve issue 1 by having three acknowledgment types . This would require changes throughout the core. I also think three acknowledgment types are not necessary, since NACK-DeliveryNotAttempted is a state that shouldn't propagate back on the receiver chain. We don't need to be able to browse all channels along a delivery path, we only need to be able to browse the last one, that actually keeps the message in question.
Here is another proposal that addresses 1. and 2. and it only requires localized changes. We still only have two types of acknowledgments: ACKs (true) and NACKs (false).
As originally designed, a Router is a synchronous component. It returns a NACK to the component that initiated delivery, if the delivery is not successful, but it does not hold messages and it does not attempt redelivery. In this respect, is not a Channel. To address 1. and 2. its interface should changes as follows
| public interface Router extends Distributor
| {
| public Serializable getRouterID();
|
| public Serializable[] handle(Routable);
| public Serializable[] handle(Routable, Serializable[]);
|
| public boolean isPassByReference();
| }
|
A Router is not a Receiver anymore, since the Receiver interface is not semantically rich enough.
The handle() method behaves as follows: the sender attempts delivery using handle(Routable) or handle(Routable, null). The Router synchronously delivers the Routable to the receivers it chooses (all receivers for a PointToMultipointRouter or only one receiver for a PointToPointRouter) and returns the array containing ReceiverIDs of receivers that NACKed. This way, the sender can store the NACKs and attempt redelivery later using handle(Routable, Serializable[]).
If the Router has no receivers, handle() only returns a single element array containing the Router's ID. This way, the sender knows the message was not delivered in the first place (this is the equivalent to Tim's NACK-DeliveryNotAttempted). The pipe that calls into the Router stores the message and it's also able to distinguish between NACKed messages and non-delivered messages.
Browsing the queue would mean quering the AcknowledgmentStore for all messages that have been NACKed by the Router and not by individual Receivers.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878107#3878107
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878107
|
1965 messages has been excluded from this view by a project administrator.
