Thanks Shane, I hadn't thought of that (should have). Sounds like the entities being in different archives is not only the best way to do things, but also the only way to do it without having to write a bunch of hacks.<br>
<br><div class="gmail_quote">On Fri, Oct 12, 2012 at 4:50 PM, Shane Bryzak <span dir="ltr"><<a href="mailto:sbryzak@redhat.com" target="_blank">sbryzak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sure - the biggest problem with this relates to configuration. We use<br>
processAnnotatedType() to pick up the entity beans and perform automatic<br>
configuration during the startup process. To do this, obviously the<br>
entity beans must be in a bean archive with a beans.xml - but we can't<br>
put a beans.xml in the main jar file as it may not have any dependency<br>
on CDI. Since we have producer methods (and other configuration related<br>
code) for the main IDM module beans in the core module, we cannot just<br>
place a beans.xml in the IDM module, (which by itself wouldn't require a<br>
hard dependency on the CDI jar library) because we would then get<br>
deployment errors for ambiguous injection points. The easiest solution<br>
for this is to simply place the entity beans for the default schema in<br>
their own separate jar file, which contains a beans.xml. This way, it<br>
can be used both in an SE environment and a JEE environment without any<br>
problems.<br>
<div class="HOEnZb"><div class="h5"><br>
On 12/10/12 00:54, Pete Muir wrote:<br>
> Shane, can you elaborate on why we can't package the entity beans in the main jar, but make them only enabled optionally (e.g. via the applications persistence.xml)?<br>
><br>
> On 10 Oct 2012, at 21:07, Shane Bryzak wrote:<br>
><br>
>> On 11/10/12 00:22, Douglas Campos wrote:<br>
>>> On Oct 9, 2012, at 7:52 PM, Shane Bryzak wrote:<br>
>>><br>
>>>> On 10/10/12 08:05, Douglas Campos wrote:<br>
>>>>> On Oct 9, 2012, at 4:49 PM, Shane Bryzak wrote:<br>
>>>>><br>
>>>>>> If the goal is to make available a simple schema for just some<br>
>>>>>> developers that wanted it, the best way to do this is to provide an<br>
>>>>>> additional, optional jar file containing just the simple schema entity<br>
>>>>>> beans (call it picketlink-idm-defaultschema or something like this)<br>
>>>>>> rather than provide an entirely new implementation. This way we avoid<br>
>>>>>> the burden of having to maintain two implementations, and also avoid the<br>
>>>>>> aforementioned problem of having unwanted entity beans in the<br>
>>>>>> distribution for developers that don't want to use the simple schema.<br>
>>>>> So we go from complex to simple? Did you mean the opposite?<br>
>>>> I don't understand the question, sorry?<br>
>>> Optional jar file for the simple schema? shouldn't it be the opposite?<br>
>>><br>
>>><br>
>> No no - the point I've been (seemingly unsuccessfully) trying to make is<br>
>> that we *must not* include any entity beans by default. If we did it<br>
>> would cause a multitude of problems for our users. If we do want to<br>
>> provide a default schema that some of our users *may* elect to use<br>
>> instead of providing their own, it must be in a separate jar file.<br>
>> _______________________________________________<br>
>> security-dev mailing list<br>
>> <a href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/security-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/security-dev</a><br>
<br>
<br>
_______________________________________________<br>
security-dev mailing list<br>
<a href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/security-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/security-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jason Porter<br><a href="http://lightguard-jp.blogspot.com" target="_blank">http://lightguard-jp.blogspot.com</a><br><a href="http://twitter.com/lightguardjp" target="_blank">http://twitter.com/lightguardjp</a><br>
<br>Software Engineer<br>Open Source Advocate<br>Author of Seam Catch - Next Generation Java Exception Handling<br><br>PGP key id: 926CCFF5<br>PGP key available at: <a href="http://keyserver.net" target="_blank">keyserver.net</a>, <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>