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: solmaz1 <nu...@jb...> - 2005-06-17 08:36:59
|
hi,
I am trying to alter a method body
CtClass clazz = ClassPool.getDefault().get("test.test2.InvokeeBuilder");
CtMethod method = clazz.getDeclaredMethod("delegation");
method.setBody("test.test2.Invokee.display($1);");
clazz.toClass();
fist of all ok.
secodary, I 'm using the same class to alter method body (in the same JVM app server JBoss)
CtClass clazz = ClassPool.getDefault().get("test.test2.InvokeeBuilder");
CtMethod method = clazz.getDeclaredMethod("delegation");
method.setBody("test.test2.Invokee.display_new($2);");
clazz.toClass() throws javassist.CannotCompileException: by java.lang.LinkageError: duplicate class definition ...
how can I handle this case.
thanks.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881892#3881892
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881892
|
|
From: <tom...@jb...> - 2005-06-17 03:02:43
|
Ok. We'll be to point where you can use the thirdparty jboss-remoting.jar soon, so am good with that. As for eclipse configuration files, I couldn't care less. Is Adrian's choice to use it, so he can live with the consequences. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881877#3881877 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881877 |
|
From: <ovi...@jb...> - 2005-06-17 02:36:10
|
Tom, The Messaging head doesn't build with the current thirdparty jboss-remoting.jar. This is because I am using ServerInvocationHandler.getClientSessionId(), for example. This will be corrected as soon as you upgrade the thirdparty remoting to 1.2.0. It's OK anyway, I am managing this and anybody who uses the project's build.sh shouldn't have any problems. As for maintaining eclipse configuration files ... Adrian bumps into this every time he wants to do something with Messaging, so I guess I am covered there :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881876#3881876 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881876 |
|
From: <tom...@jb...> - 2005-06-17 02:19:36
|
So I am a little unclear to the inital problem. You mean that jboss-head/build/build.xml does not build or that the jms project itself does not build? If the answer is not yes to either of these, then this is not something I am concerned about. The reason being that I will replace the jboss-remoting.jar in thirdparty with the new 1.2.0 release (which should be end of next week). This shoudl get all the projects in sync with the latest release (at which time I will go through all the projects and work on any incompatabilities due to any API changes). After this, there is the issue of how and how often the jboss-remoting.jar should be updated. At one point, I was thinking could have the new jboss build do this via updating from snapshot from nightly build. Since after 1.2.0 release, I don't think the API will change, it is not that big of a deal since wouldn't have to send out an e-mail every time I did a checking (but of course don't know when will be able to do this via new jboss build). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881875#3881875 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881875 |
|
From: <ovi...@jb...> - 2005-06-17 00:16:15
|
anonymous wrote : It is incompatible because jms won't compile with the currently integrated JBoss remoting version. This is correct. JBoss Remoting head contains API changes and I have chosen to go with the head, since this is where I fix the issues I encounter. anonymous wrote : I'm assuming you didn't put in the thirdparty because | then you break the rest of JBoss? Probably yes, the remoting head will break the rest of JBoss. But putting something remoting in thirdparty is not my decision to make. It belongs to the remoting project lead. What I could have done differently is to fix bugs on stable branches instead of the head. Then, if I wanted them on head, it would have been my own responsibility to port them there. However, this is overhead I cannot afford right now, unless somebody else does Messaging. If the fixes are desirable, the remoting project lead will decide whether to back port them on stable versions. What I do is document all of them, e.g: http://jira.jboss.com/jira/browse/JBREM-137 http://jira.jboss.com/jira/browse/JBREM-106 http://jira.jboss.com/jira/browse/JBREM-92 anonymous wrote : Or are you just leaving this testing to somebody else? Partially yes. If I notice that a fix I introduced breaks the remoting testsuite, while allowing me to go forward, I make a note of it, I create a remoting test that guarantees the functionality I want and I go forward. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881864#3881864 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881864 |
|
From: <ad...@jb...> - 2005-06-16 23:38:59
|
It is incompatible because jms won't compile with the currently integrated JBoss remoting version. I'm assuming you didn't put in the thirdparty because then you break the rest of JBoss? Or are you just leaving this testing to somebody else? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881862#3881862 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881862 |
|
From: <ovi...@jb...> - 2005-06-16 23:05:04
|
anonymous wrote : | revision 1.14 | date: 2005/06/15 21:45:33; author: adrian; state: Exp; lines: +1 -1 | Fix the eclipse build. | | For some reason jms is using an incompatible jboss-remoting.jar? | src/resources/jboss-remoting.jar contains fixes that haven't made it yet into jboss-head/thirdparty/jboss/remoting. It's built from the JBossRemoting head. Why are you saying it's incompatible? If you know a better way to manage this, please let me know. I am not using eclipse, but shouldn't .classpath and .project be private to everybody? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881858#3881858 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881858 |
|
From: <rl...@jb...> - 2005-06-16 22:29:23
|
In it's current form, yes. The task takes whatever vistitor was defined, instantiates it, and sends it to the graph where it will visit each node. The visitor will perform the exact same set of operations on each vertex. That being said...considering the case of license generation for example. If the visitor were to handle doing all the work then for each vertex it encounters it would need to check if a license file already exists/or create one, get the component version information and then append some information to the license file. Another approach, if we didn't use a generic task, would be for the visitor to only be responsible for compiling a list of version information. Once it returned to the task, the task itself would use the information the visitor gathered to create the license xml. This is the approach I used for the synchronize info task. Ultimately, I think there should be a generic task to handle any and all visitors who will be doing simple things which do not requrire any pre or post processing. For complex functionality that we do not wish to repeat at each vertex, we will need more specific tasks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881852#3881852 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881852 |
|
From: <sco...@jb...> - 2005-06-16 22:11:38
|
So this visit-componentref-graph task is something I can use for any navigation task with this update? There is an additional need to deal with a mismatch between the new build thirdparty repository that includes version information in the output structure, and the thirdparty legacy structure that has no such notion. The problem being that all the existing classpaths have no version notion and I don't want to have to propgate the version info other than automatically. I'll look into the new visitor capability to see if this can be handled as part of the license-info.xml generation as well. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881847#3881847 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881847 |
|
From: <rl...@jb...> - 2005-06-16 20:12:43
|
I have implemented the functionality which will allow a visitor to be defined as an attribute and then sent to the graph. A new target has been created in the secondary-dependency-test.xml file to support this. <target name="generate-license-xml" depends="synchronize"> | <visit-componentref-graph | componentVisitor="org.jboss.ant.util.graph.ComponentRefGraphLicenseVisitor"/> | </target> When this target is executed, the class defined by componentVisitor will be instantiated and sent to the graph for a visit. Currently, this visitor does nothing more than print out the component id which is contained in the vertex it is visiting. To implement the full use case of creating the thirdparty-licenses.xml, the visit method of class org.jboss.ant.util.graph.ComponentRefGraphLicenseVisitor and possibly the execute method of class: org.jboss.ant.tasks.build.VisitComponentRefGraphTask will need to be modified, depending on the final implementation. To see this in action execute the following commands: mkdir test cd test cvs checkout jbossas cvs checkout tools cd jbossas ant -f secondary-dependency-test.xml generate-license-xml Ruel Loehr JBoss QA View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881831#3881831 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881831 |
|
From: zoid <nu...@jb...> - 2005-06-16 14:25:59
|
What about MethodCalledByConstructor? Basically, when my pointcut matches, I want to invoke a particular method on the caller object. It so happens that one of the calls is made from a constructor. Is there anyway to get to the calling object (the one being constructed) in that case? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881778#3881778 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881778 |
|
From: <kab...@jb...> - 2005-06-16 14:10:34
|
If it is a ConstructorCalledByMethodInvocation or a MethodCalledByMethodInvocation you can use getCallingObject(). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881775#3881775 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881775 |
|
From: clizarralde <nu...@jb...> - 2005-06-16 13:10:10
|
I have the same error but only on ear redeployment. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881764#3881764 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881764 |
|
From: <bil...@jb...> - 2005-06-16 12:58:32
|
We don't support this, but we should... I have added a JIRA task and we hope to get to this in 2.0. You can watch this task here: http://jira.jboss.com/jira/browse/JBAOP-150 Also, if you're interested in implementing, and you do implement it, I'd be happy to give you CVS access to commit it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881761#3881761 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881761 |
|
From: <ale...@jb...> - 2005-06-16 12:56:59
|
Let's plan inheriting types and their bindings from other schemas for the future for now. It is possible. But I haven't tried it yet. In schemas it should be done with | <xsd:include schemaLocation="other.xsd"/> | jbxb:mapEntry, jbxb:mapEntryValue, jbxb:mapEntryKey are *mostly* assembling annotations. In some cases, mapEntry can define types to the entry itself and its value. Otherwise, you just use jbxb:class. PS: I have a new [getting started tutorial|http://jboss.org/wiki/Wiki.jsp?page=JBossXB_POTutorial]. I will probably edit it to include some more basic customizations. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881760#3881760 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881760 |
|
From: zoid <nu...@jb...> - 2005-06-16 12:53:07
|
Is there a way to access the caller object from the Interceptor when using a call(...) pointcut? Basically, an equivalent of thisJoinPoint.getThis() in AspectJ. Thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881759#3881759 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881759 |
|
From: zoid <nu...@jb...> - 2005-06-16 12:52:11
|
Is it possible to override a method using the mixin construct? Eg. Base class A contains a method foo(). Class B extends A but doesn't contain any methods. Define a mixin (C and CImpl) that implement foo() in a different but compatible way (same arguments, same return value). Is there a way to apply this mixin to B thus overriding the foo() method defined by A? I tried several things, but always get the same error: "jboss-aop.xml is trying to apply an already existing method foo for class B" Thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881758#3881758 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881758 |
|
From: jeff87 <nu...@jb...> - 2005-06-16 12:32:44
|
Hi all, So I've been looking at http://jira.jboss.com/jira/browse/JBMAIL-10 and found the code in SMTPProtocolInstance. | if ((authUser != null && !authUser.equals(senderAddress.getUser())) | || (!dg.isInGroup(senderAddress.getDomain()))) { | writer.println( | "503 Incorrect Authentication for Specified Email Address"); | writer.flush(); | return false; | } | When the From field is in my domain, it seems to allow anything; which I guess is bad. When it's outside my domain I do see the 503 message. So should there be some type of alias list in jboss-service.xml associated with each user listing e-mail addresses they can use in the from field? Maybe something like: | <user> | <id>userid</id> | <password>pwd</password> | <aliases> | <alias>mail-admin@locadomain</alias> | <alias>administrator@localdomain</alias> | </aliases> | </user> | Thanks, Jeff View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881755#3881755 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881755 |
|
From: <bil...@jb...> - 2005-06-16 12:18:18
|
writing an aspect that depends on line number sounds quite dangerous and eroneous. We will never support it..Sorry... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881751#3881751 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881751 |
|
From: <sco...@jb...> - 2005-06-16 01:07:00
|
There is nothing in the spec that says timers associated with entity beans have different persistence characteristics than any other bean type with the exception that such timers must be removed when the entity is removed. Vote for the following feature request if you want truly persistent timers. http://jira.jboss.com/jira/browse/JBAS-1091 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881703#3881703 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881703 |
|
From: jraymond <nu...@jb...> - 2005-06-16 00:32:39
|
Scott, let me ask... do we remove all Entities from the database when we shutdown/undeploy? Then why would we remove all timers associated with an entity from the database when the timer is undeployed? For other EJBs I can see where the could be ambiguity, but not when dealing with Entities. -- Jayson Jayson Raymond, Chair, Seattle Java Users Group View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881700#3881700 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881700 |
|
From: dhill <nu...@jb...> - 2005-06-15 21:23:10
|
I am wondering how we can detect if a war has been deployed like on startup or when we first copy a war and also would like to be able to detect a redeployment. Is there a way to detect when these actions would happens and howto hook into the deployer to handle such cases. Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881685#3881685 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881685 |
|
From: <rl...@jb...> - 2005-06-15 19:06:13
|
The problem was occurring when the same dependency occurred more than once in the graph. Each time the dependency appeared, we would import its component-info.xml file, which of course, led to the duplicate components being present in the build and ultimately this caused duplicate targets to be created. I have modified the functionality so that a check is performed before importing a component info.xml file. If the component is already present in the ant project (e.g. we have already imported it's component-info.xml), then a new one is not created. The dependency tree is still accurate, we are simply not adding the component to the project if it already exists. I have already committed these changes so that work on the thirdparty dir can proceed. The visitor attribute functionality is next on the task list. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881677#3881677 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881677 |
|
From: destr0 <nu...@jb...> - 2005-06-15 18:49:43
|
Updated the Wiki View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881670#3881670 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881670 |
|
From: natbox <nu...@jb...> - 2005-06-15 18:28:33
|
anonymous wrote : take a look at the menu portlet. it does what you want (I beliefe) Although the menu portlet does open other pages in the portal, it does not remain visible. What would be a way to implement a menu portlet that opens windows in the center so that it can be displayed along with the page that is requested. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881663#3881663 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881663 |
1965 messages has been excluded from this view by a project administrator.
