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: <tho...@jb...> - 2005-05-08 11:56:14
|
Currently we have a sittuation where the WS meta data is obtained from a plethora of sources and all/most of those are accessed direectly throughout the jbossws codebase. These meta data sources are: * webservices.xml * wsdl * jaxrpc-maping.xml * service endpoint interface * ejb-jar.xml / web.xml * jboss.xml / jboss-web.xml The sittuation is getting worse with support of JSR-181 annotations on the endpoint implementation or the SEI. Also, it is not clear at what point of the deployment process the meta data model should be constructed. Currently the contract between the various meta data sources and possible future ones (that may overwrite each other) is not clear definied. I plan to refactor the WS meta data model to a single common view that is populated from interceptor(s) on the various endpoint deployers. The ultimate client/server side service description (i.e ServiceDesc, OperationDesc, ParameterDesc) should be untouched in this refactoring process and should be populated from the new unified meta data model. This has been assigned to http://jira.jboss.com/jira/browse/JBWS-215 Any comments from the team are welcome. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876927#3876927 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876927 |
From: ilia <nu...@jb...> - 2005-05-08 11:47:06
|
"aco...@jb..." wrote : We have not yet tested with that level of load. | We do not yet implemented antivirus checkers | I am not sure about #3. (what is that?) | #4 is available depending on which user repos you are using. | #3 is the situation when 1) You are sending letter to me 2) my smtp server sees, Uh-huh! letter seems to be From: aco...@jb... 3) my smtp server opens outgoing smtp connection to mx handler of jboss.org and does a liitle conversation: %telnet jboss.com.mail1.psmtp.com 25 Trying 64.18.4.10... Connected to jboss.com.mail1.psmtp.com. Escape character is '^]'. 220 Postini ESMTP 117 y6_1_0c7 ready. CA Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisemen ts. helo paramon.ru 250 Postini says hello back mail from:<> 250 Ok rcpt to:aco...@jb... 250 Ok as far as envelope-from appears to be valid, so, my smtp server say "ok" to incoming mal. known implementation of smtp callback checking is milter-sender: http://www.milter.info/milter-sender/index.shtml Cheers, Ilia Chipitsine View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876926#3876926 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876926 |
From: timfox <nu...@jb...> - 2005-05-08 09:18:54
|
Hi Ovidiu- Currently, all the Channel implementations in core seem to first attempt synchronous delivery, and only if that is not possible is the message stored as NACKed. According to that logic, the only messages that will be stored in the channel, and therefore browsable are NACKed messages. If we want to be able to distinguish between the two sets of messages that you refer to, then I believe we would have to change this core logic - is this something we really want to do? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876923#3876923 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876923 |
From: <aco...@jb...> - 2005-05-07 19:51:18
|
Humm I have had working eclipse .project files for some time but never thought they were valuable to anyone else ;-) so I never committed them (at least not deliberately) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876909#3876909 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876909 |
From: <aco...@jb...> - 2005-05-07 19:48:14
|
These should be integrated via a maillistener. That being said, no one has written one yet. I can't wait until there is one though! :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876908#3876908 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876908 |
From: <aco...@jb...> - 2005-05-07 19:17:50
|
We really should get some postgresql setup template for the gui installer View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876904#3876904 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876904 |
From: <aco...@jb...> - 2005-05-07 19:15:22
|
is there any firewalling or port blocking set up? There is a gui that controls this hanging somewhere off of the networking config. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876903#3876903 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876903 |
From: <aco...@jb...> - 2005-05-07 19:14:12
|
We have not yet tested with that level of load. We do not yet implemented antivirus checkers I am not sure about #3. (what is that?) #4 is available depending on which user repos you are using. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876902#3876902 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876902 |
From: <mik...@sy...> - 2005-05-07 17:13:33
|
I get the following error output from an RMI Remoting client. It am using the AOP remoting framework and the remote calls seem to work fine. org.jboss.remoting.transport.rmi.RMIServerInvoker_Stub[RemoteStub [ref: [endpoint:[192.168.0.151:8085](remote),objID:[c68c3:103b8014944: I instantiated the server programmatically using the following: InvokerLocator locator = new InvokerLocator("rmi://localhost:8085"); Connector connector = new Connector(); connector.setInvokerLocator(locator.getLocatorURI()); connector.start(); connector.addInvocationHandler("AOP", new AOPRemotingInvocationHandler()); Any help would be appreciated. This is my first test at using AOP Remoting. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876894#3876894 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876894 |
From: <ani...@jb...> - 2005-05-07 16:22:02
|
Yes, nillable=false does not make sense at all as it is the default. Only the presence of nillable=true in the element will introduce the wrapper types like Integer etc. I will update the fixture when I am ready to putback my latest changes (includes refactoring, migration to Xerces Schema Object Model and seperation of concerns). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876893#3876893 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876893 |
From: <sco...@jb...> - 2005-05-07 15:25:01
|
Our jira site should be the vehicle for patches, not the wiki. http://jira.jboss.com/jira/browse/JBMAIL View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876887#3876887 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876887 |
From: mikezzz <nu...@jb...> - 2005-05-07 15:13:18
|
Re: E. mail. my address should be in the source code (Michael Barker) in one of the author comments. Re: Eclipse. It is likely that you have modified the same line in the file that I fixed in CVS. Either hand edit the file to remove the conflict or delete the files (outside of eclipse) and do a cvs update to refresh them. I would still like to see the eclipse settings in CVS (as they generally need to versioned in line with the rest of the project), but perhaps they should go in a subdirectory and be copied in place if required. Anyway, I tend to find once you get over the initial dev. env. pain things tend to be reasonably smooth. Re: Changes. I have found the best practice is to write the code first and submit patch via the wiki (see URL in my first post) and write a forum post to alert us to it. Even in the very short time that I have been on the project you get new people making suggestions and discussing ideas that never result in anything tangible. If you have gone to the effort of making a change and submitting a patch, your comments will be taken much more seriously. Please include a README file with detail of the change and JUnit tests if it is new functionality. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876886#3876886 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876886 |
From: wobbet <nu...@jb...> - 2005-05-07 14:35:42
|
Not disheartened at all. Mildly frustrated but not disheartened... The simple fact that you made the changes is encouraging. I've seen other projects where people pointed out config errors and they were ignored. I ignore those projects :) Is there a way that I can send you email to get some of this off of the forums? I went ahead and downloaded the JBoss IDE and that cleaned up the Log4J errors so that wasn't a bad thing. I figured the IDE download would be a good thing anyway to allow direct debugging of my code. On the Eclipse front, I've found that checking in the .project, .classpath, etc. files can cause difficulties. If you or I make even a minor change to one of those and commits then an update will cause conflicts. When I updated after you said "fixed" Eclipse told me that the .project and .classpath files were no longer valid. My suggestion is that you provide a .tar.gz/.zip file containing the initial Eclipse config as part of the source distro rather than committing it. If someone is using Eclipse they can use that as a starting point and configure with the local changes they need. I think I've found some defects in at least one of the XML files but I'm not 100% certain. Should I send a patch immediately or discuss w/ you first? rjsjr View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876885#3876885 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876885 |
From: <tho...@jb...> - 2005-05-07 12:54:07
|
Looking at the Base.java and Derived.java I think nillable='false' should be removed as this is the default for primitive types. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876878#3876878 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876878 |
From: mikezzz <nu...@jb...> - 2005-05-07 11:54:27
|
Note 1 - Fixed, removed external builder. Note 2 - Fixed, should use the junit.jar from lib directory. Note 3 - This is standard for setting up eclipse, otherwise we would have to explicitly specify the jboss install location which will be different from machine. At the moment there is no "official JBoss Mail dev environment" the .project & .classpath files are simply mine as I happen to use eclipse. Note 4 - Fixed. Unfortunately there are only a few of us working on the project, and things like documenation and HOWTOs do tend to end up being secondary to coding (for better or for worse). Pointing these errors is helpful, as at times we are (blissfully) unware of what has gotten out of date. Any contributions that you would like to make would be useful, even a Wiki page describing "developing JBoss Mail using eclipse". Please don't get disheartened by the state of play at the moment, we welcome all genuine interest and contributions. Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876876#3876876 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876876 |
From: timfox <nu...@jb...> - 2005-05-07 08:03:59
|
Ok, will do View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876869#3876869 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876869 |
From: <ovi...@jb...> - 2005-05-07 05:58:43
|
The current Channel interface is not rich enough to allow browsing. getUnacknowledged()/hasMessages() currently refer to the union between the set of messages that have not been acknowledged at all (for example the messages being held by a queue with no receivers) and the set of messages that have been delivered, but then NACKed. The current JBossMQ implementation of BasicQueue.browse() returns only to the first set. Probably the best thing to do is to add a browse() method to the Channel. Do you want to take a look at that? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876866#3876866 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876866 |
From: <ovi...@jb...> - 2005-05-07 04:20:42
|
OK. org.jboss.jms.server.endpoint.Consumer is "Something". I will modify it to use a thread pool to deliver messages asynchronously to the remoting callback. This way, core threads will never touch the remoting layer. Acknowledgments will be sent back to the server by the thread that accepts the message. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876862#3876862 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876862 |
From: wobbet <nu...@jb...> - 2005-05-07 04:11:54
|
I have the source and I opened it up in Eclipse 3.1M6 (using MyEclipse(1) running Java 5 on WinXP Pro SP2. Note 1 - I get a build error saying that an external builder is invalid. Is this an issue w/ my config or am I missing some config instructions? Note 2 - After I remove the external builder from the project it will still not build saying "Build path entry is missing: org.jboss.ide.eclipse.jdt.core.classpath.junit-3.8.1" which implies I'm supposed to have the JBoss IDE plug-ins installed. Do I really need the JBoss IDE version of JUnit or is the standard JUnit good enough? I'll try the standard JUnit first and find out that way... Note 3 - I get a large collection of "unbound classpath variable" errors for JBOSS_HOME. After actually setting JBOSS_HOME as a classpath variable those go away. Note 4 - The Mail Services "Get The Source" page at http://wiki.jboss.org/wiki/Wiki.jsp?page=MailServicesGetTheSource[/url] is not up to date. The correct page describing how to get the source is at [url]http://wiki.jboss.org/wiki/Wiki.jsp?page=CVSRepository. I'm willing to do work to get up and running on this but having a document that describes what I need to do to get configured would be of great help. I'd rather spend the time coding than figurin' the configurin'. rjsjr 1 - http://www.myeclipseide.com View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876861#3876861 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876861 |
From: <sco...@jb...> - 2005-05-07 01:09:02
|
It needs to be in a remoting module of the jbossas project since its integration code that bridges services in the server. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876855#3876855 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876855 |
From: <tho...@jb...> - 2005-05-07 00:00:53
|
xsd:int maps to int if nillable='false' and to java.lang.Integer if nillable='true' The default is nillable='false' Can you confirm that wscompile uses primitive types for nillable='false' View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876854#3876854 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876854 |
From: <tom...@jb...> - 2005-05-06 20:09:32
|
"sco...@jb..." wrote : | We need a variation of the SSLSocketBuilder that works with the JaasSecurityDomain or a refactoring of it so that we have a central service that has a mechanism for not requiring clear text passwords. I can build an mbean service that will implement the ServerSocketFactoryMBean and uses the DomainServerSocketFactory (which gets it's SecurityDomain set by an attribute for the preferred JaasSecuirtyDomain). Where should I put this code (since remoting and security don't need to know about one another otherwise)? "sco...@jb..." wrote : | Do you have a test that shows using this for a secure ejb invocation? | I have run a test using the sslsocket transport for unified invoker, with a home grown ejb and client and it worked, but do not have anything automated or part of the testsuite. How/where should I add something like this to the testsuite? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876844#3876844 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876844 |
From: <tom...@jb...> - 2005-05-06 20:08:52
|
We need a variation of the SSLSocketBuilder that works with the JaasSecurityDomain or a refactoring of it so that we have a central service that has a mechanism for not requiring clear text passwords. I can build an mbean service that will implement the ServerSocketFactoryMBean and uses the DomainServerSocketFactory (which gets it's SecurityDomain set by an attribute for the preferred JaasSecuirtyDomain). Where should I put this code (since remoting and security don't need to know about one another otherwise)? "sco...@jb..." wrote : | Do you have a test that shows using this for a secure ejb invocation? | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876843#3876843 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876843 |
From: wobbet <nu...@jb...> - 2005-05-06 19:56:17
|
My first run will be a simple MailListener that would execute the jASEN code "inline". But for planning future work... Another thought that I had was that it could be coded as an MBean/Servlet and listen on a port. That would allow it to work in the same fashion that SpamAssassin's daemon (spamd) works. Other services could then take advantage of the functionality in the same fashion they would spamd. If I do that then I could go back and re-write the MailListener to open the port and send in the data and get the response back that way. Is that too much network overhead? Or there's always the "give them lots of options to shoot themselves with" and allow the config to choose between the daemon or the inline style. But the first thing is a simple inline implementation. I hope my wife doesn't mind me staying up late this weekend... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876841#3876841 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876841 |
From: mikezzz <nu...@jb...> - 2005-05-06 19:19:36
|
This is definitely worth doing. The main method for integrating with JBoss Mail is by implementing a MailListener. Start with looking at the org.jboss.mail.maillistener package. If you have any success submit a patch: http://wiki.jboss.org/wiki/Wiki.jsp?page=MailServicesPatches As far as I know, no one is working on Spam filtering, but it is the plan so go for it. Mike. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3876839#3876839 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3876839 |