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: nickman <do-...@jb...> - 2006-06-26 23:24:32
|
I think it is built into Eclipse. Point to the native ResultSet field in your code, right click on it, select "Source", then "Generate Delegate Methods". It is a quick way to generate a delegate, but then you have to instrument 130 delegatations !!! With a proxy, you only have to do it once, and then override just the bits and pieces you need to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953577#3953577 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953577 |
|
From: <cle...@jb...> - 2006-06-26 22:59:41
|
I have always used concrete implementations instead of using Proxies or AOP for this proxy driver. I'm now implementing ProxyResultset which has 130 methods. Does anyone know any free tool (an eclipse plugin) that would implement delegation automatically? It would save 1 or 2 hours of nonsense work :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953572#3953572 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953572 |
|
From: <kab...@jb...> - 2006-06-26 21:43:14
|
I have had a look at the InterceptorBinding.rebind() stuff. When running within Eclipse, I found the same error you mention above - using a fully qualfied class name solved that in Eclipse. Also, in the case of advices, an interceptor class is generated every time AdviceFactory.create() is called (when the interceptor chains are created either on startup or resulting from a rebind). I now check with the classloader if the class has already been created, and reuse that instead of regenerating every time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953561#3953561 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953561 |
|
From: <bst...@jb...> - 2006-06-26 20:46:15
|
For AS 5 Bill's created a org.jboss.web.tomcat.tc6 package structure that parallels the old tc5 packages. As a result, interfaces o.j.w.t.tc6.session.(InstanceOf)AopMarker have been created. Does anyone see any reason to keep these new versions? The tc5 versions were meant for supporting FIELD granularity session repl with JDK 1.4-style annotations and annoc. AS 5 will require JDK 5, and our plan is to make the JBoss Cache PojoCacheable annotation the standard way of marking a class for FIELD granularity session replication. I want to keep the old o.j.w.t.tc5.session.(InstanceOf)AopMarker interfaces around so existing webapps that are using them still work, but I don't see any reason to keep a new version under the tc6 package. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953556#3953556 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953556 |
|
From: <cle...@jb...> - 2006-06-26 20:34:57
|
You have to specify at the JVM level, right? When you start your application, pass -XrunjbossInspector:,options... a Control-break will start captrutin. Another will stop capturing. You don't need any library on classPath (besides the DLL) fro this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953555#3953555 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953555 |
|
From: <cle...@jb...> - 2006-06-26 20:33:28
|
We could enable disable graphs, sure. We could have the same interface (ThreadControl) encpsulating sending to statistics, graphs or both. I mean, we could change some parameter and having ThreadLocal (or BasicController) updating only statistics or the full call graph. Another thing that might make sense, is to enable/disable capturing based on the category. For example, we could enable/disable JDBC capturing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953553#3953553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953553 |
|
From: jc7442 <do-...@jb...> - 2006-06-26 20:32:02
|
But how do you specify the options ? With Embedded EJB3 there is no run.bat to add JAVA_OPTS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953551#3953551 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953551 |
|
From: <cle...@jb...> - 2006-06-26 20:28:45
|
You could use SIGQUIT (kill -3 or ctrl-break) to start / stop capturing data. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953550#3953550 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953550 |
|
From: <cle...@jb...> - 2006-06-26 20:27:35
|
It's not possible to change these options at runtime. It would be a nice idea, but there is no way to do that now. You have to do -XrunjbossInspector:,option=value,option=value.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953549#3953549 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953549 |
|
From: jc7442 <do-...@jb...> - 2006-06-26 19:45:02
|
It is possible to specify some options at jVm start for XrunjbossInspector. Is it possible to modify these options at runtime (especially include and memory options ) ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953540#3953540 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953540 |
|
From: jc7442 <do-...@jb...> - 2006-06-26 19:40:31
|
Is it possible (if yes how ?) to use jboss profiler with tests running in JBoss embedded EJB3 ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953538#3953538 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953538 |
|
From: <wes...@jb...> - 2006-06-26 19:38:10
|
Further, I agree with anonymous wrote : | | 3. What is the usecase for the distinct TimerListener, CancelTimerListener, and StopTimerListener? Wouldn't these be better combined into a single interface with either all three callbacks, or a single callback with a state enum? | | This is the way it was written in the spec, but I think this should be changed to a single interface including all three callbacks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953536#3953536 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953536 |
|
From: <wes...@jb...> - 2006-06-26 19:28:12
|
All good suggestions. I will incorporate. Again, this was a 'rough' draft just to get people talking about this stuff. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953535#3953535 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953535 |
|
From: <sco...@jb...> - 2006-06-26 19:23:41
|
Some feedback. 1. Is the TimerPropertyKey key needed as a wrapper? Currently it does not even properly wrap its Object key, and even if it did provide an equals/hashCode it would seem to be an unnecessary wrapper around the real key. 2. Being able to access the TimerData from the Timer interface in the listener callback seems like something we need to support. In the case of both ejb and jmx timers there is a user data notion that can be passed in when the timer is created and retrieved from the timer callback object. 3. What is the usecase for the distinct TimerListener, CancelTimerListener, and StopTimerListener? Wouldn't these be better combined into a single interface with either all three callbacks, or a single callback with a state enum? 4. In terms of the most general timer scheduling method on the TimerManager, the method taking the TimerExcecutionContext would seem to be the place for extended scheduling semantics. Currently it has a period and data notion. I'm thinking we need more of a timer calendar notion to deal with non-trivial timer scheduling ala cron. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953534#3953534 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953534 |
|
From: <bst...@jb...> - 2006-06-26 19:15:19
|
No, this won't work. The byte[] returned by _getState() is made up of subsidiary byte[]s for the in-memory state and the persistent state. The _setState method is responsible for parsing these out and doing the appropriate stuff with each, including passing the *persistent* state to the cache loader. But CacheLoader.storeEntireState() only knows how to handle the persistent state. Actually, as I wrote this I realized that for 1.2.4 I did work to make the data format of the in-memory transfer and the persistent transfer consistent. So *maybe* it will work -- you parse out the the in-memory state and pass it to the cache loader. This is bad though -- the fact that the data structure of the persistent state and the in-memory state is the same is 1) not part of any interface contract, and therefore 2) if true for the cache loaders we ship with, it's only because *we* wrote them that way. Other custom implementations may be different. Re: the timeout and force parameters. I've no opinion on whether the timeout should be configurable, or whether you should just use StateTransferTimeout. The combination of "timeout" and "force" was meant to allow the calling code to loop with a successively longer timeout; on the final iteration of the loop, "force" would be set to true, and at that point _getState would force the breakage of any locks in order to ensure the transfer goes through. Perhaps you should follow a similar approach. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953532#3953532 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953532 |
|
From: nickman <do-...@jb...> - 2006-06-26 19:13:15
|
Clebert; I am still running a bit high level on the invocation call graph reporting and it's relationship to the actual invocation metrics collection, but here is my take on how they could be supported based on my assumption that graphing will have some higher overhead than simple metrics collection and aggregation (and jump in and correct me where I am off.......) The configuration meachanism to select between metrics and graphing/metrics can be in the interceptor adaptors. We can define two sets of adaptors, one that will generate stats only and one that will generate a call graph with embedded stats. Metrics only adaptors report simple flat collected stats on invocations (with the exception of the JDBC Proxy Driver which dives a bit deeper). The Call Graph/Metrics adaptors will generate call graphs with embedded metrics with the entry point for the call graph starting at the intercepting point of the configured adaptor. Does this make sense ? //Nicholas View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953529#3953529 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953529 |
|
From: hosierdm <do-...@jb...> - 2006-06-26 18:07:21
|
I'm interested in the thought process behind creating two different definitions for the transition element. I can see situations where it would be valuable to allow the condition element for transitions globally and not just inside a decision node. It could save work and help clean up a process if you wanted to branch based on a variable value and could do that straight from a node where that value is set. Any thoughts? I don't know how much work it would be to change that functionality. I assume evaluating the conditions is a function of the decision node and not generic to the transition implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953516#3953516 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953516 |
|
From: nickman <do-...@jb...> - 2006-06-26 18:06:45
|
Looks good.
So in BasicController, we can implement something like this:
| public static void pushMeasure(String category, String nodeName) {
| OperationMetricCollector collector = factory.newCollector(category, nodeName);
| getController().pushMeasure(collector);
| }
|
|
| public static void popMeasure(String category, String nodeName) {
| OperationMetricCollector collector = getController().popMeasure();
| factory.closeCollectorAndSubmit(collector);
| }
|
| public static void popFailure(String category, String nodeName) {
| OperationMetricCollector collector = getController().popMeasure();
| collector.setLocalStat("Failures", 1L); // Allows us to aggregate failures on this operation
| factory.closeCollectorAndSubmit(collector);
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953515#3953515
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953515
|
|
From: <wes...@jb...> - 2006-06-26 18:00:41
|
Right I agree, I think it makes the most sense to integrate Quartz straightaway. In fact, I believe this was always the intent at least as far as implementation was concerned. anonymous wrote : | I would like to ask for a timer manager which isn't dependant on JMX (for the embedded stack). | Yeah, I went back and forth on this one. The idea is that the version that exists in connector today is JMX dependent, however, in the jca project (not currently on HEAD) I have added timer annotations, and was planning on adding a TimerManager that was embeddable, or at the very least, didn't require JBossAS to run. I am finishing up touches on this and will check this in as soon as I can. I agree with the spi integration. I really appreciate you looking at this so quickly. Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953513#3953513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953513 |
|
From: wolfc <do-...@jb...> - 2006-06-26 17:51:44
|
Looking good! We could try to get Quartz under the hood? Then we would have a working prototype within no time (so to speak). I would like to ask for a timer manager which isn't dependant on JMX (for the embedded stack). I've committed a timer service implementation in org.jboss.ejb3.timerservice, you can rip anything from there to integrate Quartz. After that we can refactor org.jboss.ejb3.timerservice to the timer spi (can we have 1 timer manager per bean container?). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953506#3953506 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953506 |
|
From: sdunstan <do-...@jb...> - 2006-06-26 17:38:39
|
I have been working on this problem for a week.
You can try this class. I am still working out a few bugs but this seems to be working. I'll keep this topic posted with updates as I go...
Steve
| package org.jboss.portal.core.security.jaas;
|
| import java.util.HashSet;
| import java.util.Map;
| import java.util.Set;
|
| import javax.naming.InitialContext;
|
| import org.jboss.portal.identity.NoSuchUserException;
| import org.jboss.portal.identity.UserModule;
| import org.jboss.portal.identity.RoleModule;
| import org.jboss.portal.identity.User;
| import org.jboss.portal.identity.Role;
|
| import javax.security.auth.Subject;
| import javax.security.auth.callback.CallbackHandler;
| import javax.transaction.TransactionManager;
| import org.jboss.portal.common.transaction.Transactions;
|
| public class ExtModelLoginModule extends org.jboss.portal.identity.auth.IdentityLoginModule {
|
| protected String emailSuffix;
|
| public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options)
| {
| super.initialize(subject, callbackHandler, sharedState, options);
|
| emailSuffix = (String)options.get("emailSuffix");
| if (emailSuffix == null)
| emailSuffix = "";
|
| log.trace("emailSuffix = " + emailSuffix);
| }
|
| protected boolean validatePassword(String arg0, String arg1) {
| Boolean ok = Boolean.FALSE;
| try
| {
| TransactionManager tm = (TransactionManager)new InitialContext().lookup("java:/TransactionManager");
| ok = (Boolean) Transactions.required(tm, new Transactions.Runnable()
| {
| public Object run() throws Exception
| {
| try
| {
| UserModule userMod = getUserModule();
| userMod.findUserByUserName(getUsername());
| return Boolean.TRUE;
| }
| catch (NoSuchUserException e)
| {
| log.trace("NoSuchUser exception, trying to create user");
| RoleModule roleMod = getRoleModule();
| User newuser = getUserModule().createUser(getUsername(),"NONE",getUsername()+ emailSuffix);
| Role userRole = roleMod.findRoleByName("User");
| Set userRoleSet = java.util.Collections.synchronizedSet(new HashSet());
| userRoleSet.add(userRole);
| roleMod.setRoles(newuser, userRoleSet);
| return Boolean.TRUE;
| }
| }
| });
|
| } catch (Exception e1) {
| log.error("Error logging in user.", e1);
| ok = Boolean.FALSE;
| }
|
| return ok.booleanValue();
| }
|
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953504#3953504
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953504
|
|
From: <gal...@jb...> - 2006-06-26 17:29:51
|
Basically, when a node which has control over the singleton cache loader dies or leaves the cluster, another node needs to take the responsability for updating this cache loader. Now, this cache loader could be in a different machine or there could be updates in between the old node crashing and the new node taking over the role of the coordinator. pushStateWhenCoordinator makes the new coordinator dump the entire in-memory state into the cache store so that it contains a true reflection of what's in memory. Looking at the code, it seems like _getState can actually return all the in-memory state. The cache loader would then call storeEntireState(byte[] state) on the underlying cache loader. However, I'm not sure whether about _getState and some of the parameters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953502#3953502 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953502 |
|
From: raghuram11 <do-...@jb...> - 2006-06-26 17:24:12
|
Hi Julien, Thanks for informing me regarding it. Pls, let me know when can I start using that latest version of it so that I can start implementing it. Thanks, with regards, Raghuram View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953501#3953501 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953501 |
|
From: <wes...@jb...> - 2006-06-26 17:06:58
|
The first pass of this has been added to the connector project under org.jboss.resource.spi.timer As well as org.jboss.resource.timer After looking at the working draft (the commonj stuff) there are some differences in the draft and Quartz (this is understandable). Quartz has the concept of a 'job', basically an executable piece of code that gets executed in response to a trigger (basically a timer). The working draft assumes that listeners will respond to timer expiration as well as a set of lifecycle events (ie stop, cancel etc). The draft is concerned with timers in the managed scenario where it is assumed that the timer will not execute in a seperate thread, will not be persistent, not have transaction/security contexts etc, etc. The mapping of the spi and the underlying implementations EJB3/JMX will have to make up for this discrepancy. This is where we will deviate from the draft. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953497#3953497 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953497 |
|
From: <bst...@jb...> - 2006-06-26 16:59:19
|
I'm confused about what pushStateWhenCoordinator does -- doesn't it mean taking all in-memory state and doing a write-through to the cache loader? _getState doesn't provide that kind of behavior. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953495#3953495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953495 |
1965 messages has been excluded from this view by a project administrator.
