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: kukeltje <nu...@jb...> - 2005-08-05 13:33:22
|
"tom...@jb..." wrote : The task controller is to give you more flexibility in the data handling. The task controller is used to fetch the data from the process variables and transform them into task form parameters. It is not required that the task form parameters have a relation with process variables. With form parameters you mean the form parameters as used by the default webapp. That is at least the impression I got when trying to implement a task controller. "tom...@jb..." wrote : | In the other direction, when the task parameters are submitted, this could/should lead to updates in the process variables. but a custom implementation of the task controller here does not have to keep the one-on-one relation between task parameters and process variables. (e.g. the form could submit 2 integer values. the task controller could add them and store the result in a process variable) Again, task parameters as posted by the default webbap. right? "tom...@jb..." wrote : | is there some other behaviour that you want to customize ? Yes, A completely different type of form, namely an xform. I'm currently working on this with a party that has a server-side xforms engine (applet and AJAX compliant version are being worked on). A different task instance handler seems more appropriate then creating a mapping between task form parameters and the way this xforms engine works internally. Ronald View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888617#3888617 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888617 |
|
From: mafor <nu...@jb...> - 2005-08-05 13:32:21
|
I have scanned the forums and the web for information on this but haven't found adequate information. If I simply missed some wiki page somewhere please let me know. 1. What version of JBR is included in JBoss AS 4.0.3RC1? 2. Is it possible to run AS4.0.3RC1/EJB3 with only JBR 1.2.0, i.e. replacing the old transport stack? If it is, please give some hints on how to do this. Sorry if I missed something obvious. Thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888615#3888615 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888615 |
|
From: sengsational <nu...@jb...> - 2005-08-05 13:30:49
|
Same problem with the VSS plug-in; if the project is connected to VSS, the "run packaging" fails, if the project is disconnected from VSS, the "run packaging" works. An internal error occurred during: "Packaging Generation". java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: P/TestJsp org.eclipse.core.internal.runtime.Assert.isLegal(Assert.java:58) org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:106) org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:200) org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:80) org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:170) org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:95) org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1628) org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1224) org.jboss.ide.eclipse.packaging.ui.actions.PackagingRunAction$1.run(PackagingRunAction.java:195) org.eclipse.core.internal.jobs.Worker.run(Worker.java:66) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888614#3888614 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888614 |
|
From: gamac <nu...@jb...> - 2005-08-05 13:09:48
|
I'm having this problem too!
I'm trying to build JBoss from a fresh checkout (cvs co -r "Branch_4_0" jbo=
ss-4.0), on a Red Hat box, with Sun JDK 1.5.0_04.
Where's what I get at the end of the build:
/usr/jboss/jboss-Branch_4_0/media/src/main/org/jboss/media/util/registry/Re=
gistry.java:16: warning: unmappable character for encoding UTF8
* @author Ricardo Arg=C3=AF=C2=BF=C2=BDello
=
^
error: error reading /usr/jboss/jboss-Branch_4_0/thirdparty/sun-jmf/lib/jmf=
.properties; error in opening zip file
1 error
73 warnings
BUILD FAILED
/usr/jboss/jboss-Branch_4_0/media/build.xml:197: Compile failed; see the co=
mpiler error output for details.
I've been building JBoss from the CVS on a regular basis too, and if I do a=
checkout off a month ago (e.g. with -r "2005-07-01") it works fine.
It looks like the current CVS version of the 4.0.x branch is broken, since =
it started using this new automatic dependency checking and downloading sys=
tem.
jboss-head compiles fine, though.
I've tried buiding 4.0.x on Windows but it failed too.
Any suggestions?!
Thx,
CG
View the original post : http://www.jboss.org/index.html?module=3Dbb&op=3Dv=
iewtopic&p=3D3888613#3888613
Reply to the post : http://www.jboss.org/index.html?module=3Dbb&op=3Dpostin=
g&mode=3Dreply&p=3D3888613
|
|
From: <sco...@jb...> - 2005-08-05 12:55:59
|
Can you submit it as a patch to jira for now so others can play around with its usability. The logo and color scheme definitely need to be updated as well. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888611#3888611 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888611 |
|
From: <tom...@jb...> - 2005-08-05 12:42:00
|
in the release notes (release.notes.html) i have created 2 new sections : 1) Changes to the process XML schema (jPDL) 2) Changes to the Database schema Only the HEAD trunk contains these 2 paragraphs in the release notes because only the 3.1 releases are allowed to have changes in the XML schema and/or DB schema. Even there they should be kept to a minimal. Everyone be very cautious about keeping this file up to date. Also keep an eye on each other and me :-) 3.0.x releases will not contain any database or xml changes. regards, tom. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888608#3888608 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888608 |
|
From: <tom...@jb...> - 2005-08-05 12:30:41
|
The task controller is to give you more flexibility in the data handling. The task controller is used to fetch the data from the process variables and transform them into task form parameters. It is not required that the task form parameters have a relation with process variables. In the other direction, when the task parameters are submitted, this could/should lead to updates in the process variables. but a custom implementation of the task controller here does not have to keep the one-on-one relation between task parameters and process variables. (e.g. the form could submit 2 integer values. the task controller could add them and store the result in a process variable) is there some other behaviour that you want to customize ? regards, tom. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888606#3888606 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888606 |
|
From: yxyang <nu...@jb...> - 2005-08-05 12:22:29
|
Considering all websites are page centric. If remove page, it could introduce more problems. yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888605#3888605 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888605 |
|
From: legolas <nu...@jb...> - 2005-08-05 12:05:27
|
"ju...@jb..." wrote : dynamicity means create the portal objects during runtime and have the system persist them. | | for 2.2 we feature both styles static/dynamic the restriction for the static is that the whole portal must be described in one file (thus dropping *-pages.xml files). So the definitions of the pages will be part of the *-portal.xml file. I don't mind that, alltough you lose the advantage that jspaeth pointed out. "ju...@jb..." wrote : admin will be capable to create shared pages and also the single user can create its own personnal pages (dashboard). | | all these approachs answer to different use cases. | And the more users you guys get, the more use cases will pop-up ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888602#3888602 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888602 |
|
From: <ju...@jb...> - 2005-08-05 11:52:41
|
dynamicity means create the portal objects during runtime and have the system persist them. for 2.2 we feature both styles static/dynamic the restriction for the static is that the whole portal must be described in one file (thus dropping *-pages.xml files). admin will be capable to create shared pages and also the single user can create its own personnal pages (dashboard). all these approachs answer to different use cases. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888601#3888601 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888601 |
|
From: legolas <nu...@jb...> - 2005-08-05 11:44:22
|
Julien, what do you precisely mean with dynamicity? Does it mean that any user can dynamically create and maintain the setup of the portal? Is it restricted to an administrator? In that case, I think it would be wise to stick to the static deployment structure. Because during development you'd figured out how the configuration must be, it went through functional testing and through acceptance testing. So when its time to get it into a production environment, you just need to deploy the static configuration file. In addition to yxyang's : "yxyang" wrote : Instead of removing -page.xml file, i think more attributes should be added for page. Such attributes include: Content-Type, accept-character etc...... On the whole, html related meta-data and http headers can be put in -page.xml file. | yang I would like to extend that list with e.g. Security information, like what role does a user need to view the page | Navigation related information, like the ordening of the pages | Page type, eg. page, link label, where the latter contains nested pages. | Localisation of page titles. | | | Regards, | Marcel | Or should this info go in a different configuration? | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888600#3888600 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888600 |
|
From: schrouf <nu...@jb...> - 2005-08-05 07:22:42
|
I would like to check in a modified version of the jmx console web application into CVS. This is a frame based version with a more concise and compact layout and simplified navigation (hopefully :-). As this is often a matter of taste and also has some impact on the layout of the web-consoleI would appreciate other point of view. Some screenshots and the modified jmx-console.war can be found here http://home.foni.net/~ulf-schroeter Regards Ulf View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888592#3888592 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888592 |
|
From: Ravi K. <nu...@jb...> - 2005-08-05 07:19:28
|
I am accessing a mysql database (MySQL 4.0.15, running on Winndows 2000). My program tries to insert a row into a table through Hibernate but i am getting duplicate of the primary key. Below is the error
thod:net.sf.hibernate.JDBCException: Could not execute JDBC batch update
12:47:07,931 WARN [SessionImpl] afterTransactionCompletion() was never called
12:47:09,056 WARN [JDBCExceptionReporter] SQL Error: 1062, SQLState: S1009
12:47:09,056 ERROR [JDBCExceptionReporter] Invalid argument value, message from
server: "Duplicate entry '969' for key 1"
12:47:09,056 WARN [JDBCExceptionReporter] SQL Error: 1062, SQLState: S1009
12:47:09,056 ERROR [JDBCExceptionReporter] Invalid argument value, message from
server: "Duplicate entry '969' for key 1"
12:47:09,071 ERROR [JDBCExceptionReporter] Could not execute JDBC batch update
java.sql.BatchUpdateException: Invalid argument value, message from server: "Du
plicate entry '969' for key 1"
at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:
1404)
at com.mchange.v2.sql.filter.FilterPreparedStatement.executeBatch(Filter
PreparedStatement.java:260)
at net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.
java:54)
at net.sf.hibernate.impl.BatcherImpl.executeBatch(BatcherImpl.java:118)
at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2311)
at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2261)
at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2187)
at net.sf.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.j
ava:61)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888591#3888591
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888591
|
|
From: <tom...@jb...> - 2005-08-05 07:02:15
|
not yet. implement an ActionHandler to invoke your webservice with a Java API of your choice. regards, tom. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888587#3888587 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888587 |
|
From: <koe...@jb...> - 2005-08-05 06:47:21
|
There is a screenshot of this spiderstuff at http://blogs.cocoondev.org/crafterm/archives/2004_08.html#002060, but the referenced website seems out of order. I found an Eclipse update site containing the spider at http://javaspider.sourceforge.net/updatesite. I just checked it out and it still seems to work for Eclipse 3.x. But there is no sourcecode, so I guess the work has to be redone anyway... Nevertheless, I played with it while I was reading the Gamma/Beck book on Eclipse plug-ins and it was really cool. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888586#3888586 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888586 |
|
From: <aco...@jb...> - 2005-08-05 06:01:08
|
So I'm not a huge believer in "project mangement" in the tradtional sense or the fancy roadmaps. However, I'm trying to just work out goals for the 1.0 release to ensure we're working on the must haves for an enterprise grade mail server. I'd like some feedback. This isn't to say that we won't do any of the things I've kicked out of the 1.0 release, but since 1.0 has a tentative release date of say March or so. One must prioritize. Moreover its important we aim for a production release as soon as feasible. Its important for every project of course. Please take a look at the roadmap: http://jira.jboss.com/jira/browse/JBMAIL Meanwhile here are a few decisions I made in the interest of time that I view as more controversial: 1. No NIO until the 2.0 release: http://jira.jboss.com/jira/browse/JBMAIL-94 - while this probably limits the "per instance" or "per server" scale of the 1.0 release, it probably increases our performance on some platforms and reduces complexity dramatically. I do think NIO is a good idea and that not dedicating a thread per connection is a good idea (and proven more or less by the tomcat clan), I think we can achieve adequate performance and scale for 1.0 without it. I suspect we can make bigger gains in the area of datastore management and memory tradeoffs than this. Moreover, I think we'll be best to wait until underlying OS support for this and JVM support for this is more mature accross all platforms. 2. No "over HTTP" protocol stuff until the 2.0 release: http://jira.jboss.com/jira/browse/JBMAIL-42 - While Exchange 2003 actually has something like this as well and I think it is a good idea, its not a widely used thing now. Its something that will take time to do and probably won't be used widely anyhow. It does mean that we won't have as great of support for organizations with peculiar firewall rules (port 80 is holy and nothing bad can happen there right?), I don't think it limits us enough to make it worth our while for 2.0. 3. Exchange protocol port pushed to 2.0. We have a lot of road to travel and this will be a big effort. Its more than one protocol but several things that have to be matched. The active directory stuff alone will take time. Next, it requires a software investment which means it probably is a "rich committers" and "employee-only" effort. I think once the project is more widespread we can probably get shared resources for things like this, but right now I don't think it is feasible. Sadly its the thing I most want to do! 4. Aggregate message store stuff pushed to M5: http://jira.jboss.com/jira/browse/JBMAIL-37 - There is a lot of stuff in M4 and I want to get our milestones happening regularly again. I have only budgeted 1 month for M4 (pretty ambitious since I do have a week's trip to Japan in there). There might be some slippage but I'd rather move features to M5 than miss the date now. 5. Basic IMAP for M4. I just mean like list command and maybe get a mail or two from tbird. Its probable that this will neither be a complete or workable implementation, just some basic support for Tbird's imap. There are a number of things I haven't detailed out yet: http://jira.jboss.com/jira/browse/JBMAIL-65 These will mostly be aimed at M6+. I need to research them more heavily. It would also be helpful if experienced people and potential/existing users sounded off in those areas. Please distinguish between "nice to have" "must have" and "Must have for 1.0". View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888583#3888583 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888583 |
|
From: <ben...@jb...> - 2005-08-05 05:31:44
|
Do you further details for that plugin? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888580#3888580 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888580 |
|
From: yxyang <nu...@jb...> - 2005-08-05 02:00:51
|
Instead of removing -page.xml file, i think more attributes should be added for page. Such attributes include: Content-Type, accept-character etc...... On the whole, html related meta-data and http headers can be put in -page.xml file. yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888566#3888566 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888566 |
|
From: yxyang <nu...@jb...> - 2005-08-05 01:51:10
|
Just share my idea: I think -page.xml is needed. But it should be slightly modified. For a war file, it has its own -page.xml file. Within this -page.xml, two kinds of pages can be defined. The first is global pages which are visible globally and can be used by any portals. The second page is portal specific. For current jbp 2, the pages are all portal specific. For the lifecycle issue, why pages must be related to portal? I think portal is only a machine to put pages together, am i right? Example, For a page Pg which is portal Pt specific, it doesn't mean that Pg's lifecycle must be constrained by Pt lifecycle. Similarly, a pdf file is related to PDF reader, it doesn't mean that if there is no PDF reader installed in computer, i should remove all pdf files. :) regards Yang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888565#3888565 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888565 |
|
From: <chr...@jb...> - 2005-08-05 01:47:37
|
We can still provide a special packaging for people who like to run this on their cellphone. Otherwise I'm going to vote for the 99% common case, users who'd certainly prefer not to worry at all about JAR and classloading issues. I suggest a few common profiles, depending on what we can actually re-use, integrate with, and what people want. I'm also certain that we'll have to change this packaging once or twice until we get it right. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888564#3888564 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888564 |
|
From: <bil...@jb...> - 2005-08-05 01:34:51
|
The JBoss Microkernel has the notion of "On Demand". This means that the bean will not be created until it is needed. Doesn't having one or two large jar files mean that the entire jar gets loaded into memory? The On Demand thing, when we get the EJB3 container set up to support it, will allow us to have a smaller memory footprint if we dont use things like JMS, security, etc... What do you suggest? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888560#3888560 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888560 |
|
From: bonfarj <nu...@jb...> - 2005-08-05 00:53:31
|
i didn't understand... can jBPM invoke web services or not? if it can, how? if it can't, what i need to do? i'm using jBPM 3 thanks my friends ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888556#3888556 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888556 |
|
From: <chr...@jb...> - 2005-08-04 23:37:40
|
Should we consider repackaging to make it really a product that can be embedded easily? Maybe a few variations of a single JAR depending on the native integration someone wants. I'd love to get rid of the "what libraries do I need" FAQ right at the download button. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888546#3888546 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888546 |
|
From: freemanl <nu...@jb...> - 2005-08-04 23:15:34
|
I just downloaded the RC1 build and found that (like the beta 1 release) this functionality is not implemented! Why would there be missing functionality in a Release Candidate build? Shouldnt this build be more appropriately titled Beta 2? Is this functionality intended to be in the Final Release? Sorry but its a little frustrating View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888540#3888540 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888540 |
|
From: <ben...@jb...> - 2005-08-04 23:13:29
|
Recently I have been busy trying to build couple of more "real life" use cases for JBossCacheAop. The whole goal is to write an article promoting it! There are many possbilities after talking to people that are using it. But I have settled on two use cases both involved network management. They all have complex circular and multiple reference properties. In addition, heavy use of Collection classes (liek List) is also needed.
So that gave me a chance to fix couple problems in Collection class proxy support. But now I have run into a fundamental problem of the underlying object graph model. Previously, we use JBossInternal node to re-locate pojos that are multiple referenced. Here are the pros and cons:
Pros-
1. It is more "canonical". Meaning all the parent pojos of that shared object see the same tree under JBossInternal.
2. Locking can be applied in a more consistent manner
Cons-
1. Circular and multiple reference interaction is complicated becuase of relocation.
2. Relocation of pojos are expensive.
On the other hand, if we don't use JBossInternal, we will simply keep track of reference counting within the original pojo. Here are the pros and cons.
Pros -
1. No need for re-location. So it is efficient.
2. No need to distiguish between circular and multiple references. Their interaction is vastly simplified.
Cons -
1. It is not canonical. I.e., the location of the shared pojos depends on the order of the parent pojo get put into cache.
2. Locking behavior can be inconsistent depending on where the referenced object resides.
3. Overwriting of an existing pojo that is still multiple referenced will need to throw exception.
Anyway, because the obstacle is Cons #1 in the first JBossInternal model, I am now leaning toward the second solution of keeping the refernce counter of the original pojo. Then to solve the problems, we will:
1. To address the canonical problem (and thus the resulting locking issue), a user is advised to put the referenced pojo into cache first, e.g., cache.putObject("/shared", sharedPojo), although this is still not totally desirable.
2. To address overwriting of exsiting shared pojo that holds the reference counter, we will throw an exception if attempted. So a user is warned. Again, this is not a complete solution because a user may need to know the alternative. But we shall just treat it as a limitation now.
Any sgguestion?
-Ben
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888539#3888539
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888539
|
1965 messages has been excluded from this view by a project administrator.
