jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of JBoss ESB] - Re: JBossESB 4.0_Alpha1 released

[<mar...@jb...>]

Path of least resistance at the moment. ant for sure. Maven probably not until 2007.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954079#3954079

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954079

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: JBAS-993 broke the dependency contract

[<sco...@jb...>]

JBoss_4_0_3_SP1 is the correct cvs tag for the 4.0.3.SP1 release. I'm using it to browser diffs between versions.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954078#3954078

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954078

[Jboss-dev-forums] [Design of JBoss ESB] - Re: JBossESB 4.0_Alpha1 released

[<mar...@jb...>]

That's one of the JIRA tasks. Now I'm looking for some help on that ... ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954077#3954077

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954077

[Jboss-dev-forums] [Design of JBoss ESB] - Re: JBossESB 4.0_Alpha1 released

[tfennelly <do-...@jb...>]

(hit return too soon)

Will the builds be staying as Ant builds or are we interested in moving them to Maven?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954076#3954076

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954076

[Jboss-dev-forums] [Design of JBoss ESB] - Re: JBossESB 4.0_Alpha1 released

[tfennelly <do-...@jb...>]

Are there JUnit test suites for the new codebase?  Just wondering i.e. for regression testing as we evolve the design!!  Obviously they can sometimes be a useful comprehension tool too :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954074#3954074

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954074

[Jboss-dev-forums] [Design of Security on JBoss] - Re: JBAS-1477: Pass in the security-domain name to the login

[j2ee_junkie <do-...@jb...>]

Thanks guys for your replies.  #2 it is then.  Anil, my plan was to do exactly as you have advised.  The only question remains then.  What versions to do this update to?  HEAD and Branch_4_0?

cgriffith

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954072#3954072

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954072

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: JBAS-993 broke the dependency contract

[<ale...@jb...>]

BTW, what is the correct tag name for 4.0.3.SP1? JBoss_4_0_3_SP1 doesn't seem to be correct. Is it Branch_4_0_3_SP1?
Then I can see JBoss_4_0_3_SP1_CP_2006_06 and then patches.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954070#3954070

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954070

[Jboss-dev-forums] [Design of Security on JBoss] - Re: JBAS-1477: Pass in the security-domain name to the login

[<ani...@jb...>]

In HEAD, I have generalized security config to not be Jaas dependent but to cater to both authentication as well as authorization information. 

Branch_4_0:
Given this,  it boils down to one step:
In XMLLoginConfigImpl, when there is a request made for
public AppConfigurationEntry[] getAppConfigurationEntry(String appName)

you have the appName (which is the securityDomain),  you just populate the options with a special keyword (maybe "jboss.security.domain").  This way, the user is not forced to add an option to his LM config.  Now any LM that wants to obtain the security domain information, can do so by peeking into the options with this keyword  (which can be equivalent to Util.SECURITY_DOMAIN)

I see a need for the following in security for the 4.0 codebase:
1) A security constants interface defining constants.
2) A Security utility class.  (Util does it but it is for Jaas only).
[/url]

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954068#3954068

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954068

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Microcontainer tests for aop-mc-int

[<kab...@jb...>]

What's the trick? I am able to run them from Eclipse, but get errors when running them via ant

  | Running org.jboss.test.microcontainer.test.MicrocontainerAllTestCase
  |     [junit] Tests run: 224, Failures: 1, Errors: 60, Time elapsed: 2.156 sec
  | 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954066#3954066

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954066

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: JBAS-993 broke the dependency contract

[<ale...@jb...>]

I am checking out 4.0.3.SP1 now. But I guess it's the same as in the current EjbModule, i.e. in the EjbModule.startService.

I was thinking about moving persistenceManager.start() to EntityContainer.createService() right after persistenceManager.create(). At this point all plugins are created and set, not started though.
The start() of the persistenceManager will use the DataSource and possibly the TransactionManager. Is this acceptable?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954060#3954060

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954060

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: JBAS-993 broke the dependency contract

[<sco...@jb...>]

Ok, I see. Where was the logic for the last EntityContainer startService call in the EjbModule? I don't see it looking at the EjbModule, EntityContainer of 4.0.3SP1.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954054#3954054

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954054

[Jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Re: Can MainDeployerMBean call the deploy directly ?

[<dim...@jb...>]

Where is this code taken from? Can you provide more context?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954030#3954030

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954030

[Jboss-dev-forums] [Design of Security on JBoss] - Re: JBAS-1477: Pass in the security-domain name to the login

[<sco...@jb...>]

Moved to design forum. I'm inclined to pursue approach 2).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954029#3954029

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954029

[Jboss-dev-forums] [Design of JBossCache] - Re: Proposal: Flat 'Heap' for POJOs stored in PojoCache

[<ben...@jb...>]

"bst...@jb..." wrote : 
  | 2 Person objects, with a shared reference to an Address.  Using buddy replication.
  | 
  | 1 Person is placed in Cache 1 under "/husband" then the other is placed in Cache 1 under "/wife".  The address is stored in "/husband/address" -- "/wife/address" just has an indirect pointer to "/husband/address".
  | 
  | Cache 1 dies.  User fails over to Cache 2.  
  | 
  | 1) User calls getObject("/wife"). 
  | 2) This causes node's "/wife" and "/wife/address" to gravitate.
  | 3) User call wife.getAddress().
  | 4) JBCACHE-669 is fixed, so this causes "/_JBossInternal_/_RefMap_/husband_address" to gravitate.
  | 5) PojoCache deferences and follows the RefMap entry to "/husband/address", so node "/husband/address" is gravitated.
  | 6) Gravitating "/husband/address" *does not cause the data map of "/husband" to gravitate*!!!  Rather, Cache 2 just creates an empty node at "/husband" to maintain the tree structure.
  | 7) User calls getObject("/husband").  This returns null, because node "/husband" does not have any data.  No data gravitation is performed, because the "/husband" node *exists* in Cache 2.
  | 
  | The fundamental problem here is the intermingling of the TreeCache structure with the storage of data.  You can't access the Address object without involving the concept of "husband", which leads to all sorts of problems.
  | 
  | BTW, I don't think this particular issue has to be fixed for 1.4.0 -- we could just say BR is for plain cache operations.  However, JBCACHE-669 does need to be fixed, as FIELD replication does not work correctly without it.

Brian, I have thought about this issue while designing the new mapping scheme. While the scenario that you mentioned can happen, I think it is more unlikely. The reason being that buddy replication requires "sticky session" to operate in cases like http session repl.

If it is http session repl, then every data structure will be stored under a sessionID. In this case, my undertanding is we will gravitate everything under sessionID in one shot during failover, am I correct. Therefore, shared reference between "joe" and "mary" will still work, for example.

Using a flat mapping on the other hand, will require, during gravitation, the special need to gravitate the corresponding _JBoss_Internal_ area (since everything is stored in the internal flat heap now). In essence, we will need to walk the object graph.

For example, I am thinking what will be the best behavior for data gravitation, if after failover I do a:

  | joe = getAttribute("joe", joe);
  | joe.getName();
  | 
should we also gravitate the corresponding address field as well. Or just lazily gravitate it when needed? E.g., when

  | joe.getAddress().setCity("Taipei");
  |  
is called?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954000#3954000

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954000

[Jboss-dev-forums] [Design of JBoss jBPM] - moving from pluggable architecture to inheritence

[<tom...@jb...>]

i recently realized that pluggable architecture should be replaced with inheritence as much as possible.

currently, jPDL and the jBPM GOP implementation is designed according to the pluggable architecture mechanism.  This means that you can plug new features into the core engine by means of aggregation.

You can add new process definition information (e.g. the average time it takes for a node to execute or the odds of taking a specific transition) that results in new runtime information and add new logs.  

The pluggable architecture made sure that you can develop process features and deploy them in any process language.  

In practice, users do not compose and customize their process langauge a lot.  They might only tweak here and there.

But the pluggable architecture also has a downside.  The main downside is that all modules have to operate independently.  We were lacking some kind of notification mechanism by wich modules could listen to events generated by other modules.  

This all becomes much easier if you take an inheritence approach.  Meaning that we forsee base classes ProcessDefinition and ProcessInstance.  And that for the jPDL language we create subclasses JpdlDefinition and JpdlInstance.  In the latter case, we implement a JpdlDefinition with a fixed set of modules.  That makes it easier to tightly integrate the different modules with each other.

Probably we still want to keep some kind of extensibility mechanism, but e.g. the context and the taskmgmt should definintely be an integral part of jPDL, whereas now those are treated as independent extension modules.

This should improve the database schema and the lengthy object graph navigations that you now regularly encounter in the API.

i realize this explanation is not very clear.  i just want to throw it out in the open.  feel free to ask for more explanation or share thoughts.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953964#3953964

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953964

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: Two Transition Definitions

[<tom...@jb...>]

feel free to make a jira issue feature request and describe your desired behaviour. 

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953961#3953961

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953961

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: JBAS-993 broke the dependency contract

[<ale...@jb...>]

Actually that's not surprising since the testcase has only one EJB.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953957#3953957

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953957

[Jboss-dev-forums] [Design of JBoss Web Services] - Re: JBoss integration redesign

[<tho...@jb...>]

Jason, 

I suggest we stay away from a fix in the jbossws codebase. As we all agree, this should be solved in a general way for all MC beans with dependencies on jboss services.

For the next release, we disable the eventing subsription manager by default and document that it can only be enabled when the JNDI service is part of conf/jboss-service.xml

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953952#3953952

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953952

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: JBAS-993 broke the dependency contract

[<ale...@jb...>]

But if I move startPmAndInterceptors() to the EntityContainer.startService() the testcase passes...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953951#3953951

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953951

[Jboss-dev-forums] [Design of the JBoss EJB Container] - Re: JBAS-993 broke the dependency contract

[<ale...@jb...>]

Actually, I don't think the changes committed as a fix for JBAS-993 introduced the bug. Before the changes, the initialization of the commands of every JDBCStoreManager in the EjbMOdule was triggered by the startService call on the last EntityContainer in the EjbModule. So, by that time all the other EntityContainers in the EjbModule have successfully passed the startService phase.

The right service to depend on in this case would be the EjbModule, not the EntityContainer.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953949#3953949

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953949

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: Two Transition Definitions

[<tom...@jb...>]

aha.  you are absolutely right and i misinterpreted your request initially.  

what your saying make absolute sense.  thanks for being persistent !

here's some ways of we could add support for what you want.

* add conditions on the transitions.  there is one catch to it: how to resolve the variables that are used in the condition.  We could only resolve to the variables in the subprocess, only resolve the vars in the super process.  Or maybe we could resolve first in the sub process and then in the superprocess.  Would that make sense ?

* add an expression to the process-state that resolves to the name of the leaving transition to take.

Maybe we could strive to support both (exclusive) options...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953939#3953939

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953939

[Jboss-dev-forums] [Design of JCA on JBoss] - Re: JBAS-3343

[<wes...@jb...>]

Sigh...sorry, I can't resist.

This also came up in another discussion I had today via email (Sorry Adrian, I didn't start the thread so yell at the EJB3 guys for this :-) )

In JBoss 4.0.x we had standardjboss.xml allowing for container configurations that would be universally applied across EJB deployments unless overridden by jboss.xml. With the advent of EJB3, this mechanism has essentially dissapeared and again, as if on cue, we had a client asking how can they configure an inflow deployment without having to replicate properties in the ActivationConfig for every MDB. This is really where RA level properties would come into play in for an ActivationSpec. In fact, the spec basically calls for this capability so we may have to end up doing something for this anyway. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953898#3953898

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953898

[Jboss-dev-forums] [Design of JCA on JBoss] - Re: JBAS-3343

[<wes...@jb...>]

One more time...;-)

This is where the MBean repository, or exposure of the ResourceAdapter itself would help. Right now, the only way 'in' to the adapter is via the ManagedConnectionFactory MBean which is starting to sort of look like Swiss cheese. This is in large part due to the fact that there is no other place to 'put' stuff as it relates to a RAR deployment as a whole.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953896#3953896

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953896

[Jboss-dev-forums] [Design of JCA on JBoss] - Re: JBAS-3343

[<wes...@jb...>]

And for some reason...as if literally on cue...we get 2 questions about this in the user forum, and the JIRA task itself...

One thing we could do is add a new element to the *-ds.xml file specifically naming RA level properties. Something like: 

<ra-config-property>

Or, add a 'scope' attribute to the existing element. I am inclined to the former just because it is more clear. 



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953895#3953895

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953895

[Jboss-dev-forums] [Design of JCA on JBoss] - JBAS-3343

[<wes...@jb...>]

This is a tricky one for a few reasons.

The spec states that the ResourceAdapter should be initialized first, it's properties applied and retained. When the ManagedConnectionFactory is initialized it's properties should be set BUT if a property value is not provided, and it also exists in the ResourceAdapter, the RA property should be applied. The properties used at runtime are a union of the RA and MCF.

We definitely don't do the first one, hence the JIRA task, but we also don't allow for the second condition at all. Typical case would be an RA with the following properties:

RA
  ServerName = "localhost"
  Port = "8080"


MCF
   ServerName = ""
   Port = ""

(Yes, yes, stupid example I know)


The spec seems to suggest that the RA values would be applied here in lieu of the MCF providing these values in the descriptor. Otherwise, what would be the point of applying the values from the RA at all? Of course, if any of these were set via *-ds.xml, they would override what has already been applied. After checking *both* the RA and the MCF for the existence of the property. 


While we don't recommend modifying the contents of the ra.xml that come with our adapters, clients could most certainly do this. Further the
managed connection factory properties element constructed via XSLT will have to check both the RA and the MCF being that the property could live in both/either place. 

Unless I am complicating this scenario, it appears to be a hole that is at presently unaccounted for. 

The ConfigPropertyMetaData collections that live off the ConnectorMetaData and ConnectionDefinitionMetaData can actually help. Being that we have both collections at the time of the deployment, I can look for a disjoint between the two. This is of course after implementing equals(), hashCode(). If there are no elements in common then all is well. If there are elements in common, it's a matter of going back to the RA checking if the property was provided, etc, etc. 


The strangest edge case would be the following: 

RA
   FirstProp = ""

MCF 
   FirstProp = ""

*-ds.xml contains the config-property FirstProp with the appropriate name and type. Now...here is the rub...which one gets set? The RA or the MCF? The spec says that the MCF should take precedence in the case of intersecting names (which is really the only case that matters) but in this scenario, coupled with our deployment, it is not all that clear.


Some of this stuff needed to be cleaned up a bit anyway, so I guess it's a good thing.

Sorry for the long post. 









View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953892#3953892

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953892