Really *weird* problem in Seam 2.x
by Max Rydahl Andersen
Hi,
http://jira.jboss.com/jira/browse/JBIDE-2190 is one of those things you just don't want to see before going GA.
We had QA reporting that they could not deploy and run an Ear application since it would throw an "no application context" exception.
I could not reproduce it and rejected it a couple of times - until they kept saying new builds did not help etc. etc.
It turns out I can reproduce it, but *only* if the deployment starts with a captial letter(!)
SeamEear breaks seamEar works. MyApp breaks myApp works.
You can "fix" it by removing jboss-seam.jar from the MANIFEST.MF but that makes zero sense since that is actually required/legal by spec
since that is what defines the classpath.
Pete thinks it is something inside jbossAS that is causing this, but what I don't understand is why it works fine with Seam 1.2, but
fails on Seam 2.0.1 and Seam 2.0.2.
Is there anyone who has an idea why seam suddenly starts failing because the first letter is a captial letter ?
(note: all references inside descriptors is the exact same casing)
/max
18 years
Identity on Seam 2.1.0 SNAPSHOT
by Felix Knecht
Hi all
I just read the forum thread [1] about (see subject).
I think that the src/main/org/jboss/seam/security-2.1.xsd needs an update for this as well, otherwise newbies like me -
trusting an editors suggestions relying on the xsd - will do it wrong again and again.
Regards
Felix
PS:
IMO it would be overkill to subscribe only for this single post or to create an account only to enter a single JIRA
entry. That's way I try it this way (I saw that the list is moderated anyway). Hope it's ok.
[1] http://www.seamframework.org/Community/IdentityOnSeam210SNAPSHOT
18 years
Javassist limitation?
by Dan Allen
While researching the internals of Seam, I observed that interceptors
are not applied to methods that a component invokes on itself, even if
those are public. This would be any method that could be written
prefixed with "this." or "super.". This behavior differs from how
interceptors work on true proxies, of which session beans are an
example.
((MyComponent) Component.getInstance(MyComponent.class)).outerMethodCall();
// intercepted
@Name("myComponent")
public class MyComponent {
public void outerMethodCall() {
innerMethodCall(); // not intercepted
}
public void innerMethodCall() { }
}
Is this something we should try to fix or should we just document it
as expected behavior? Unfortunately, I find it quite limiting because
it takes away from the fine-grained control you would get when working
with things like transactions and security.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://www.mojavelinux.com
http://manning.com/dallen
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
18 years
session invalidation problem
by Dan Allen
I was doing some session size research today in my application and I
uncovered what appears to be a pretty nasty bug in Seam during the
post-session invalidation routine. If you call #{session.invalidate}
(which is also called by #{identity.logout} it leads to an *explosion*
of sessions. (~50)
To observe this behavior, install a servlet context listener that
watches for session creation. Then run one of these two action
listener methods. You can run Thread.dumpStack() in the listener to
see that it is happening as a result of attribute reads on the
ServerConversationContext. I guess because the session was
invalidated, Seam attempts to recreate the session over and over as it
works with the conversation within that request.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://www.mojavelinux.com
http://manning.com/dallen
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
18 years
Re: [seam-dev] Google Summer of Code
by Daniel Roth
Hi,
Niclas Karlsson and I have discussed a bit on an Excel exporter. Niclas have
proposed a quite nice jsf component structure you might want to have a look
at.
Currently whe are both fed up with quite a lot of commercial work, and
haven't had time to work on it too much. Personally I think there will be
plenty of time for me to write the JSF components when the "industry summer"
of Sweden kicks in(July).
Daniel
--
Daniel Roth
M.Sc. Computer Science
daniel(a)danielroth.se
www.danielroth.se
+46 736 36 29 46
18 years
Start releasing Seam 2.0.2.GA
by Pete Muir
People,
All the issues scheduled for Seam 2.0.2.GA are now closed, so we shall
move to tagging and releasing.
Please consider the branch frozen until Jay lets us know he has
completed the release - you need to pre-clear any commits with Jay.
18 years
FaceBook integration for Seam
by Dan Allen
Someone (I don't remember who) approached me at JavaOne and asked if
the Seam development team would consider adding a module that would
aid in the development of FaceBook apps in Java. Of course, in light
of the announcement today about FaceBook dropping support for the Java
API, this might put a damper on the initiative. Still, I like the idea
of helping developers create plugins for these social networks. It
could be a great opportunity for Seam to move into a new space (so we
are not siloed to standalone enterprise applications). I would imagine
it would just be a matter of wrapping the API in something more
accessible.
Thoughts?
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://www.mojavelinux.com
http://manning.com/dallen
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
18 years
Re: [seam-dev] Wicket & Interceptors
by Pete Muir
I did consider forcing creation of seam-enabled wicket components
through a factory and just returning a proxy, however this struck me
as fairly un-wicket-like as it seemed to me that the simplicity of
Wicket was that you could use new and anonymous inner classes. Maybe
we do a POC using factories for now, and look at classloading tricks
or Paolo's idea as a second step.
On 12 May 2008, at 16:03, Igor Vaynberg wrote:
> i think thats what pax wicket does for osgi integration
>
> -igor
>
>
> On Mon, May 12, 2008 at 12:07 AM, Johan Compagner <jcompagner(a)gmail.com
> > wrote:
>> You could create a factory where you ask your instances from
>> instead of new...
>>
>>
>>
>> On 5/12/08, Paolo Di Tommaso <paolo.ditommaso(a)gmail.com> wrote:
>>> Other than using AspectJ to intercept the @Begin annotated
>>> methods, I don't
>>> see an elegant/straightforward solution.
>>>
>>>
>>> An idea could be to subclass WebPage adding a visitor to look for
>>> all
>>> components implementing IFormSubmitListener interface
>>> (ILinkListener .. and
>>> so on).
>>>
>>> That components should be replaced dynamically with an interceptor
>>> proxy.
>>>
>>> Anyway it would be a partial solution because in Wicket action
>>> could be
>>> submitted with behaviour also.
>>>
>>> Core developers any ideas?
>>>
>>>
>>> // Paolo
>>>
>>>
>>>
>>> On Fri, May 9, 2008 at 6:27 PM, Pete Muir
>>> <pmuir(a)bleepbleep.org.uk> wrote:
>>>
>>>> All,
>>>> Looking for some ideas/suggestions here (perhaps I am missing a
>>>> trick
>>>> here?).
>>>>
>>>> Wicket binds html layout/styling to Java objects which define the
>>>> component
>>>> behaviour:
>>>>
>>>> public class Home extends WebPage {
>>>>
>>>> @In Foo foo;
>>>>
>>>> public Home(final PageParameters parameters) {
>>>> add(new LoginForm("login"));
>>>> }
>>>> }
>>>>
>>>> is doable, as we use a component instantiation callback (provided
>>>> by
>>>> Wicket) to make foo a proxy which asks Seam for the component
>>>> *every time*
>>>> the object is accessed. This is pretty ugly though, and I would
>>>> prefer to
>>>> use injection/disinjection.
>>>>
>>>> However, if we want to do:
>>>>
>>>> public class LoginForm extends Form {
>>>> public LoginForm(String id) {
>>>> super(id);
>>>> add(new TextField("username", new PropertyModel(identity,
>>>> "username")));
>>>> add(new PasswordTextField("password", new
>>>> PropertyModel(identity,
>>>> "password")));
>>>> }
>>>>
>>>> @Begin
>>>> protected void onSubmit() {
>>>> // Authenticate, and display feedback to user
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>>> then no lifecycle callback will help.
>>>>
>>>> As you can see the new operator is used almost exclusively. This
>>>> means we
>>>> can't use a proxy based interceptor system. So, AFAICS we have to
>>>> use byte
>>>> code enhancement to apply an interceptor, I guess either at
>>>> compile time
>>>> or
>>>> through a custom classloader.
>>>>
>>>> So,
>>>>
>>>> 1) is it worth it (this is starting to get very fiddly)?
>>>> 2) is there a better way?
>>>>
>>>> Thanks :)
>>>>
>>>> _______________________________________________
>>>> seam-dev mailing list
>>>> seam-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>>
>>>>
>>>
>>
18 years
out for a few weeks
by Norman Richards
Just a heads up that I'll be traveling for a few weeks. I have a Seam
talk in China, and then I'll be taking some vacation time. If anyone
needs anything from me this month, then please get with me this week.
Otherwise, it'll have to wait.
18 years
