jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Switching to https

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

After a lot of trail-and-error and no trail-and-success (hence the long res=
ponse time) I've come to the following conclusion (I'm not saying that this=
 is correct - I might be way of here since I'm pretty new to all this):

When building your portlet with JSF (MyFaces) and using commandLink and com=
mandButton for navigation, it is not possible to switch dynamically between=
 http and https within the same portlet.

If this where to work, the best implementation would be if both commandLink=
 and commandButton had a secure=3D"true" attribute that could be applied, f=
orcing the application or portal server to render the links and forms with =
https.

Since this is not the case, the other solution would be to move all the fac=
es that are supposed to be secure into a separate folder (i.e. /faces for t=
he regular faces and /faces/secure for the secure once) and then use a secu=
rity-constraint like the following in the web.xml (as you correctly suggest=
ed Julien):

<security-constraint>
  | =09<web-resource-collection>
  | =09=09<web-resource-name>Secure</web-resource-name>
  | =09=09<url-pattern>/faces/secure/*</url-pattern>
  | =09</web-resource-collection>
  | =09<user-data-constraint>
  | =09=09<transport-guarantee>CONFIDENTIAL</transport-guarantee>
  | =09</user-data-constraint>
  | </security-constraint>

It is not possible to put this into the general web.xml for the portal sinc=
e the url-pattern doesn't make sense to anybody else then the portlet it se=
lf. From outside the portlet a URL accessing a page in /faces/secure would =
look like this (line braked using =C2=BB):

http://localhost:8080/portal/portal/default/Hello%20World/My%20Portlet?mask=
=3D2 =C2=BB
&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=3D =C2=BB
%2Ffaces%2Fsecure%2FSecureHelloWorld.jsp

As you can see only the last argument part of the URL (in red) reveals that=
 we are accessing something in the folder /faces/secure. For anybody else t=
hen the portlet this just looks like any other URL argument.

But how come that I can't get this to work then? I've tried to insert the a=
bove security-constraint argument into the portlet's web.xml but it seems l=
ike that the server just ignores it. The security-constraint arguments in j=
boss-portal.sar/portal-server.war/WEB-INF/web.xml work fine though. My gues=
s is that the filter-mapping also present in the web.xml file overrules the=
 security-constraint so that it never gets to that:

<filter-mapping>
  | =09<filter-name>extensionsFilter</filter-name>
  | =09<url-pattern>/faces/*</url-pattern>
  | </filter-mapping>

The conclusion? Since we use Apache as the entry point (and also terminates=
 any SSL here as well) we might as well create a RewriteRule that uses regu=
lar expressions to look for %2Ffaces%2Fsecure%2F in the URL and then do a H=
TTP redirect to https. But what are the downsides or problems with this?

  | * Since the logic about which faces should be accessed via https is now=
 put into the Apache server, we can no longer be certain that other portal =
servers acting as WSRP consumers will protect the same faces with SSL as we=
 want them to (in fact this could only be possible if the commandLink or co=
mmandButton had a secure=3D"true" attribute).
  | * Can we always be certain that the URL will reveal which face (and in =
turn which folder) is about to be accessed? What if this is part of a POST =
request? In that case an Apache RewriteRule will not be able to detect it a=
nd then not be able correctly secure the site.
  |=20

View the original post : http://www.jboss.com/index.html?module=3Dbb&op=3Dv=
iewtopic&p=3D3954640#3954640

Reply to the post : http://www.jboss.com/index.html?module=3Dbb&op=3Dpostin=
g&mode=3Dreply&p=3D3954640

[Jboss-dev-forums] [Design of JBossCache] - Re: JBCACHE-399

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

To resolve JBCACHE-675, should we conform to our new requirement that Map keys be serialiable? Or do you want me to revert the requirement that keys be serializable?

Should we allow Map keys that are PojoCacheable?

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

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

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: Contention point in the AOP layer

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

http://jira.jboss.com/jira/browse/JBAOP-269

I have replaced this with a ConcurrentReaderHashMap in head. Please let me know if this helps

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

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

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

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

So, is it ok to assume that after EntityContainer.createService() returns, the DataSource is availble and can be used?

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

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

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

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

Scott,
Why can't we have 

  | Object[] args = //URL
  | String[] sig =    //void 
  | server.invoke(mainDeloyer,"deploy",args,sig);
  | 
instead of this 

  | MainDeployerMBean md = (MainDeployerMBean)
  |          MBeanProxyExt.create(MainDeployerMBean.class, mainDeployer, server);
  |       try
  |       {
  |          md.deploy(config.getServerConfigURL() + config.getRootDeploymentFilename());
  |       }
  |       catch (IncompleteDeploymentException e) {
  |          log.error("Root deployment has missing dependencies; continuing", e);
  |       }
  | 
This is what I am trying to say , as the code becomes more understandable .

Regards
Vicky

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

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

[Jboss-dev-forums] [Design of JMX on JBoss (JBoss/JMX)] - Re: How are the Notifications send in ServiceController hand

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

anonymous wrote : 
  | You don't really care who receives the notification, that's the whole point: anyone can subscribe to it. 
  | 
Ok that means if you have a dependent custom Management Layer you will subscribe it to listen to the Notification generated by the booting process. I am not able to think/visualize  of any the real use case , can you please provide me some ?

Regards
Vicky


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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: compilation problem in head

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

hhmmm.. never thought I'd do this but....

same here ;-)

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

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

[Jboss-dev-forums] [Javassist development Forum] - Re: Array access

[<jas...@jb...>]

"chiba" wrote : Implementing this spec. would be tricky.  Because:
  | 
  | 
  |   | test.array[5] = 10;
  |   | 
  | 
  | is compiled into:
  | 
  | 
  |   | long[] a = test.array;
  |   | a[5] = 10;
  |   | 
  | 
  | It would be difficult to recognize "a" is "test.array" when Javassist transforms "a[5] = 10".
  | 
  | 
  | 

It seems this isn't the case for the sun compiler:

 20:  getfield        #2; //Field array:[J
 23:  iconst_5
 24:  lconst_1
 25:  lastore

Or did you mean that a user can assign it to a local var and manipulate it there?

In that case, couldnt you store a reference map from local vars to arrays you are interested in?

-Jason


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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: Contention point in the AOP layer

[<cle...@jb...>]

I will move this forum to AOP development.


This was during EJB3 tests, but this feature is specific from AOP.

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

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

[Jboss-dev-forums] [Javassist development Forum] - Re: Array access

[<bst...@jb...>]

Jonas Boner told me they can track changes to arrays.  He said how but I had no idea what he meant and was doing a presentation at the time so couldn't really follow up.

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

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

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

[<jas...@jb...>]

An MC task was just created by scott to do this, so I have added a corresponding task on our side to make use of it.

http://jira.jboss.com/jira/browse/JBWS-1030

-Jason


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

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

[Jboss-dev-forums] [Design of EJB 3.0] - Re: EJB3 SFSB passivation and replication

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

We have had a meeting in Vegas to discuss this further. It is more complicated than we thought to simply re-inject the Hibernate ExtendedPersistenceContext.

We also had a conf call on Wednesday to discuss this further on how to move forward on possibly for Hibernate to provide some sort of API to manage the replication delta (and more).

For more details, I have update the Jira:
http://jira.jboss.com/jira/browse/EJBTHREE-585 and this wiki:
http://wiki.jboss.org/wiki/Wiki.jsp?page=Ejb3ClusteringAndExtendedEntityManager


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

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

[Jboss-dev-forums] [Design of EJB 3.0] - 4.0.4 ejb3 clustering upgrade problem with JBossCache 1.3 an

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

This problem was discovered in this Cache forum thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=83655

Basically here is the problem:
In ejb3 under PassivationTreeCache.java (of which is a sublcass of TreeCache), there is an additional API to expose EvictionPolicy:

   public EvictionPolicy getEvictionPolicy()
   {
      return (EvictionPolicy) eviction_policy_provider;
   }

where in 1.2.4, the protected field, eviction_policy_provider, is declared as TreeCacheListener (but also implements EvictionPolicy), and in 1.3 it is declared as EvictionPolicy.

So here is the problem, in head, the code base has been compiled with 1.3 and later. So upgrading to 1.4 will have no problem. 

In 4.0.4, however, since the cache release version is still 1.2.4 (and therefore compiled as such), when upgrading to 1.4, it will produce the field not found exception for the eviction_policyu_provider.

So for the released version of ejb3, nothing we can do about it, meaning we simply can't upgrade JBossCache version to 1.3 and beyond for sfsb clustering.

But for future release, there are two possiblities:

1. We will rollout a 4.0.4SP1 that has the JBC 1.4 release checked in.
2. Or we will rollout an independent ejb3 release like RC9-FD from 4.0 (or head).


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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: JBCACHE-399

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

I have discover some additional issues that are tracked here:

http://jira.jboss.com/jira/browse/JBCACHE-676
http://jira.jboss.com/jira/browse/JBCACHE-110
http://jira.jboss.com/jira/browse/JBCACHE-675

While 110 and 676 are the problems that I told you before.

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

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

[Jboss-dev-forums] [Javassist development Forum] - Re: Array access

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

So in other words, neither AspectJ (or asm) can do this? Just to confirm.


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

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

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Aop field interceptor to provide filtering for method call s

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

Kabir,

This is the issue that we discussed in Vegas:
http://jira.jboss.com/jira/browse/JBCACHE-110

Basically what I am looking for from PojoCache point of view is that, say, if while I am doing all field interception, but if it is from certain method call stack, then I don't care about it. So either aop not to intercept it or I have some knowledge that I can skip it.

Is it possible for AOP to provide such funcationality?

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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: compilation problem in head

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

One more thing...I do get a compile error with IdentityBean in Eclipse.

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

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

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: compilation problem in head

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

Tom,

The pageflow and identity errors are now gone.  I'm still getting two compile errors in Mail.java, lines 234, 238 (same as above)

I did a fresh checkout again to be sure and all the steps in build/readme.html

Regards,
Jim

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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: [JBCACHE-669] Enable data gravitation for PojoCache inte

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

I don't think we need it now. But one thing that I can think of is the need to have a global scope node, e.g., a read-only region where everyone can see and use. BR will break down in this case.

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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: PojoCache 2.0 Interface

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

And how do I get an Interceptor instance? From getInterceptorChain and take any of the Interceptor?

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

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

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

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

Yeah, active loading is what I have in mind. As a matter of fact, if we can safely assume that all BR will a corresponding session ID fqn associated with it, then all we need is graviate it twice: one on the regular /JSESSION/sessionId and one on _JBOSS_INTERNAL/sessionId. All the object graphs should be contained within.

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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: [JBCACHE-669] Enable data gravitation for PojoCache inte

[<bst...@jb...>]

It's not clear from the above thread, so bears saying -- Ben's fixed JBCACHE-669, so shared objects will be gravitated.  The last bit about the scope of sharing is a further issue beyond the basic need to be able to follow and gravitate indirect references to shared objects.

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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: [JBCACHE-669] Enable data gravitation for PojoCache inte

[<bst...@jb...>]

To think through the kludgy idea a bit (mostly to save others doing it)....

In general, the scope of pojo sharing needs to match up with a data structure that is meant to be "owned" by a single cache.  Otherwise if a POJO is shared between two different owners, the owners will keep gravitating it back and forth.  So, for example, sharing a POJO within a session is fine; sharing across sessions is not.

If a POJO is shared across data owners, then it gets replicated globally, not w/ BR.  Thus the owners no longer need to fight over it.

Problems:

1) How do you know the POJO is shared across data owners.  The cache doesn't know what the boundaries are of the data structure that is meant to be owned by one owner.

2) How do you ensure that all replication associated with a POJO's object graph is done globally, partic. if the changes occur as part of a tx that involves nodes that are not replicated globally?

YIKES!! Too kludgy.

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

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

[Jboss-dev-forums] [Design of Security on JBoss] - Re: Authorization framework

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

This has been added to the testcase that drove the culmination of this important JIRA feature request:
http://jira.jboss.com/jira/browse/JBAS-3324

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

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

[Jboss-dev-forums] [Design of JBossCache] - Re: Integration issue w/ 1.4.0.CR2 and JBoss AS 4.0.4

[<bst...@jb...>]

Oh, it will definitely go in HEAD.  Just a matter of timing vis a vis Ben's refactoring work, not stepping on each other, etc.

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

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