[jBPM Development] - Problems with date filters in the HistoryService (HistoryAct
by NAKHO
=== Environment ==============================
- jBPM Version : jbpm 4.1
- Database : oracle(ojdbc14.jar ->Oracle JDBC Driver version - 9.0.2.0.0)
-JDK : 1.5.09
- Container : jboss 4.05 GA
- Configuration :only importing files from the jbpm.jar
lib itself? or did you create a custom config file?
- Libraries : all jbmp libraries
=== Problem description =========================
When I use the historyService for search activities by dates (for example activities started before or after) I checks the assigned method (historyService.createHistoryActivityInstanceQuery().executionId(idProcessInstance).startedBefore()) does not filter the records correctly. For example for the records (JBPM4_HIST_ACTINST table):
DBID_ CLASS_ DBVERSION_ HPROCI_ TYPE_ EXECUTION_ ACTIVITY_NAME_ START_ END_ DURATION_ TRANSITION_ NEXTIDX_ HTASK_
1328 act 1 1326 state SERVICIO_TEST2.CI-797 state2 21/10/2009 10:51:25,748000 21/10/2009 10:51:25,998000 250 1
1327 act 1 1326 state SERVICIO_TEST2.CI-797 receive confirmation 21/10/2009 10:51:25,498000 21/10/2009 10:51:25,717000 219 to state2 1
I execute the method historyService.createHistoryActivityInstanceQuery().executionId("SERVICIO_TEST2.CI-797").startedBefore(new java.util.GregorianCalendar(2009, 9,22,10,37).getTime()).list() and returns 0 activities.
I think the problems is in the method org.jbpm.pvm.internal.query.HistoryActivityInstanceQueryImpl.applyParameters(Query) . This method assigns to query the "startedAfter" parameter a field of type Date instead Timestamp. If I assign the Timestamp field to "startedAfter" parameter the execution query returns two records.
The query log are correct:
Hibernate: select historyact0_.DBID_ as DBID1_10_, historyact0_.DBVERSION_ as DBVERSION3_10_, historyact0_.HPROCI_ as HPROCI4_10_, historyact0_.TYPE_ as TYPE5_10_, historyact0_.EXECUTION_ as EXECUTION6_10_, historyact0_.ACTIVITY_NAME_ as ACTIVITY7_10_, historyact0_.START_ as START8_10_, historyact0_.END_ as END9_10_, historyact0_.DURATION_ as DURATION10_10_, historyact0_.TRANSITION_ as TRANSITION11_10_, historyact0_.NEXTIDX_ as NEXTIDX12_10_, historyact0_.HTASK_ as HTASK13_10_, historyact0_.CLASS_ as CLASS2_10_ from JBPM4_HIST_ACTINST historyact0_ where historyact0_.START_<? and historyact0_.EXECUTION_='SERVICIO_TEST2.CI-797'
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261420#4261420
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261420
16 years, 5 months
[jBPM Development] - Re: Criteria ordered not execute on the HistoryActivityInsta
by NAKHO
=== Environment ==============================
- jBPM Version : jbpm 4.1
- Database : oracle(ojdbc14.jar ->Oracle JDBC Driver version - 9.0.2.0.0)
-JDK : 1.5.09
- Container : jboss 4.05 GA
- Configuration :only importing files from the jbpm.jar
lib itself? or did you create a custom config file?
- Libraries : all jbmp libraries
=== Problem description =========================
API doesn't work as expected because the class HistoryActivityInstanceQuery not executes criteria orders (for example: PROPERTY_STARTTIME, or PROPERTY_EXECUTIONID). If look the hibernate log we see that it does not appear the query criteria ordered.
log:
Hibernate: select historyact0_.DBID_ as DBID1_10_, historyact0_.DBVERSION_ as DBVERSION3_10_, historyact0_.HPROCI_ as HPROCI4_10_, historyact0_.TYPE_ as TYPE5_10_, historyact0_.EXECUTION_ as EXECUTION6_10_, historyact0_.ACTIVITY_NAME_ as ACTIVITY7_10_, historyact0_.START_ as START8_10_, historyact0_.END_ as END9_10_, historyact0_.DURATION_ as DURATION10_10_, historyact0_.TRANSITION_ as TRANSITION11_10_, historyact0_.NEXTIDX_ as NEXTIDX12_10_, historyact0_.HTASK_ as HTASK13_10_, historyact0_.CLASS_ as CLASS2_10_ from JBPM4_HIST_ACTINST historyact0_ where historyact0_.START_<? and historyact0_.EXECUTION_='SERVICIO_TEST2.CI-797'
- In this query not exists criteria order. This query must be:
Hibernate: select historyact0_.DBID_ as DBID1_10_, historyact0_.DBVERSION_ as DBVERSION3_10_, historyact0_.HPROCI_ as HPROCI4_10_, historyact0_.TYPE_ as TYPE5_10_, historyact0_.EXECUTION_ as EXECUTION6_10_, historyact0_.ACTIVITY_NAME_ as ACTIVITY7_10_, historyact0_.START_ as START8_10_, historyact0_.END_ as END9_10_, historyact0_.DURATION_ as DURATION10_10_, historyact0_.TRANSITION_ as TRANSITION11_10_, historyact0_.NEXTIDX_ as NEXTIDX12_10_, historyact0_.HTASK_ as HTASK13_10_, historyact0_.CLASS_ as CLASS2_10_ from JBPM4_HIST_ACTINST historyact0_ where historyact0_.START_<? and historyact0_.EXECUTION_='SERVICIO_TEST2.CI-797' order by historyact0_.START_ desc
-However, in the other AbstractQuery implementations (ProcessDefinitionQueryImpl or ProcessInstanceQueryImpl) works correctly and I think it's because in the hql construction the method don`t invoke to appender order clause. For example I look the appendOrderByClause method is invoked in the org.jbpm.pvm.internal.query.ProcessInstanceQueryImpl.hql()
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261414#4261414
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261414
16 years, 5 months
[jBPM Development] - Criteria ordered not execute on the HistoryActivityInstanceQ
by NAKHO
=== Environment ==============================
- jBPM Version : jbpm 4.1
- Database : oracle(ojdbc14.jar ->Oracle JDBC Driver version - 9.0.2.0.0)
-JDK : 1.5.09
- Container : jboss 4.05 GA
- Configuration :only importing files from the jbpm.jar
lib itself? or did you create a custom config file?
- Libraries : all jbmp libraries
=== Problem description =========================
API doesn't work as expected because the class HistoryActivityInstanceQuery not executes criteria orders (for example: PROPERTY_STARTTIME, or PROPERTY_EXECUTIONID). If look the hibernate log we see that it does not appear the query criteria ordered.
log:
Hibernate: select historyact0_.DBID_ as DBID1_10_, historyact0_.DBVERSION_ as DBVERSION3_10_, historyact0_.HPROCI_ as HPROCI4_10_, historyact0_.TYPE_ as TYPE5_10_, historyact0_.EXECUTION_ as EXECUTION6_10_, historyact0_.ACTIVITY_NAME_ as ACTIVITY7_10_, historyact0_.START_ as START8_10_, historyact0_.END_ as END9_10_, historyact0_.DURATION_ as DURATION10_10_, historyact0_.TRANSITION_ as TRANSITION11_10_, historyact0_.NEXTIDX_ as NEXTIDX12_10_, historyact0_.HTASK_ as HTASK13_10_, historyact0_.CLASS_ as CLASS2_10_ from JBPM4_HIST_ACTINST historyact0_ where historyact0_.START_<? and historyact0_.EXECUTION_='SERVICIO_TEST2.CI-797'
- In this query not exists criteria order. This query must be:
Hibernate: select historyact0_.DBID_ as DBID1_10_, historyact0_.DBVERSION_ as DBVERSION3_10_, historyact0_.HPROCI_ as HPROCI4_10_, historyact0_.TYPE_ as TYPE5_10_, historyact0_.EXECUTION_ as EXECUTION6_10_, historyact0_.ACTIVITY_NAME_ as ACTIVITY7_10_, historyact0_.START_ as START8_10_, historyact0_.END_ as END9_10_, historyact0_.DURATION_ as DURATION10_10_, historyact0_.TRANSITION_ as TRANSITION11_10_, historyact0_.NEXTIDX_ as NEXTIDX12_10_, historyact0_.HTASK_ as HTASK13_10_, historyact0_.CLASS_ as CLASS2_10_ from JBPM4_HIST_ACTINST historyact0_ where historyact0_.START_<? and historyact0_.EXECUTION_='SERVICIO_TEST2.CI-797' order by historyact0_.START_ desc
-However, in the other AbstractQuery implementations (ProcessDefinitionQueryImpl or ProcessInstanceQueryImpl) works correctly and I think it's because in the hql construction the method don`t invoke to appender order clause. For example I look the appendOrderByClause method is invoked in the org.jbpm.pvm.internal.query.ProcessInstanceQueryImpl.hql()
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261413#4261413
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261413
16 years, 5 months
[JBoss ESB Development] - Re: SAML Token Support
by jeff.yuchang
Maybe let us discuss by use case here. (sorry if these two use cases are obvious). ;-)
we have two scenarios here:
1. client didn't have a saml token, it just has username&password, and it tries to use our SAML Login Module to do the authentication. In this case, our LoingModuleImpl should have two steps.
1). Use the username&password to issue a token.
2). Validate this token and propagate this token if necessary.
2. client had an existing saml token. It expects ESB to do the authentication based on this token. Our LoginModuleImpl just need one step.
1) Validate this token and propagate this token if necessary.
Based on above analysis, I thought the LoginModule should be only doing one thing, and also issue a token should not belong to the LoginModuleImpl. (it should be happened before talk to JAAS authentication, just like you should have username&password, and then try to talk to JAAS).
So I prefer to have an action and a LoginModule instead of having just one LoginModule.
Sorry if I misunderstood something here. ;-)
Regards
Jeff
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261385#4261385
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261385
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by david.lloyd＠jboss.com
"alesj" wrote : "david.lloyd(a)jboss.com" wrote :
| | What if there was a substantial speed increase and memory footprint decrease associated with doing so? That's the question I think we need to explore here.
| |
| No.
|
| As all the complex/slow processing should be done by the tool, pre-runtime.
| Deserializing + reattaching annotation repository is O(1).
|
Again that's your opinion, but spec compliance isn't optional and this is what we all agreed to accomplish. If you want to reopen the question, go for it.
"alesj" wrote : Sure, but that doesn't mean you should rewrite everything that you don't like. ;-)
| btw: how is Remoting3 coming along ... :-)
What else does it mean? I'm not rewriting things I don't like, I'm rewriting things that are not doing the job they're supposed to be doing, so that they do. I'm not arbitrarily picking on projects. I'm measurably improving things. Every single thing I've rewritten is measurably better than it was before. Logging is 10%+ faster and now supports JDK logging as well as Log4j, and is fully integrated with MC. Threads are now fully POJO-ized as well, and abstracted behind a clean and simple API which makes it very easy to plug in alternate implementations - without adding lots of extra abstraction. VFS is next because it's the next-most-significant blip on the radar in terms of performance problems which is something we are all supposed to be working towards fixing.
Remoting is coming along quite well. The Marshalling subproject (another evil rewrite!) is now being used by Infinispan (another evil rewrite!) with some great performance numbers. The XNIO subproject is also successful and will be the core of network configuration on AS 6. Were it not for the VFS work I'm doing now, I'd have 3.1 released already.
Not all rewrites are bad. It is not reasonable to maintain a deathgrip on existing code out of a sense of personal attachment. One must always be ready to throw away what they have if it's defective in design. Knowing this makes one rethink design in terms of avoiding lock-in. That's why my projects all have so few dependencies and impose few or no dependencies on their consumers.
My experience shows that it's more cost-effective in the long run to get rid of problems early on, rather than continually applying small patches. I'm sorry if you disagree but I think my approach is fairly well proven at this point, and I can and have been able to back that up with numbers rather than just a stream of increasing problems and complaints, which is what I think the logical culmination of the "use existing codebases at all costs" approach.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261330#4261330
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261330
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by david.lloyd＠jboss.com
"alesj" wrote : "david.lloyd(a)jboss.com" wrote :
| | Far simpler than designing a plugin mechanism for restrictions is to simplify the API so that you just give it the input streams of classes you want to index. Simplfying the API is usually preferable to adding an abstraction.
| |
| A? What kind of nonsense is this?
|
| And how do you plan on providing this streams?
| Via abstraction!!!!
|
No, I'm saying rather than having the scanner pull in the classes, the API consumer pushes the classes into the scanner. This way you don't have to worry about missing use cases when you design the abstraction. This way, Papaki is less limited by usage patterns.
Case in point, say Papaki depends on VFS and uses that project's visitor system to scan classes. Now later on we want to scan classes that are not found on VFS (maybe they're being downloaded). In this case, tying to VFS was an arbitrary restriction that we pay for later since now all classes have to be wedged in there whether it makes sense or not. On the other hand, if we push classes in, then both use cases are easily accommodated.
"alesj" wrote : [Or how else are you gonna know which one's should or shouldn't be scanned?
| Should I list them by hand, all of the 1M classes?
| Or what about if tomorrow Sun speeds up its modules impl,
| and we all start doing module-info.java?
This logic would be something that belongs in the module-loading layer (which is currently spread between deployers and classloading as far as I can tell), not in the scanning layer. The scanning layer does not have semantic awareness of what should or should not be scanned, so there's no reason to push this functionality into it. Let it do one thing well.
"alesj" wrote : "david.lloyd(a)jboss.com" wrote :
| | The specifications for many of our components (like EJB 3.1) tell us that we can't rely on this, or at least that's my understanding from the developer meeting when we decided we had to do it this way.
| Then I would say this is their problem.
| Who ever doesn't have automated build, has either just started programming or is moro....
| The first one's don't need this feature yet, the 2nd one's don't deserve it. ;-)
|
That's a valid opinion, but it doesn't help us meet the requirements that we have spelled out for us, which include (but are not limited to) performance improvement and complete support for these specs.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261328#4261328
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261328
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by david.lloyd＠jboss.com
"alesj" wrote : "david.lloyd(a)jboss.com" wrote :
| | Wrong. Because you end up contorting your code to match the use-case of the dependency, rather than the use case you're trying to achieve, causing ineffective code to become further entrenched, and making it even harder to fix later.
| |
| A?
| What's the point of frameworks then?
|
They have no point, in and of themselves, unless they solve a specific problem without introducing more problems. If the framework doesn't have a clearly defined contract, it is a problem. If the framework's contract cannot possibly be met (aka VFS2), it's a defect waiting to happen. If a framework doesn't have a strictly defined and limited scope it will eventually overlap and conflict with other frameworks.
"alesj" wrote :
| But well, now that I see your take on ext libs,
| I'm no longer wondering why VFS3, vs. trying to fix existing impl.
|
Ales, the implementation can't be fixed because it's the API that is broken. That's why the new solution is so much smaller. It has a clearly defined API, with contracts that can be met by the implementation. Yes there are implementation fixes as well, but it's fixing the API (and thus usage patterns) which gives us the performance increase and size decrease without compromising functionality.
"alesj" wrote :
| Wrong in what way?
| Going back to AS4 behind an VFS api (aka VFS3) doesn't make it right. ;-)
|
I don't see what you're getting at here.
"alesj" wrote : "david.lloyd(a)jboss.com" wrote :
| | Refactoring code is easy. Refactoring semantics is really difficult (see VFS again).
| |
| Specially when you rename packages for no reason, right? ;-)
|
Huh? Are you referring to VFS? Renaming the package is just a one-key code refactor, it has nothing to do with semantics.
"alesj" wrote :
| I'm not saying you're completely wrong.
| But in this case - as again my use-case proves it -
| I would never take that re-invented "reflection abstraction + resource lookup abstraction" over existing impls.
What if there was a substantial speed increase and memory footprint decrease associated with doing so? That's the question I think we need to explore here.
"david.lloyd(a)jboss.com" wrote :
| We're here to solve problems, not worship old ineffective solutions.
You don't sound convincing, specially with all the negative comments about ext code.
Looks like you're more into re-writing things than solving real problems.
The world is not perfect, the code is not perfect,
but at least the code is open sourced, hence you can fix it. ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261323#4261323
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261323
16 years, 5 months