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: <kab...@jb...> - 2005-06-30 08:04:32
|
Did you set the EnableLoadtimeWeaving attribute of the AspectManagerService to true. Try the "injboss" tutorial example (docs/aspect-framework/examples/injboss), some extra info about getting it to work with the latest aop release here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=65741 kabir View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883186#3883186 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883186 |
|
From: <dim...@jb...> - 2005-06-30 07:52:51
|
Try the User Messaging forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=48 Please dont forget to read the following: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=43573 http://www.jboss.org/index.html?module=bb&op=viewtopic&t=43817 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883184#3883184 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883184 |
|
From: kanekotky <nu...@jb...> - 2005-06-30 05:18:56
|
We evaluated JBoss4.0.0 & SPECjAppServer2004 in Japan. Please see here: http://www.ipa.go.jp/software/open/forum/NEAforum.html "Evaluation of the Java Application Layer" section. Takayuki View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883179#3883179 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883179 |
|
From: gouthamcumar <nu...@jb...> - 2005-06-30 03:56:55
|
hi, Iam running jboss in minimal.Now i want to use jms and mdb's in this conguration. please help me. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883176#3883176 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883176 |
|
From: doug4641 <nu...@jb...> - 2005-06-30 03:53:11
|
The code won't display in browser properly. If you want the nex index.html email me @ dou...@co... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883175#3883175 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883175 |
|
From: doug4641 <nu...@jb...> - 2005-06-30 03:50:13
|
I think I have the solution to your problems. I had to make the file be xhtml compliant. Here is the new code for index.html: (hope this helps) <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Fibonacci Application <h1>Fibonacci Form</h1> Limit : View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883174#3883174 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883174 |
|
From: mlybarger <nu...@jb...> - 2005-06-30 01:06:25
|
thanks for the reply Khan. I've went through the document and am still having troubles. i noticed that originally i had forgot to specify the -javaagent:plugableinstrumentor.jar as part of the JAVA_OPTS variable. i've now put that jar into the jboss bin folder and added the parameter to the JAVA_OPTS variable. i also upgraded to the 1.3 jboss aop, and to the jboss 4.0.2. i have an orgtest-aop.xml file in the server/default/deploy folder that looks like: | <?xml version="1.0" encoding="UTF-8"?> | <!DOCTYPE aop PUBLIC | "-//JBoss//DTD JBOSS AOP 1.0//EN" | "http://www.jboss.org/aop/dtd/jboss-aop_1_0.dtd"> | <aop> | <bind pointcut="execution(* org.test.ProfileTest->*(..))"> | <interceptor class="org.jboss.aspects.logging.CallLoggingInterceptor"/> | </bind> | </aop> | but still when running my web app, i have nothing being logged. still i must be missing someting. any help would be most appreciated, thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883166#3883166 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883166 |
|
From: patrickdalla <nu...@jb...> - 2005-06-29 20:03:40
|
I would like to restrict access to a particular directory. How can I do this? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883144#3883144 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883144 |
|
From: <ad...@jb...> - 2005-06-29 19:20:58
|
and "connect address" might resolve to the "relay" in the JXTA example. For DNS environments there would have to be a fallback ip address for when the hostname could not be resolved. Or you just manually configure the ip address as the "connect address". Also I think jboss-remoting has the notion of a discovery service that serves as an abstraction for resolving locators. i.e. the discovery can be anything from dynamic discovery, to preconfigured, a reference server like a DNS or a jgroups gossip service. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883137#3883137 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883137 |
|
From: <sco...@jb...> - 2005-06-29 19:18:20
|
Ok, I see what your saying, but the problem is that the server may not have any meaningful name. We do have a notion of an "external" interface for the client, but it is sometimes resolved too early in our current usage, and sometimes its simply not known. If the remoting layer had a tiered approach to resolving a name that first tried to use the name as a hostname/ip address, and then a system property of even a transformed system property (e.g., given a name of host1 use system property org.jboss.remoting.address.host1) then there is the ability to handle any situation while allowing for a purely server side configuration. In the future we could even have a locator service to deal with names that may not be in dns as is the case for redevuouz, and some sip names. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883135#3883135 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883135 |
|
From: <ad...@jb...> - 2005-06-29 19:04:07
|
Yes, I know. My point was that the system property should be unnecessary in most cases. If we didn't resolve the network address on the server and instead just allowed something to be configured/transported that might only make sense to resolve on the client. i.e. differentiate bind address == nic that the service accepts requests on (could be 0.0.0.0) connect address == host name used by client that could resolve to the firewall with port forwarding enabled or might resolve to different nics on different subnets even without a firewall. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883134#3883134 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883134 |
|
From: <sco...@jb...> - 2005-06-29 18:59:40
|
I'm not too concerned about the jxta details which may be good or bad, just whether or not there is abstraction in the form of the client side connection setup that works with firewalls or even non-dns aware envs where the participants need to be located at runtime when the connection is to be created. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883133#3883133 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883133 |
|
From: <sco...@jb...> - 2005-06-29 18:55:57
|
I'm not talking about replacing a marshalled InetAddress. There simply needs to be an ability to override any connection parameters passed to the connection factory the client endpoint is using to establish its connection. When we override the uil2 settings using system properties, the marshalled InetAddress is ignored. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883132#3883132 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883132 |
|
From: <ad...@jb...> - 2005-06-29 18:36:03
|
JXTA looks to require running "relay" software outside the firewall. http://www.dcs.gla.ac.uk/~iraklis/fyp_report/node24.html#firewallFigure View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883128#3883128 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883128 |
|
From: <ad...@jb...> - 2005-06-29 18:32:46
|
NAT only works if the firewall understands the protocol. You can't just embed an ip address in a tcp/ip stream and expect the firewall to automagically replace it. Things like RMI have system properties to override the hostname seen by the clients on the other side of the firewall, e.g. java.rmi.server.hostname The advantage of using the hostname is that it can be resolved to different ip addresses on different subnets based on dns configuration. The disadvantage is that you have more complicated dns configuration. In general, it is not a good idea to transport an InetAddress like UIL2 does, since it is pre-resolved on the server and it will usually prefer the ip address. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883126#3883126 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883126 |
|
From: <sco...@jb...> - 2005-06-29 18:19:49
|
I talked to a jboss user who indicated he needed to create a custom invoker to deal with firewall routing issues because the remoting layer did not have the notion of allowing the client endpoint to specify the connection info as an override. The basic scenario is pulling down a transport endpoint/proxy across a nating firewall where the server has no idea of the topology the client is going to be using. This is something we support in the uil2 jms transport using a client side property for the server address/name and port. We need something similar in the remoting layer as well. In talking to the jxta people, they have support for even more totorous types of paths so maybe there is an abstraction there we can incorporate. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883125#3883125 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883125 |
|
From: <ad...@jb...> - 2005-06-29 17:46:27
|
You should always forward port any fix. Backporting is upto you. 3.2.x is in maintenance mode which means that only must have fixes like security problems or those requested by customers absolutely have to be backported. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883119#3883119 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883119 |
|
From: <deb...@hp...> - 2005-06-29 17:39:00
|
I assume I will have to back port it to 3.2.X also, right? What about HEAD, should I commit this small change there also? Clebert View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883118#3883118 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883118 |
|
From: <ad...@jb...> - 2005-06-29 17:37:05
|
In jmx1.2 ObjectName implements QueryExp http://docs.jboss.org/jbossas/javadoc/3.2.7/jmx/ So any change would be redundant. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883117#3883117 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883117 |
|
From: ctday <nu...@jb...> - 2005-06-29 17:29:10
|
This has come back to life. The class is: org.jboss.mx.remoting.tracker.MBeanTracker In Jboss 3.2.5, which we are using, it is in the docs/examples/remoting/remoting.sar file. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883116#3883116 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883116 |
|
From: <ad...@jb...> - 2005-06-29 16:29:52
|
"dim...@jb..." wrote : This is just a short term solution to be able to fail a deployment directly, somewhat better from what we do now with jmx notifications. It carries the same set of problems, and it only works if the interceptor is closely deployed with the target deployer(s). | Yes, it is a mechanism that helps in the decoupling of the aspects of deployment e.g. creating webservice endpoints but my main problem with it that it does nothing to expose what is happening to the deployment. At least in the "monolithic" SubDeployer architecture there is some attempt to collect the deployment description in DeploymentInfo. anonymous wrote : | We also need to clarify what makes the org.jboss.system/deployment APIs that we want to support. Scott already raised the issue of each project describing what is its "public api" supported across versions, as oppossed to implementation details or internal integration routines that happen to be public classes. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883109#3883109 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883109 |
|
From: <ad...@jb...> - 2005-06-29 16:24:24
|
"ad...@jb..." wrote : | deployment aspects -> metadata -> kernel -> objects | ... | let alone trying to describe the possible deployment configuration to tools. In the more complicated tool workflow: raw deployment -> deployment aspects -> metadata -> user review/change -> metadata -> versioned config -> kernel -> objects View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883104#3883104 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883104 |
|
From: <ad...@jb...> - 2005-06-29 16:15:30
|
"sco...@jb..." wrote : So let's move the non-core stuff to the deployment module that contains the jsr-88 implementation? | OK anonymous wrote : | As for not supporting this in the future, what is the main problem, not being able to adapt this behavior to the jb5 kernel? | 1) It would require yet another compatibility layer to invoke user written XMBean deployment interceptors from the aspectized deployers. 2) The purpose of the aspectized deployers is to work on the metadata model of the deployment. deployment aspects -> metadata -> kernel -> objects This XMBean interception approach is just a form of scripting deployment -> interceptor -> anything at all with the kernel having no understanding of how the "anything at all" fits into the system for dependencies/classloading/lifecycle/mangement/etc. let alone trying to describe the possible deployment configuration to tools. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883102#3883102 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883102 |
|
From: <dim...@jb...> - 2005-06-29 16:11:10
|
This is just a short term solution to be able to fail a deployment directly, somewhat better from what we do now with jmx notifications. It carries the same set of problems, and it only works if the interceptor is closely deployed with the target deployer(s). It can be somewhat improved by not having a dependency and start dealing with registration notifications, but that's just as far you can get. The "interceptors" really need to register with the MainDeployer, because this is the only way to be informed of past deployments, and get the lifecycle right. This is in Adrian's deployer design, anyway. We also need to clarify what makes the org.jboss.system/deployment APIs that we want to support. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883101#3883101 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883101 |
|
From: <ad...@jb...> - 2005-06-29 16:05:00
|
http://jira.jboss.com/jira/browse/JBAS-1805 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883097#3883097 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883097 |
1965 messages has been excluded from this view by a project administrator.
