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: vickyk <do-...@jb...> - 2006-06-28 06:36:45
|
anonymous wrote :
| // Ok, now deploy the root deployable to finish the job
|
| MainDeployerMBean md = (MainDeployerMBean)
| MBeanProxyExt.create(MainDeployerMBean.class, mainDeployer, server);
|
| try
| {
| md.deploy(config.getServerConfigURL() + config.getRootDeploymentFilename());
| }
| catch (IncompleteDeploymentException e) {
| log.error("Root deployment has missing dependencies; continuing", e);
| }
|
After going through the code of the MBeanProxyExt I found that this basically does the optimization based on method/attribute call on MBean. What I mean to say is that if the application calls the MBean setter/getter the same value could also be obtained from the corresponding attributes in the MBean . As per my understanding getting the attribute would be faster than getting the same data from the method call.
So I was wondering if calling the deploy method directly on the MainDeployerMBean is ok . I know this is just called once during the booting of the Jboss so would not significantly improve the booting.
Why I am suggesting to make a direct call to the MainDeployer is because the code will become more easy to understand ?
Does this make a sense?
Regards
Vicky
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953890#3953890
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953890
|
|
From: rapelh <do-...@jb...> - 2006-06-28 05:39:29
|
HI, I have been unit testing jrunit itself and using my jrunit builds to unit test jboss-remoting. I am talking of the Linux case specifically. Due to http://wiki.jboss.org/wiki/Wiki.jsp?page=IPv6 TestDriver must be patched on Linux to include -Djava.net.preferIPv4Stack=true in the exec string. On a specific machine, while testing jboss-remoting, I also found it necessary to adjust (increase) the timeouts. After that I ran into many java.lang.IllegalMonitorStateException at java.lang.Object.wait(J)V (Native Method) at org.jboss.jrunit.harness.TestDriver.shutdown (TestDriver.java:508) which I solved marking the thread to be waited on that line as synchronized. After both actions, both jrunit unit tests itself, as well as jboss-remoting unit tests gave much better results, with some issues pending in both cases. I will post the details later. Cheers, Ralph View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953875#3953875 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953875 |
|
From: <bst...@jb...> - 2006-06-28 05:21:03
|
Well, one thought is that going to 2.0 gives us the freedom to specify in the CacheLoader contract what the format of the data passed to storeEntireState has to be. So, we theoretically could take the in-memory state and pass it to storeEntireState. But we'd all have to think very long and very hard about doing that, as we'd have to live by the contract as much as anyone. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953870#3953870 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953870 |
|
From: <mcu...@jb...> - 2006-06-27 23:44:47
|
It's been brought to my attention that the "Alpha" and "Beta" naming will probably be innacurate according to our versioning guidelines: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning Basically the guidelines say that Alpha and Beta should be used for "feature complete" versions. Mark Proctor has argued that odd number versioning (i.e.. 1.9) should be used for the development process and "even" number versioning (i.e. 2.0) should be used for our final user-facing version. Following these guidelines our new release names would look like this: 6/30: 1.9.0.M1 7/14: 1.9.0.M2 8/4: 1.9.0.M3 8/25: 1.9.0.M4 9/15: 2.0.0.Beta 9/22: 2.0.0.CR1 9/29: 2.0.0.CR2 10/6: 2.0.0.GA Definately looking for more feedback if this makes sense (remember we can't use "Milestone" as a release identifier in the same release series as our "GA" because of OSGi's version ordering rules) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953853#3953853 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953853 |
|
From: <go...@ic...> - 2006-06-27 22:42:16
|
so as to not reinvent the wheel, does anyone have the sql code to fully delete emails from dbase i.e., when a user or mailbox is deleted, all their associated email should be deleted, was wondering if anyone already has the SQL code that could accomplish this...will keep searching forums though, would look in code, but last time I spoke with Andrew, he stated mails were never fully expunged, and that we needed a routine to do this periodically View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953847#3953847 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953847 |
|
From: <dan...@jb...> - 2006-06-27 21:00:26
|
Yes I like the idea of having each bank use a different transport method, we will do one of course first then expand it from there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953835#3953835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953835 |
|
From: martykells <do-...@jb...> - 2006-06-27 20:12:08
|
I agree a simple approach makes more sense at this time. Having the credit agency as a local ejb would be the best way to go and an email response would be a nice touch. As you say we can always expand the front end at a later date (perhaps an optional REST implementation) but SOAP makes sense at this stage. Where you planning on having a fixed number of banks, each configured for one the transports: JMS, EMAIL, File, etc... ? or had you another idea in mind. I think Mule used SOAP to all the Banks (and then JMS back) leaving it up to the user to change the transport manually. Incidentally I noticed they've got some nice new diagrams for the LoanBroker if anyone is still unsure. http://mule.codehaus.org/LoanBroker+ESB View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953830#3953830 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953830 |
|
From: <ral...@jb...> - 2006-06-27 19:56:09
|
discard my previous post, I misinterpreted your question. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953828#3953828 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953828 |
|
From: <ral...@jb...> - 2006-06-27 19:54:56
|
this is already in CVS jboss-portal-2.4 module View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953827#3953827 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953827 |
|
From: knovoselov <do-...@jb...> - 2006-06-27 19:47:20
|
Any plans to update projects .classpath entries to reflect new thirdparty structure? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953826#3953826 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953826 |
|
From: <dan...@jb...> - 2006-06-27 19:45:08
|
I've added a state/flow diagram Esteban put together for us to use as a reference of what we're trying to achieve. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953825#3953825 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953825 |
|
From: <tom...@jb...> - 2006-06-27 19:44:00
|
One of my biggest issues when using JRunit for remoting tests is that sometimes messages, such as sending test results, do not get delivered to the JRunit driver class. This causes the driver to timeout thinking that the tests are hung and produce an error and kill the test. JGroups is the framework used behind the MessageBus class which handles the messaging. I have been able to identify in the logging that the test result message is sent by the client test, but never consumed by the driver's MessageBus. I have tried different JGroups configurations, but can't seem to find one where this does not occasionally happen. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953824#3953824 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953824 |
|
From: <mar...@jb...> - 2006-06-27 19:42:34
|
"dan...@jb..." wrote : | We could do Aggregator implementation, but not for this example I don't think. I'm trying to keep it as simple as possible and not have to add functionality to our core codebase - take the "use as is" approach for now. | I agree. I think building it up over time is the right approach and even illustrating that build up as part of the trailmap/example: take a user from a basic example to a more complex one in a number of steps. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953823#3953823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953823 |
|
From: <cle...@jb...> - 2006-06-27 19:41:06
|
The right forum would be Internal Benchmark. We have used Jrunit internally for JBossRemoting, and JBossSerialization. We are at this point (just a coincidence your message came today) gathering requirements to finish the release. If you actually go now to design on of internal Benchmark you will se a post about that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953822#3953822 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953822 |
|
From: <cle...@jb...> - 2006-06-27 19:39:08
|
I will start adding sources on distribution (next release) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953821#3953821 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953821 |
|
From: <bst...@jb...> - 2006-06-27 19:27:05
|
I don't think this is a JIRA issue. It's just removing two interfaces that were created a couple days ago as a side effect of a copy operation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953815#3953815 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953815 |
|
From: <tom...@jb...> - 2006-06-27 19:27:04
|
Am starting this thread to discuss current JRunit requirements and what needs to be done to further satisfy these requirements and stabilize the project. Current requirements have been posted to: http://labs.jboss.com/portal/index.html?ctrl:cmd=action&ctrl:window=default.wiki.WikiPortletWindow&page=JRunit_Requirements&language=EN View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953814#3953814 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953814 |
|
From: martykells <do-...@jb...> - 2006-06-27 19:25:17
|
Daniel you might want to make a reference to the fact that this example is based on the www.eaipatterns.org sample - just so that people don't get the wrong idea ;-) At a basic level this design would be suitable, both Mule and ServiceMix have applied the same example with this design. If you haven't tried them Mules LoanBorker-ESB verison gives a better feel as it allows you (the customer) to 'input' the requested loan amount and then produces the loan quote - instead of ServiceMix approach which didn't ask but just provided a result. The diagram might need reworking though, as far as I'm aware in the original version the Loan Broker deals with the request and forwards this to the credit agency. The credit agency can then attach the 'customer credit profile' to the 'original loan request' it then gets returned and forwarded to a Lender Service which for an example purpose we could use to create the sample bank(s) and then forward the request (with credit profile). To get an idea see: http://homepages.cs.ncl.ac.uk/martin.kelly/LoanBroker_with_Lender_Service.JPG Its at this point that things can get confusing depending on implementation choice. It's possible to have the banks contact the Loan Broker service without contacting the Lender Service using a ReplyTo header on the request message but I don't know if we can support this yet! The Loan Broker can then use an 'aggregator' (eia pattern) to assemble all the bank quote messages into one (xml) file and base a decision on this for the customer as the best quote available. But again I'm not sure we will support this 'aggregator' pattern. We could of course create a simpler LoanBroker version and expand from there, perhaps even have two versions like Mule. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953798#3953798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953798 |
|
From: <gal...@jb...> - 2006-06-27 18:50:06
|
Brian, is there anything you would suggest then? I can't see an easy solution to the problem you are stating. I will need to look at the exact details of those methods to see what I can do. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953797#3953797 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953797 |
|
From: chiba <do-...@jb...> - 2006-06-27 18:47:03
|
Implementing this spec. would be tricky. Because: | test.array[5] = 10; | is compiled into: | long[] a = test.array; | a[5] = 10; | It would be difficult to recognize "a" is "test.array" when Javassist transforms "a[5] = 10". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953807#3953807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953807 |
|
From: <gal...@jb...> - 2006-06-27 18:25:16
|
Or alternatively, avoid byte[] states and use navigation methods that would not trigger the cache loader. However, this is likely to be slower. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953799#3953799 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953799 |
|
From: <dan...@jb...> - 2006-06-27 18:16:45
|
Oops sorry forgot to add references to the Wiki, I had it my Word cover page. I would like the ability to let the client enter in the data to process, can be just runtime arguments to the request code or even a .JSP page. We'll figure that out later. >From the credit scoring perspective, attaching a CreditScore profile to the Customer sounds good! We could do Aggregator implementation, but not for this example I don't think. I'm trying to keep it as simple as possible and not have to add functionality to our core codebase - take the "use as is" approach for now. Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953802#3953802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953802 |
|
From: <jas...@jb...> - 2006-06-27 17:36:46
|
"sco...@jb..." wrote : | Ok, I did not realize that. Then I guess its just a question of is it worth the extra time to add support for integration of dependencies on jmx kernel beans to the deployer vs essentially creating a custom bean deployer for the jbossws usecase. The former is what I would prefer. I'll post in the mc forum on what it would take to get this done. Lack of followup would a green light to do what you want. I agree, the former is ideal because this is a problem that will affect other projects as they migrate to the mc. I will monitor the thread. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953794#3953794 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953794 |
|
From: <ani...@jb...> - 2006-06-27 17:21:10
|
Link your JIRA issues to the following container JIRA task: http://jira.jboss.com/jira/browse/JBAS-3330 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953789#3953789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953789 |
|
From: <sco...@jb...> - 2006-06-27 17:11:31
|
The MC thread: [http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953787[/url] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953788#3953788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953788 |
1965 messages has been excluded from this view by a project administrator.
